On Thu, May 17, 2012 at 6:23 AM, Valentin V. Bartenev <span dir="ltr"><<a href="mailto:ne@vbart.ru" target="_blank">ne@vbart.ru</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>First implementation of SPDY support will work only on frontend side. So, nginx</div>
will be able to talk with backends by HTTP, FastCGI, uwsgi, or SCGI protocols.<br></blockquote><div><br></div><div>Got it. Looking forward to backend SPDY support, so crucial advantages like multiplexing are preserved. Will nginx at least add headers like "X-Priority" to the forwarded request?</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">First implementation will have no support of SPDY server push. I believe that<br>
the next step is to add pushing by special response header from backend (like<br>
"X-Accel-Redirect" but with the list of URIs to push).<br></blockquote><div><br></div><div>That'll work, but am I correct in assuming that the response containing "X-Accel-Redirect" is different from the response to the original request? If they are the same, then nginx will not be notified of the URIs to push until the server is ready to send the headers for the response to the original request. This would be more restrictive than SPDY's semantics, which allow pushing resources before the SYN_REPLY frame for the original request is even sent.</div>
<div><br></div><div>Alek</div></div>