- From: David W. Morris <dwm@shell.portal.com>
- Date: Fri, 5 Jan 1996 14:07:19 -0800 (PST)
- To: HTTP Caching Subgroup <http-caching@pa.dec.com>
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