- From: Josh <josh@early.com>
- Date: Mon, 11 Aug 1997 12:47:01 -0400 (EDT)
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: fielding@kiwi.ics.uci.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
ISSUE 1 - server hint for POST/chunked ISSUE 2 - what my problems are/were. SUMMARY - How I feel about re-raising this issue now. ISSUE 1 On the use of server version hint.. Even though you can look at the server version from a previous request, to determine if you are speaking to a 1.1 server (perhaps to do the chunked POST), you cant be sure that the version number is really what it said it was.. The issue is related to the 301/302 issue for POST redirects to GETs from CGIs. CGI/NPH may send their own response line, and advertise a different version than the server's own version. So, on a 1.1 server, if a CGI sends a 1.0 response line, no real harm, but if you looked at it to base your POST on, you would mistakenly assume that the server is 1.0. However, if the server is 1.0, and the CGI sends a 1.1 response, you would mistakenly send the POST/chunked and fail. Effectively, the server response version becomes the "URI" version number. Not entity version, and not server version. The only way to be sure, ( or surest ) IMHO is to use OPTIONS. Granted, Ive raised another fringe case, but the POST chunked is a fringe case, and it can be remedied by using OPTIONS instead of a previous request's server version advertisement. My point here is that it essentially makes this server version advertisement useless, therefore, philosophically, I beleive the response version should be the entity-version. The server implementors I have spoken to beleive that this hint, might be useful, and only 1 real example has come up. As a proxy implementor, the issue of figuring out what the entity version is and when I can send it to what version client is a real problem, that exists today, and life would be easier if the response version was something useful like entity-version. ISSUE 2 My original problems werent about the POST issue, but how a proxy would manage its cache. When it records the entity in the cache, it would have a complicated heuristic to determine the entity version. Dealing with a messy version number and deciding when an entity that you got from a 1.0 request is OK to serve a subsequent 1.1 client request is tricky. If the client is 1.0 and the server is 1.1, the cache entry would be written as version 1.1, but you'd need to also store the client's original request version so you can correctly determine that it is, in fact, a 1.0 entity. If the client is 1.1 and the server is 1.0, then the response version is correct in indicating the entity version number. However, if the proxies UPGRADE all requests to *its* highest version number, then this problem mostly goes away. This is what RFC1945 says, and I think Roy has been saying all along. My previous impression was that a proxy would "Downgrade on request" but that upgrading the request was not encouraged. (And others also had similar feelings). SUMMARY If the proxies are specified to UPGRADE the request to their highest version, then I can live with the current version spec. I still think that fundamentally, the entity-version is much more useful, than the ambiguous, unreliable server version hint, and that in a perfect world, the response version should be that.. ( the response entity version ) Time will tell if 'entity-version' or 'server version' is more useful, but if we stay our course and define the response-version to be the server-version, then we shouldnt hack things up to accomodate old implementations. My personal belief is that entity version is much more useful than server version to solve the problems that exist today. However, my personal opinions aside,it is late in the game and things mostly work. Therefore, as long as proxies upgrade their requests, I dont beleive that we absolutely must to change the response version to save the universe. (any longer) -- ----------------------------------------------------------------------------- Josh R Cohen /Server Engineer josh@early.com Netscape Communications Corp. josh@geeks.org (This message is sent from my private email account to reach me for business related issues, mailto:josh@netscape.com ) -----------------------------------------------------------------------------
Received on Monday, 11 August 1997 09:48:09 UTC