[Mongrel] Bare carriage returns in HTTP headers

Eric Wong 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  
> accepts.

Not speaking for the rest of the team, but I'm very much against this

ref: http://mongrel.rubyforge.org/wiki/Security

Eric Wong

More information about the Mongrel-users mailing list