* Re: Purpose of "Status" header in HTTP responses?
2010-06-23 5:57 Purpose of "Status" header in HTTP responses? Craig Davey
@ 2010-06-23 9:07 ` Eric Wong
2010-06-24 14:56 ` Purpose of "Status" " Craig Davey
0 siblings, 1 reply; 3+ messages in thread
From: Eric Wong @ 2010-06-23 9:07 UTC (permalink / raw)
To: unicorn list; +Cc: Craig Davey
Craig Davey <me@craigdavey.ca> wrote:
> Hi folks
>
> On line #63 of unicorn/http_response.rb a "Status" header is written
> to the socket. A comment in the code explains that some broken clients
> require this header and unicorn generously accommodates them.
>
> We’re having the opposite problem. One of our clients using Microsoft
> Windows and ASP haven’t been able to connect to our HTTP API since we
> moved it to unicorn from passenger. They receive the following error
> message when they try to connect to our servers:
>
> msxml3.dll error '80072f78' server returned an invalid or unrecognized
> response
Hi Craig,
Interesting and strange...
Looking at lib/phusion_passenger/rack/request_handler.rb (blob ad22dfa)
line 94, they also set the Status: header, too (but just the numeric
code, no text).
You can try "proxy_hide_header Status;" in your nginx config
to suppress it.
Another theory: You are running nginx in front of Unicorn, right?
If not (but you really should be), the lack of a Server header may throw
off some clients...
I also don't ever want folks to be forced to reveal they use which
server they use for security concerns, so Unicorn won't ever force the
Server: header on you. And since nginx overwrites any Server header
Unicorn would set, Unicorn won't bother, either. However, it's easy to
setup Rack middleware to write anything you want in the Server header.
rainbows.git (unreleased) allows using the Rainbows::ServerToken
middleware, and if you really need it, it should be easy to port to
Unicorn:
http://git.bogomips.org/cgit/rainbows.git/tree/lib/rainbows/server_token.rb
> Our client thinks this error is caused by the "Status" header that is
> added to responses by unicorn. We don’t know of any other instances
> where this header is causing problems so we’re pretty confused about
> why it’s a problem for them.
Passenger also adds X-Powered-By, but that's completely non-standard and
probably used to get around proxies (like nginx) that overwrite the
standard Server: header. You can also make middleware (or your app) add
that header, too, and even go as far to make Unicorn pretend to be
Passenger :>
> Does anyone remember why this "Status" header was added to
> HttpResponse? Which broken clients was the change trying to
> accommodate?
I seem to recall some JavaScript libraries relied on it at some point,
and possibly some versions of Firebug. Maybe some browser plugins do,
too. Some folks here with more experience on client-side stuff ought
to chime in, since I generally stay away from GUI/DOM things.
However, even with my lack of JS experience (or because of) I realize
it's very easy to fall into the trap of writing JavaScript that relies
on the Status: header. The Status: header has been with us as a
de-facto standard since the CGI days. Older cgi.rb-based versions of
Rails set it, too.
--
Eric Wong
_______________________________________________
Unicorn mailing list - mongrel-unicorn@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-unicorn
Do not quote signatures (like this one) or top post when replying
^ permalink raw reply [flat|nested] 3+ messages in thread