[Prev][Next][Index][Thread]

Followup on SEARCH URL's / processing GET forms

John,

  Thanks for the response, but I'm still confused...


>At 5:36 PM 1996-06-14, Glenn Iba wrote:
>>Greetings,
>>
>>  I've been trying to use GET and POST URLs in MAC-CL-HTTP and have been
>>running into a number of stumbling blocks.  I'd really appreciate
>>any help that anyone could offer!
>>
>>1. PROBLEM ONE -- GET
>>
>>   I have this kind of working using a :search URL, but am having
>>   trouble accessing the "search-keys".  I suspect there may be a
>>   bug in the search-keys parser -- it seems to be splitting at
>>   #\+ characters which are encodings for space, rather than the
>>   #\& characters which separate the name=value "fields".  Please
>>   somebody correct me if I'm misunderstanding the syntax, as I'm
>>   still a rank neophyte at HTTP protocol.
>
>Search URLs only take + as field delimiters.

Am I wrong to map general processing of GET forms onto SEARCH URL's ??
My experience with the syntax for GET form requests suggests that multiple
inputs are allowed, with name=value "pairs" delimited by "&", and "+" being
used to encode "space"s in text:

   name1=value1&name2=value2+morevalue2

for example.  Is this understanding incorrect?
OR are search URL's intentionally limited to processing a subset of
GET requests? If so, is there a more general way of handling GET's?

>
>You are applying the form url-encoding scheme in the wrong place.

I didn't apply anything anywhere.  I created an html GET FORM (with multiple
inputs) which caused Netscape to send a GET request to CL-HTTP.

The URL string (as seen in the Netscape 3.0b4 location box) was:

http://ibappc/cl-http/GlennTest/print-args-get?fullname=this+is+a+test&hidde
narg=hidden+text&submitname=Submit+Query

Then I looked at the resulting HTTP-SEARCH object (the CL-HTTP URL object
passed to my response function) and compared the following two fields:

URL:NAME-STRING:
"http://ibappc.gte.com/cl-http/GlennTest/print-args-get?fullname%3Dthis+is+a
+test%26hiddenarg%3Dhidden+text%26submitname%3DSubmit+Query"

URL:SEARCH-KEYS: ("fullname=this" "is" "a" "test&hiddenarg=hidden"
                  "text&submitname=Submit" "Query")


>
>Access the search fields with http:search-keys applied to the url passed
>into your response function.

The above HTTP-SEARCH object IS the URL that was passed to my response
function.  All I did was store the URL in a global variable so I could
look at it.  And (http::search-keys url) in the response function just
returns the same result as what's stored in the URL:SEARCH-KEYS slot.

Does this make my problem any clearer?

If SEARCH-URLs are the intended way of handling GET FORMS, then
I don't think the search-key mechanism is doing the right thing.
The results are not useful as parsed.
To do what I want I'll have to parse the argument string myself,
which shouldn't be too hard, and ignore search-keys.  I just thought
(and I'll volunteer to do it if I'm on the right track) that maybe
the search-key mechanism could be extended to handle multiple
inputs in GET's, so as to be more generally useful.

Let me know if this makes sense, or whether I have some fundamental
conceptual misunderstanding.

Thanks in advance,
Glenn







-------------------------------------------------------------
Glenn A. Iba
GTE Laboratories
40 Sylvan Rd., MS-44
Waltham, MA 02254

e-mail: giba@gte.com
phone: 617-466-4233