I am ambivalent, so I will defer to Eric.
Evan
On Tue, Mar 24, 2009 at 1:26 PM, Eric Wong <normalper...@yhbt.net> wrote:
> 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
>
--
Evan Weaver
_______________________________________________
Mongrel-users mailing list
Mongrel-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/mongrel-users
