Thanks for analysis and explanation.
Then how about the following workaround -
- queue blocked frames at the begining of queue in FIFO order.
(just remove from ngx_http_spdy_queue_blocked_frame the code:
 if (frame->priority >= (*out)->priority) {

- queue non-blocked frames after blocked in priority order:
static ngx_inline void
ngx_http_spdy_queue_frame(ngx_http_spdy_connection_t *sc,
    ngx_http_spdy_out_frame_t *frame)
    ngx_http_spdy_out_frame_t  **out;
    for (out = &sc->last_out; *out && !(*out)->blocked; out = &(*out)->next)
        if (frame->priority >= (*out)->priority) {
    frame->next = *out;
    *out = frame;

Do you foresee any obvious drawback of such approach?

BR/ Yury

2013/6/25 Valentin V. Bartenev <vbart@nginx.com>
On Tuesday 25 June 2013 12:51:17 Yury Kirpichev wrote:
> Hi Nginx Developers,
> Could someone explain what is the purpose to use blocked frame for
> SYN_REPLY frame in spdy implementation?
> According to our investigation it makes it impossible to use spdy
> priorities because of blocked frames (since each stream is started with
> SYN_REPLY which is blocked there is no way how frames from subsequent
> requests can outrun previous request with lower priority in spdy output
> queue).

SPDY uses zlib compression for output headers in SYN_REPLY frames.
In fact zlib is just a wrapper over deflate compression that consists
of LZ77 and Huffman coding.

Both client and server must keep LZ77 window in sync between each
other across a whole SPDY session, so the order of SYN_REPLY frames
cannot be changed after the compression has done.

There is a way to improve things a bit.  We may postpone compression
to the latest phase (right before sending of queue), but it requires
more code and we have no ETA for this yet.

  wbr, Valentin V. Bartenev

nginx-devel mailing list