From: "Rodent of Unusual Size" <[EMAIL PROTECTED]> Sent: Friday, November 09, 2001 5:10 AM
> 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. Since SSI is another beast, it accepts path_info and serves the page. 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. CGI authors have to deal with this issue in whatever way is appropriate, if they use path_info at all. Bill
