Re: RE-VERSION

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