Documentation and a work-around for a strange problem that I thought should be at least archived on the sail-dev list.
>Hi Stephen, > > I was able to reproduce the error that you mentioned, but I do >not know why this error occurs or how to fix it. > > Is -H 'User-Agent:' a proper usage of curl? All the stuff that >I've found so far online has something after the colon. What does >'User-Agent:' mean? > > Another thought: how about curl -i -A ><http://tels-develop.soe....>http://tels-develop.soe.....? The curl commands below are just examples for you to easily duplicate the problem. Normally curl always sends a User-Agent header. The "-H 'User-Agent:'" parameter removes this header from curls communication. See this page for an explanation of the User-Agent header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43 At 1:27 AM -0500 2/11/07, Paul Burney wrote: >Stephen Bannasch <[EMAIL PROTECTED]> on Saturday, February 10, >2007 at 21:17 +0000 wrote: >Have you ever seen this kind of problem before? > >No, but since the problem doesn't occur with other requests on that >tomcat server, it would appear to be the servelet that is returning >the JNLP file. I'd guess that the servelet is doing some kind of >sniffing based on the user-agent string to determine which >JNLP/properties to return to the user, maybe to avoid browser bugs >or maybe to provide platform specific features. At 10:37 PM -0800 2/10/07, Hiroki Terashima wrote: >messing around with curl a bit more, I found that > >curl -i -H 'User-Agent:' ><http://wise.berkeley.edu>http://wise.berkeley.edu works > >curl -i -H 'User-Agent:' <http://hiroki-prod.wisetest.org> >http://hiroki-prod.wisetest.org (tels-develop) works > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu>http://tels-develop.soe.berkeley.edu >works > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080>http://tels-develop.soe.berkeley.edu:8080 > >works > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/ > >works > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp > >doesn't work > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/authoring-everything-snapshot.jnlp>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/authoring-everything-snapshot.jnlp > >doesn't work > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/sessionConfig.xml>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/sessionConfig.xml > >works > >so it seems like a problem with the jnlp files. > >Hiroki Probably not the jnlp files themselves but the Java webstart servlet and how it responds to requests for those files. It shouldn't produce a 500 error in response to the lack of a User-Agent header so it's a bug. I've been able to implement a work-around by 'monkey-patching' the Net::HTTPGenericRequest Ruby library class. As long as any User-Agent header is present the request complete's without error. It can be very helpful to use a language where classes can always be re-opened. I could have changed the library directly but then my fix would only work on the computers with the patched library. Instead in the sds I reopen the Ruby library class and redefine just the method which initializes the headers used for all HTTP requests. This following code is now in the startup section: # Monkey patch Net::HTTP so it always provides a User-Agent # if the request doesn't already specify one. # This compensates for a bug in the tels-develop webstart server which # throws a 500 error for requests w/o a User-Agent header. class Net::HTTPGenericRequest include Net::HTTPHeader def initialize(m, reqbody, resbody, path, initheader = nil) @method = m @request_has_body = reqbody @response_has_body = resbody raise ArgumentError, "HTTP request path is empty" if path.empty? @path = path initialize_http_header initheader self['Accept'] ||= '*/*' self['User-Agent'] ||= 'Ruby' # this is the new line @body = nil @body_stream = nil end end >Hiroki > >On 2/10/07, Stephen Bannasch ><<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote: > >Hi Hiroki, > >There is an annoying bug (??) in the tomcat server on ><http://tels-develop.soe.berkeley.edu:8080>tels-develop.soe.berkeley.edu:8080 >that serves up the jnlps. If I >make an HTTP GET request and do NOT include a 'User-Agent:' header >the server responds with a 'HTTP/1.1 500 Internal Server Error'. > >Let me know if you can fix this. It's getting in the way of >converting the SDS to jruby. > >You can test this yourself with the following curl commands: > >1) This command works. Curl automatically sends the following header >in the request: > >User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 >OpenSSL/0.9.7l zlib/1.2.3 > >curl -i ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp > >2) This command produces a 500 error from the server. Adding the >header option and leaving a null string to the right of the colon: >"-H 'User-Agent:'" causes curl to leave out the header in it's >request. > >curl -i -H 'User-Agent:' ><http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp>http://tels-develop.soe.berkeley.edu:8080/maven-jnlp-snapshot/plr-everything-jdic-snapshot.jnlp > >if you add the options "--trace curldump.txt" to the curl command you >can see curl's detailed trace in the file curldump.txt. >-- >- Stephen Bannasch > Concord Consortium, <http://www.concord.org>http://www.concord.org -- - Stephen Bannasch Concord Consortium, http://www.concord.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
