Thierry, This work-around is perfect for my current needs, thanks.
-Matt On Nov 19, 2009, at 4:29 AM, Thierry Boileau wrote: > Hello Matt, > > the current directory is based on a mapping between extensions and media > types (see the javadoc of the method MetadataService#addCommonExtensions). > At this time, the extensions "jpe", "jpg", "jpeg" are all mapped with > the media type "MediaType.IMAGE_JPEG", with a preference for the first > one. This can be updated by calling the #addExtension(String, Metadata, > boolean) method. > This mapping does clearly not define a bijection, which leads to your > reported errors, in case the served directory contains already files > with "unpreferred" extensions such as "jpg" and "jpeg". > I've entered an issue for this: > http://restlet.tigris.org/issues/show_bug.cgi?id=953. > > Best regards, > Thierry Boileau > >> I have found some behavior that I think is incorrect when a jpeg is >> PUT to a Directory. I wrote a test server in groovy and a client in >> curl to illustrate the problem, see below. In summary, when a jpeg >> image is PUT into a Directory resource with a URL like >> http://host:port/tmp.jpg, the file extension gets changed to .jpe. A >> subsequent retrieval of the same URL does work, but directory listings >> show the "wrong" file name. Similarly, and the reason this is a >> problem for me, other programs that run on the server need to deal >> with the files with the same name that users PUT as the resource >> name. In this case, I need users to be able to overwrite a file >> called tmp.jpg that already exists in the directory. Instead, I wind >> up with two files, tmp.jpg and tmp.jpe. When the user subsequently >> request http://host:port/tmp.jpg immediately after they perform a PUT, >> they get the original image back, not the one that they just PUT to >> the system to replace the original. >> >> I suspect this might happen with other media types that have multiple >> valid extensions. >> >> I am testing against 2.0m5 for jse. I tried to test this with a >> recent checkout from svn, but building yielded some gwt errors I don't >> know how to work around. >> >> Is this a configuration problem on my end? Or could this be a bug? >> >> Thanks for your time, >> Matt >> >> //Groovy test server, I can rewrite this is java if necessary. >> import org.restlet.*; >> import org.restlet.resource.Directory; >> import org.restlet.data.Protocol; >> >> class TestDirApp extends Application >> { >> @Override >> public Restlet createInboundRoot() >> { >> def dir = new Directory(getContext(), 'file:///tmp') >> dir.modifiable = true; >> //dir.negotiateContent = false; //NB have tried this both ways >> println("Negotiating: ${dir.isNegotiateContent()}"); >> dir.listingAllowed = true; >> return dir; >> } >> } >> >> def component = new Component(); >> Server http = component.servers.add(Protocol.HTTP, 8181); >> component.clients.add(Protocol.FILE); >> Context workingCtx = http.context; >> def app = new TestDirApp(); >> component.defaultHost.attach(app); >> component.start(); >> >> >> #curl client >> curl -i --request PUT --data-binary "@tmp.jpg" --header "Content-Type: >> image/jpeg" "http://localhost:8181/tmp.jpg"; >> HTTP/1.1 201 The request has been fulfilled and resulted in a new >> resource being created >> Content-Length: 0 >> Date: Tue, 17 Nov 2009 16:23:00 GMT >> Accept-Ranges: bytes >> Server: Restlet-Framework/2.0m5 >> Connection: close >> > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2419969 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2420123
![http://localhost:8181/tmp.jpg"](http://localhost:8181/tmp.jpg"){kind=link}