[Mongrel] Bare carriage returns in HTTP headers
normalperson at yhbt.net
Tue Mar 24 16:26:44 EDT 2009
Jonathan Rochkind <rochkind at jhu.edu> wrote:
> Dido Sevilla wrote:
>> I've been using Mongrel for a while to write bare HTTP servlets as a
>> replacement for webrick and encountered an HTTP client using the
>> servlet that for some reason occasionally embeds carriage return
>> characters ('\r', 0x0d) inside the value fields of message headers.
>> Mongrel doesn't like that, and aborts the request with a parse error.
>> I'm not sure if this is strictly permitted by RFC 2616, but at any
>> rate, changing Mongrel to accept these kinds of HTTP headers was a
>> single character change in the Ragel parser, viz.:
>> From a cursory
>> reading of RFC 2616 I don't see that a carriage return character there
>> should be illegal, but as Jon Postel was once quoted as saying: "Be
>> liberal in what you accept, and conservative in what you send."
"\r" is a control character and is not allowed in field values. This
also has the potential to break things with 3rd party libraries and
applications because it's not allowed by HTTP.
I consider stopping bad things early in the pipeline a good policy:
The kernel I use enforces TCP and doesn't allow corrupt IP packets to
get to Mongrel. Thus Mongrel doesn't have to worry about
bad/malicious TCP traffic.
Along the same lines, Mongrel enforces HTTP, so the application
doesn't have to worry about non-compliant HTTP traffic at all.
> "Be liberal in what you accept, and conservative in what you send."
> Sadly (to my perspective), this is definitely not the philosophy of
> Mongrel, and the mongrel development 'community' (does it exist?) is not
> partial to it.
I believe that philosophy leads to huge compatibility issues down the
line. It makes proliferation of a new technology easier and faster
("worse is better"); but HTTP has already "won" as a protocol and
fortunately most clients do a pretty good job (unlike with HTML and
HTML authors vs parsers).
> I've run into other malformed HTTP requests in other circumstances, and
> the solution I ended up with was using Apache rewrite maps to "fix"
> those malformed requests before they even get to mongrel. I'm not sure
> if that solution would work for this particular error, but sounds like
> you've found another one.
There was a bug we fixed last year where the parser was too strict with
certain requests made by IE. Other than that, I don't believe there
has been any changes to the way the parser behaves.
> I wouldn't hold my breath for that patch to be incorporated in mongrel
> though, the mongrel philosophy seems to be to be conservative in what it
Not speaking for the rest of the team, but I'm very much against this
More information about the Mongrel-users