[Mongrel] Invalid HTTP format, parsing fails

Ross Singer ross.singer at library.gatech.edu
Fri Aug 25 20:08:20 EDT 2006


Thanks for getting back to me on this.

Here is the log from the offending request:

Fri Aug 25 20:01:09 EDT 2006: BAD CLIENT ( Invalid HTTP
format, parsing fails.
Fri Aug 25 20:01:09 EDT 2006: REQUEST DATA: "GET
HTTP/1.1\r\nHost: umlaut.library.gatech.edu\r\nUser-Agent: Mozilla/5.0
(Macintosh; U; PPC Mac OS X; en) AppleWebKit/312.8 (KHTML, like Gecko)
Safari/312.6\r\nAccept: */*\r\nAccept-Encoding: gzip,
deflate\r\nAccept-Language: en\r\nCookie:

Is this what you were looking for?

IE and Safari (and presumably other KHTML based browsers) don't escape
the ">>".  Gecko and Opera do.

Again, here's the URL:

The ">>" is the critical part.

On 8/25/06, Zed Shaw <zedshaw at zedshaw.com> wrote:
> On Fri, 2006-08-25 at 15:49 -0400, Ross Singer wrote:
> > While I agree with this fundamentally, pragmatically this is an
> > unrealistic expectation.  I get this vendor to fix it, another vendor
> > pops up with another dumb unescaped character.
> >
> It's most likely not a problem with unescaped characters but something
> else (I won't know until you send me the logs).
> > You can type these characters into the query string on IE or Safari
> > and get the same result, it wouldn't have to be vendor provided.
> Well, this is the problem:  almost all security attacks against web
> servers take advantage of how loose they interpret the protocol in order
> to handle user errors that really the browser should be dealing with.

I completely understand this.

> If you think about it, you have two situations:
> 1) Dumb user typing into a browser -- browser fixes it.

Except it's not.

> 2) Trained programmer writing an API -- follow the RFC.

Agreed.  But, again, YMMV.

> So the trade-off of being more strict is that a few folks who don't do
> either of the above have to go change their interactions.

Right.  I guess I'm just pointing out "real world behavior" that broke
mongrel.  But, yes, you're right, it's sort of 'encouraging' bad
behavior to adjust mongrel to it.

> > I am not 'blaming' anybody.  I'm just pointing out that it's a pretty
> > chaotic world and, as a result, it's fairly important that (within
> > reason) a webserver can handle the things that are thrown at it.
> >
> Yep, that's understandable, but it's also why so many other web servers
> get hacked so often.  The HTTP RFC is very complex, and the best way
> I've found to deal with it is to use a strict parser.

Sure.  Understandable.

> That being said, the parser has been wrong in the past so shoot me the
> logs and I'll look at how to update it.
> > My webserver is the one thing that /I/ can control.
> This also bring up another point, not every solution is right for every
> job.  Mongrel's the hot thing but I'm the first to suggest another
> solution if Mongrel doesn't work out, and have many times told people to
> not adopt Mongrel if they've got something that works.

Well, I liked mongrel for the simple fact that it's uber-easy to
deploy (and, until last night, I couldn't get fcgi to work, period).
If I'm helping another library install my app, the ability to say,
"Type gem install mongrel; gem install mongrel_cluster" and they're
basically running is a ton better than the alternatives.

I mean, yes, fcgi is working (and, like I said, this is new), but
'options' are nice.  Especially if a library is stuck Solaris or AIX
machine that they don't have much control on.

But,  yeah, I see both sides of this.


> If fcgi works then stick with it.  Another option you might like is
> litespeed:
> http://litespeedtech.com/community/wiki/doku.php?id=litespeed_wiki:ruby_rails
> It's fast, commercial, has support, pretty easy to setup and they do
> fast work.
> --
> Zed A. Shaw
> http://www.zedshaw.com/
> http://mongrel.rubyforge.org/
> http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users

More information about the Mongrel-users mailing list