Jonathan Rochkind <rochk...@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.:
<snip>
>> 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
patch.
ref: http://mongrel.rubyforge.org/wiki/Security
--
Eric Wong
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
