Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]

[Rodent of Unusual Size <Ke...@Golux.Com>]

"William A. Rowe, Jr." wrote:
> 
> 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.

Irrelevant.  It is perfectly possible and acceptable to submit
path-info to a resource that cannot handle it (e.g., a text/plain
file).  If we return 404 for that, we are broken -- period.

> > 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.

No, it is the correct answer, not a convention.

> The real issue is ending up with hundreds of robot hits (or goofy
> caching state) against a site with an infinite number of pages...

No, that is not the real issue.  The real issue is that we
are lying when we say 'not found'.  The robot hits issue is
separate and something of which to be aware and for which to
plan, but it does *not* dictate the correct behaviour of
the server.
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"

Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]

[john sachs <js...@covalent.net>]

right, so i'll hold off on writing the test for the moment.  once this gets all hashed out, if someone could just post what the correct expected results for

GET /index.html/
GET /index.shtml/
GET /index.cgi/

and if the result would vary for something like

GET /index.html/more/stuff

post what the expected behavior should be for that test too.
thanks.
-j

for what its worth, i thought GET /index.html/ should be 404 because it would seem the server would want to translate that URI to <DocumentRoot>/index.html/<DirectoryIndex>.  and since there is no directory called <DocumentRoot>/index.html, the resource would not be found.  make sense?

Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]

["Roy T. Fielding" <fi...@ebuilt.com>]

On Fri, Nov 09, 2001 at 03:16:03PM -0500, Rodent of Unusual Size wrote:
> Rodent of Unusual Size wrote:
> > 
> > "William A. Rowe, Jr." wrote:
> > >
> > > 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.
> > 
> > Irrelevant.  It is perfectly possible and acceptable to submit
> > path-info to a resource that cannot handle it (e.g., a text/plain
> > file).  If we return 404 for that, we are broken -- period.
> 
> Nrrgh, I take that back, at least temporarily.  Objections
> currently in abeyance while I check some stuff.. :-/

Good, because I was about to slap you silly.  ;-)

One of the goals of an HTTP server is to give the server owner control
over their http namespace.  Allowing every storage component to map into
an infinite number of URI is not desirable.  It isn't even desirable for
gateways like CGI, SSI, and JSP, though it is necessary in order for those
storage components to become dynamic handlers of collection resources.
Extra path info is therefore only valid for those components for which
handlers are defined that are capable of being collections (like mod_index)
or being a potential gateway to a collection.

This would be a lot easier for the server to determine if we had some sort
of config or module rec field that indicated the handler wants path info.
The default handler definitely does not want path info.

....Roy

Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]

[Rodent of Unusual Size <Ke...@Golux.Com>]

Rodent of Unusual Size wrote:
> 
> "William A. Rowe, Jr." wrote:
> >
> > 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.
> 
> Irrelevant.  It is perfectly possible and acceptable to submit
> path-info to a resource that cannot handle it (e.g., a text/plain
> file).  If we return 404 for that, we are broken -- period.

Nrrgh, I take that back, at least temporarily.  Objections
currently in abeyance while I check some stuff.. :-/
-- 
#ken	P-)}

Ken Coar, Sanagendamgagwedweinini  http://Golux.Com/coar/
Author, developer, opinionist      http://Apache-Server.Com/

"All right everyone!  Step away from the glowing hamburger!"