httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]
Date Fri, 09 Nov 2001 20:19:56 GMT
> > john sachs wrote:
> > > 
> > > anyway, in doing so, i noticed that 1.3 serves the page
> > > as you'd expect.  in 2.0, you get 404.  which is "correct"?
> > 
> > 404 is most definitely not correct.  Adding a '/', optionally
> > followed by more data, to the end of a mapped filename is
> > perfectly valid and defines the 'path-info'.  1.3 seems to be
> > correctly differentiating between the resource and its path-info;
> > 2.0 is probably trying to treat the whole thing as a resource
> > and hence not finding it.
> 
> Yes, and no.
> 
> Since the default handler doesn't glom onto trailing path_info,
> it doesn't get handled.  All 1.3 pages I tested _without_ SSI's
> enabled returned 404.

Yep, that's what it is supposed to do.

> Since SSI is another beast, it accepts path_info and serves the
> page.

Yes, though I wish I could find a way to prevent if from doing so
if it did not expect path_info.

> It seems IBM's core handler was tweaked, and in doing so, exposed
> this hole.
> 
> > Code for a 200 return, and a response body that matches the
> > document's correctly-rendered (as opposed to raw) content.
> 
> That would be a good convention, against an SSI page.
> 
> The real issue is ending up with hundreds of robot hits (or goofy
> caching state) against a site with an infinite number of pages...
> 
> /index.html
> /index.html/hello?
> /index.html/are/you/there
> 
> etc.  A possible convention, against the core handler, would be an
> external redirect back to /index.html to keep all that cruft away.

No, those should be 404 unless .html is SSI.

> CGI authors have to deal with this issue in whatever way is appropriate,
> if they use path_info at all.

Likewise for JSP.

....Roy


Mime
View raw message