[Mongrel] Invalid HTTP format, parsing fails

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


Zed,

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 (127.0.0.1): Invalid HTTP
format, parsing fails.
Fri Aug 25 20:01:09 EDT 2006: REQUEST DATA: "GET
/resolve?genre=article&issn=00224898&title=Journal+of+Terramechanics&volume=43&issue=4&date=20061001&atitle=Requirements+and+system+design+for+a+robot+performing+selective+cleaning+in+young+forest+stands.&spage=505&sid=EBSCO:aph&pid=Vestlund%2c+Karin%3bHellstr%C3%B6m%2c+Thomas>>2183092720061001aph
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:
_session_id=8999f072c7fcf77d13e741c9ee8faccc\r\nMax-Forwards:
10\r\nX-Forwarded-For: 24.98.252.118\r\nX-Forwarded-Host:
umlaut.library.gatech.edu\r\nX-Forwarded-Server:
umlaut.library.gatech.edu\r\n\r\n"
---
PARAMS: {"REQUEST_PATH"=>"/resolve", "REQUEST_METHOD"=>"GET"}
---

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:
http://umlaut.library.gatech.edu/resolve?genre=article&issn=00224898&title=Journal+of+Terramechanics&volume=43&issue=4&date=20061001&atitle=Requirements+and+system+design+for+a+robot+performing+selective+cleaning+in+young+forest+stands.&spage=505&sid=EBSCO:aph&pid=Vestlund%2c+Karin%3bHellström%2c+Thomas>>2183092720061001aph

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.

Thanks,
-Ross.

> 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