Thanks for all the suggestions. Wireshark and tcpdump work well together. I can reproduce the problem. When a client makes a GET request and intends for my application to return a REST resource in XML format it should look like this (or derivations thereof):
curl -H 'Accept: application/xml' http://localhost:3000/1/offering/84/bundle/168/0 About 6 months ago when I first wrote the app using rails 1.1.x I had instead specified this as the header to pass to indicate a REST xml response from the app was appropriate: curl -i -H 'Content-Type: application/xml' http://localhost:3000/1/offering/84/bundle/168/0 That spec didn't last long (because it didn't actually make sense: a GET should describe what it accepts), I instead documented the first method as how to get the resource. The java program that uses these resources however still used the 'Content-Type' header when making a GET request. That worked in rails 1.1.x for two reasons: the only controller methods it was calling in this manner *ONLY* provided REST xml responses and these methods didn't use this rails idiom: respond_to do |wants| wants.html wants.xml end Instead they always returned an xml resource. In addition the interaction between webrick|lighttpd and rails 1.1.x didn't generate an error with this kind of request. So the flaw went undiscovered. Here's what seems to be a problem in the webserver/rails integration, making this kind of GET request: curl -i -H 'Content-Type: application/xml' http://localhost:3000/1/offering/84/bundle/168/0 Produces this response (the returned headers indicate success and the returned body indicates a 500 error): HTTP/1.1 200 OK Connection: close Date: Wed, 31 Jan 2007 18:24:44 GMT Content-Type: text/html Content-Length: 371 Status: 500 Internal Server Error Content-Type: text/html <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd";> <html> <body> <h1>Application error</h1> <p>Change this error message for exceptions thrown outside of an action (like in Dispatcher setups or broken Ruby code) in public/500.html</p> </body> Shouldn't 500 errors be reported in the first line of the HTTP headers? Is the wrong use of a header (and I would certainly agree that using 'Content-Type' in a GET makes no sense) reason for disallowing the request. If the answer is yes then it probably makes sense to return an error in the headers also. So my question now is: Should this incorrect use be trapped as an error? If the answer is yes is the current handling of the error correct? If the answer is no any suggestion on where I can look in the code to fix the patch or fix the problem. My specific problem now is that while we can easily update the Java program now that I've found the problem the application is designed to support the creation of learner portfolios and to view portfolios created they may need to be matched to the earlier jar files and of course those earlier jar files will use the wrong heder when making the REST GET request ... sigh ... I rather not have to keep using 1.1.6 much longer. Thanks again for any comments/ideas. -- - Stephen Bannasch Concord Consortium, http://www.concord.org _______________________________________________ Mongrel-users mailing list Mongrel-users@rubyforge.org http://rubyforge.org/mailman/listinfo/mongrel-users
