[Mongrel] GET request works via curl, crashes from Java

Wed Jan 31 14:00:18 EST 2007

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