Parsing requests

Dave Makower writes:
 > From what I can tell, there is nothing in the specification of HTTP URLs
 > that prohibits a URL like the following:
 > 
 > http://myserver.me.com/some_container/?param1=value1&param2=value2
 > 
 > That is, a smart container that takes some parameters, which are passed in
 > via a query string in a GET request.  I'm finding that Jigsaw doesn't find
 > the appropriate resource when I do this. ("Target resource not found!")

I guess the trailing / is harmfull (that's a bug)

 > If I hunt around for a while, I can probably locate the class that actually
 > parses the URL passed in in the HTTP request and separates the query string
 > from the rest of the URL.  I was hoping, however, that you wouldn't mind
 > saving me some time and pointing me at the source file where this actually
 > occurs.

The class to look into is w3c.jigsaw.http.LookupState

 > There are two issues here.
 > 
 > 1) When a url like the one above is hit, the server needs to be able to
 > figure out the right resource and pass the parameters to it in the query
 > string.
 > 
 > 2) When the trailing slash on "some_container/" is omitted, the server
 > needs to create a relocation response that _includes_ the parameters,
 > rather than simply the plain URL of the container resource, otherwise the
 > parameters will be dropped, which is what currently occurs.
 > 
 > Is there a particular reason that Jigsaw doesn't implement this behavior
 > already?  It seems that it fits within the expected behavior of HTTP, or am
 > I missing something?

I think all this is correct, I am right in assuming that if I add the
query string when relocating (on a container resource), you're problem
is solved ?

Anselm.

Received on Thursday, 23 January 1997 12:47:09 UTC