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