Community
Participate
Working Groups
Build ID: I20070222-0951 Steps To Reproduce: You can register a resource using the HTTP service e.g. at "/sample". If you try to access this alias e.g. "http://localhost/sample", then you will get an HTTP 500 code returned. Output is: HTTP ERROR: 500 C:\data\p\SSE\EclipseCon2007\wsp-play\org.eclipsecon.serverside.sample02\WebContent (Access denied) RequestURI=/sample Powered by Jetty:// More information: The expected behaviour would be to get an HTTP 403 (Access Denied) instead.
Yes the error should not be a 500. To clarify, this is when we're try to directly access a directory as a resource.
I've added a check for resources that end in "/" and 0 length resources that prevents the ResourceRegistration from handling the request and ultimately letting a default servlet if present handle the request. If no default servlet is present a 404 is returned. I actually prefer this behaviour as the directory as a pure resource is not present. This is also consistent with what both Tomcat and Jetty return when accessing a directory resource. -- Fixed in HEAD
Re-opening. I think we'll have to trap a 500 or similar error in the Http Service implementation, however I think the approach we've taken here is not correct. The Servlet spec says that it's up to the servlet container implementation to decide how to handle requests to a directory and in this case I think we've inadvertently hijacked control. "/" suffixed URLs should be legitimate and are up to the HttpContext to decide what resource to return. In addition, the 0 content-length check is not really valid; there's nothing inherently wrong with a 0 length resource.
Fixed in HEAD
Hmm, I still get 500 error when accessing directories. The fix is not trivial, though. We have to check if an URL resolves to a directory. Then, if we have a directory we need to make a decision ... should we return 403 or should we return a 404?
Created attachment 115131 [details] Patch for detecting directories The attached patch properly detects directories (even those which do not end with a "/"). The key is an FileNotFoundException which is thrown by URLConnection#openInputStream for directories and not accessible resources. The only downside is that it introduces a dependency on org.eclipse.equinox.common (FileLocator). But I used reflection to keep the dependency optional.
Gunnar, Can you describe your test case. I'm doing some simple sanity checks and am getting a mixture of 404s and 0 length 200 oks. Are you saying that "/" terminated directories URLs work correctly but not non-"/" terminated URLs? Which version of Jetty are you using?
(In reply to comment #7) > Can you describe your test case. I'm doing some simple sanity checks and am > getting a mixture of 404s and 0 length 200 oks. If the content length is 0 then everything is ok. However, I have a BundleURLConnection to a folder which returns 4096 as content length. Therefore, it's trying to deliver it as a file. > Are you saying that "/" terminated directories URLs work correctly but not > non-"/" terminated URLs? It doesn't matter. "connection.getContentLength()" returns 4096 for the URL which points to that folder. It could be a Windows specific problem, though.
(In reply to comment #7) > Which version of Jetty are you using? Sorry, forgot to mention. It fails with both (Jetty 5 as well as Jetty 6.1) from Orbit. Given the observations in comment #8, it might fail everywhere.
Created attachment 115143 [details] Sample project exposing the problem. Simon, if the folder has a bit more files, its content length goes from 0 to 4096 (at least on Windows Vista). Try with the attached project. There is a launch configuration which should work with a vanilla Equinox 3.4 SDK. http://localhost/bug176405
re: Sample project exposing problem + patch Thanks Gunnar. If only all my bugs were like this... ;) -- After a bit more investigation this only seems to be a problem on Vista (Not XP). What's happening is the underlying URLConnection is reporting 4096 bytes of content but then throwing a FNF when the inputStream is retrieved. In this case (and only the FNF case) I'm currently thinking that returning a 403 (Forbidden) indeed makes sense, but I'll need to try this out some more. As much as possible I want to keep things simple and so avoid any special treatment for directories. As a result I'm less inclined to do the apache redirect or detailed directory check. If need be one could write a specialized ResourceServlet to do this.
Created attachment 115151 [details] Patch for org.eclipse.equinox.http.servlet Simon, please find attached a simplified patch as discussed. It just catches FileNotFoundException and SecurityException and sends a 403.
Created attachment 115152 [details] Patch for org.eclipse.equinox.http.servlet Updated patch to not fail on closing the InputStream.
Marking FIXED. Thanks Gunnar, I've checked in a very slightly tweaked version of your patch that calls resp.reset() instead of just removing specific headers and also catches the potential IllegalStateException if the response is already committed. I did some manual tests without any problems but I'd appreciate it if you could also. More than ever it's apparent to me that we "need" to have automated test cases in place here to avoid regressions. I'll log a bug and set something up for 3.5.
Comment on attachment 115152 [details] Patch for org.eclipse.equinox.http.servlet Marking for the iplog. Thanks Gunner.
