Spdy - Double Status header

Matthieu Tourne matthieu.tourne at gmail.com
Wed Jun 20 16:23:54 UTC 2012


On Jun 20, 2012 8:42 AM, "Valentin V. Bartenev" <ne at vbart.ru> wrote:
>
> On Wednesday 20 June 2012 05:12:12 Matthieu Tourne wrote:
> > Hi,
> >
> > I think, I've found an interesting corner case with the recent Nginx
> > SPDY support.
> > I'm using the latest : http://nginx.org/patches/spdy/patch.spdy-37.txt
> >
> > I connect to Nginx using SPDY, and then proxy_pass to another server,
> > with a location similar to this :
> >
> >     location /redirect {
> >         add_header 'Status' '301 Moved Permanently';
> >         rewrite (.*) / permanent;
> >     }
> >
> >
> > This causes Nginx to return 2 Spdy ":status" headers, which I guess is
> > disallowed by the protocol.
> >
> >
> > This is the output from spdycat (https://github.com/tatsuhiro-t/spdylay/
)
> > Chrome reports a similar error.
> >
> > [  0.141] [INVALID; status=PROTOCOL_ERROR] recv SYN_REPLY frame
> > <version=2, flags=0, length=227>
> > (...)
> >     status: 301
> >     status: 301 Moved Permanently
> >
> >
> > Note that this can be fixed using configuration to hide any potential
> > "Status" header returned by the second server, before the Spdy
> > response is generated.
> > But the code should probably handle this ?
>
> The problem is that spdy draft 2 reserved "status" and "version" header
> names for its own purpose. This was fixed in draft 3, where all such
> headers have the colon prefix (":status", ":version").
>
> Personally, I think that since these headers are non-standard for HTTP
> protocol, then the user is entirely responsible for their usage. However,
> because the "Status" header is quite often appears somewhere, then hiding
> of these headers inside the spdy module will cause less headaches.

Why not guarantee that all these reserved headers will only appear once in
the response?
This way the visiting browser never "breaks".

Nginx could always take the first header found in the http response for the
spdy response. And avoid breaking just because the upstream is badly
configured and returns 2 Version headers for example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120620/4eeced93/attachment.html>


More information about the nginx-devel mailing list