Re: transmission of large queries using GET URLs

On Fri, 5 Jan 1996, Jeffrey Mogul wrote:

> One could argue that this browser is buggy and ought to be
> fixed (and we did report it to the responsible party).  But

The bigger issue I think is that there will always be bugs which take
time to get fixes deployed.  Protocol changes to address bug 
induced limitations have little hope for success. IMHO, altavista is
so great that ya'll have the leverage to get users to switch browsers.
I would. I haven't looked closely at the altavista data stream but perhaps
something like shorter field names would help.

> it might not be reasonable to expect that indefinitely long
> URLs will be properly supported by all HTTP implementations,
> even though RFCs 1630 and 1738 do not give any length limits
> for URIs or URLs.  In other words, sooner or later the practice
> of encoding long queries in the URL of a GET might break.

There is apparently some kind of length limit for URLs specified
as attributes. I recall 1024 being mentioned and I recall comments
that it may have been raised but from that I would infer a fairly
generous size.
> 
> On the other hand, if the entire query is specified in the
> URL of a GET, then we don't have to include the request
> body of a method in the cache-matching key for such requests.
> 
> I'll admit that I can't think of a good answer to this dilemma.

I'm becoming slowly convinced that it may make sense to cache some forms
of entity bodies associated with requests (x-urlencoded for example).
Combined with my suggestion in another post to use the html form enctype
to tell the UA to use the body for GET transfer I think we could deal
with GET vs POST side-effects w/o a new method and largely withing 
existing standards/drafts.

From a caching perspective, of course in this case the body must be part of
the key ... I initially agreed with the concern that the likelyhood of
match was somehow lower than with a URL.  On further reflection, I have
concluded this probably isn't a large isssue:
1.  UAs are already free to compose the data associated with a GET URL 
    FORM however they wish so unless we impose a canonicalization
    requirement, different browsers are likely to provide different
    URLs.
2.  We are talking about a very tight coupling here between a prompting
    page containing a form and the input submitted.  Not about expecting
    that different pages/forms will somehow exist and need to share 
    cached results. Thus, at least within a single UA edition, I would
    expect consistant 'cannonical' ordering of the form data and some
    real hope of cachability, maybe.
However, it occurs to me that log data from altavista might provide a
bit of insight as to whether there is any point in caching such results.
Perhaps in the real world, there won't be enough commonality in what
users ask for to bother, even for a heavily used service.


Dave Morris

Received on Friday, 5 January 1996 22:18:42 UTC