Missing HTTP reason phrase

[Florian Munz]

Hi,

I was debugging a problem that our Rails app wasn't sending the HTTP
reason phrase in the response, which causes problems in a J2ME HTTP
client.

(responding with "HTTP/1.1 200" instead of "HTTP/1.1 200 OK")

I was wondering whose responsibility this is? I tested this with a lot
of web servers and most of them just add the reason phrase if it's
missing. Nginx, which we use, is the only one that doesn't do it.

The HTTP spec states "The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without
affecting the protocol". This currently doesn't seem to be possible
with Rack, since it only passes the integer.

Any thoughts if this something that should be fixed in Rack or in
nginx?

Cheers,
Florian

[Iñaki Baz Castillo]

First of all let's talk about if it's really an issue of Rack/Nginx:

According to HTTP ABNF grammar the reason phrase is not mandatory, but the
single space separating the status code and the reason phrase (even if empty)
*is* mandatory.

So the following is an invalid response status line:

"HTTP/1.0 200"

but the folllowing is *valid*:

"HTTP/1.0 200 "

So, which is the case of both?

--
Iñaki Baz Castillo <i...@aliax.net>

[Florian Munz]

On Feb 25, 5:35 pm, Iñaki Baz Castillo wrote:
> First of all let's talk about if it's really an issue of Rack/Nginx:

I agree that it's not necessarily an issue with Rack. Most HTTP
clients seems to handle it just fine. But the Passenger guys also
worked around it:

http://code.google.com/p/phusion-passenger/issues/detail?id=278

> So, which is the case of both?

without the space, as far as I can tell (didn't look at it with
Wireshark):

$ curl -I http://www.qype.co.uk/
HTTP/1.1 200
Server: nginx
Date: Thu, 25 Feb 2010 17:22:29 GMT

Cheers,
Florian

[Iñaki Baz Castillo]

El Jueves, 25 de Febrero de 2010, Florian Munz escribió:

> without the space, as far as I can tell (didn't look at it with
> Wireshark):
>
> $ curl -I http://www.qype.co.uk/
> HTTP/1.1 200
> Server: nginx
> Date: Thu, 25 Feb 2010 17:22:29 GMT

I've checked it and there is no space after status code (200) so the HTTP
response is invalid according to HTTP SBNF grammar.

[Ryan Tomayko]

Each Rack server handler manages writing the HTTP response onto the
wire, so I it's something you'd have to fix in whatever server
implementation you're using. It's possible, but unlikely, that the bad
response writing logic is in the Rack handler.

Thanks,
Ryan

[Florian Munz]

On Feb 26, 1:15 am, Ryan Tomayko <r...@tomayko.com> wrote:
> Each Rack server handler manages writing the HTTP response onto the
> wire, so I it's something you'd have to fix in whatever server
> implementation you're using. It's possible, but unlikely, that the bad
> response writing logic is in the Rack handler.

Okay, right now every *cgi handler only sends the status code, without
a space and without the reason phrase. That seems to be a bug. If you
agree, I can work on a patch.

The other, more general thing is that it's not possible to have custom
reason phrases with Rack, but I don't really care about that.

Cheers,
Florian

[Christian Neukirchen]

Florian Munz <flo...@qype.com> writes:

["200 Alright, dude", {...}, [...]]

should work by the SPEC, no?

> Cheers,
> Florian
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org

[Iñaki Baz Castillo]

El Lunes, 1 de Marzo de 2010, Christian Neukirchen escribió:
> ["200 Alright, dude", {...}, [...]]
>
> should work by the SPEC, no?

Mustn't be the first element of the Array a Fixnum?

[Magnus Holm]

From the spec: This is an HTTP status. When parsed as integer (to_i), it must be greater than or equal to 100.

// Magnus Holm