[Mongrel] Bare carriage returns in HTTP headers
evan at cloudbur.st
Tue Mar 24 20:21:33 EDT 2009
I am ambivalent, so I will defer to Eric.
On Tue, Mar 24, 2009 at 1:26 PM, Eric Wong <normalperson at yhbt.net> wrote:
> 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
> ref: http://mongrel.rubyforge.org/wiki/Security
> Eric Wong
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
More information about the Mongrel-users