I'm not sure I understand your suggestion. I also don't see what the fuss is about.
Try this out on linux. You'll see that the path /home/user/blah is the same as ////home///////user/////blah. If somebody can point me out a very clear rule in the URI spec (or anything else) that proves this is wrong (and thus linux, apache, and many others are in violation of the URI spec), then I'll happily shut up. :-) Otherwise, I don't think we need to be so anal about this issue. Like Alin said, we should be more pragmatic about this if we want a wide audience to use Pax Web. Unless I'm overlooking something, this is not a case where being more tolerant can cause any danger. Just my 2 yen. Like I wrote in the Jira issue, I think it's a reasonable approach to be strict by default, but to allow the option to be tolerant. Is that an acceptable compromise? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Alin Dreghiciu Sent: 27 September 2007 22:08 To: General OPS4J Subject: Re: [issues] Commented: (PAXWEB-41) Ignore slashes in the middle of aURL I agree with Niclas, and that's why I did not suprt that in the first place. You may recall the mails from when Pax Web was built. But on the other hand I see that people are not using Pax Web for such a reason so I'm wondering about a wise decision here. Actually I was looking to bring the following into consideration: Yesterday when I implemented the trimming of slashes at first I did that for both a servlet registration and resource registration. But the trimming of slashes from servlet registration proved that it actually brake the department store sample of pax wicket, which I did not seen comming. So, pax wicket/wicket actually expect to have this double slashes overthere, otherwise will not work. So, there is no trimming if the request matches a servlet registration. Now, actually what I changed was for handling resources. Those paths get trimmed. So, I suggest that we always pass the requested path "as is" including multiple slashes and we change the default http context implementation to trim those spaces while looking for a resource in the bundle. WDYT? Now, if someone has it's own http context then they should do that by their own. Alin On 9/27/07, Niclas Hedhman (JIRA) <[EMAIL PROTECTED]> wrote: [ http://issues.ops4j.org/jira/browse/PAXWEB-41?page=com.atlassian.jira.plugin .system.issuetabpanels:comment-tabpanel#action_10794 ] Niclas Hedhman commented on PAXWEB-41: -------------------------------------- I am not happy to see this being done. I am a strong supporter of following the spec to the letter, and R4:102.4 says; "When an HTTP request comes in from a client, the Http Service checks to see if the requested URI matches any registered aliases. A URI matches only if the path part of the URI is exactly the same string. Matching is case sensitive." So, the double slashes in the "alias" part are not to be handled other than "as-is". And for resources the part right of the matched alias, is passed to the HttpContext.getResource() also as-is. For this the HttpContext decide what to do with the extra slashes. I can't find any reference to what is must/should do. IMHO, we should fix the problem in Pax Wicket instead, and *perhaps* provide a "Redirect" rule in Jetty that people can enable, which redirects the browser to the URL without the extra slashes. But this is a separate feature that probably need a lot of further discussion. > Ignore slashes in the middle of a URL > ------------------------------------- > > Key: PAXWEB-41 > URL: http://issues.ops4j.org/jira /browse/PAXWEB-41 > Project: Pax Web > Issue Type: Bug > Reporter: David Leangen > Assignee: Alin Dreghiciu > > As discussed somewhat in http://issues.ops4j.org/jira/browse/PAXWEB-31, a URL should ignore extra slashes in the middle of a URL. > In other words, the following URLs should both resolve to the same resource: > http://host/path/to/resource > http://host/////path///////to///////resource -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.ops4j.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman /listinfo/general
_______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
