RE-VERSION
Josh Cohen (josh@netscape.com)
Wed, 03 Sep 1997 18:28:19 -0700
This is a cryptographically signed message in MIME format.
--------------ms0B88AE5F29121E1105F8E686
Content-Type: multipart/mixed; boundary="------------273493159D631D6F7C3DE1D2"
This is a multi-part message in MIME format.
--------------273493159D631D6F7C3DE1D2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
--
-----------------------------------------------------------------------------
Josh Cohen <josh@netscape.com> Netscape Communications Corp.
http://people.netscape.com/josh/
"You can land on the sun, but only at night"
--------------273493159D631D6F7C3DE1D2
Content-Type: text/plain; charset=us-ascii; name="RE-VERSION-2.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="RE-VERSION-2.txt"
Greetings,
At Munich, we discussed the RE-VERSION issue. The issue is
should the response version be the server's version advertisement
or the message version.
After yet another heated discussion:), my impression is that
in the absence of a compelling bustage, the current
semantics should remain the same, ie response version = server version.
I also want to note, that (IMHO) most people felt that they
would prefer a message version, but at this stage, it was
too late to change it. (in the absence of a compelling bustage).
So, to close the issue, I'd like to get ready to last call this
issue. To do so, Id like to move forward, if the following
issues are deemed resolved:
(These are possible problems that we run into with the
current semantics, along with ways of making them work)
The current proposal:
Leave the version as-is, but clarify that proxies MUST upragde
all requests to the proxy's highest version.
Issues;
issue: cache-label: How does a proxy label a cache entry, and when can
it use the cache entry to satisfy subsequent requests.
solution: as long as the proxy always upgrades to the highest version,
it can be confident that it has the 'best response' in its cache
and can satisfy both http/1.1 and http/1.0 requests in the future.
issue: chunked POST: this was the only concrete use where
the server version is useful. Unfortunately, even 1.1 proxies/servers
may not support a chunked POST. Since this is a fringe case,
its not a show stopper either way. Another method, possibly
OPTIONS is necessary to determine if a chunked post will succeed.
solution: none as-is
issue: keep-alives in client
If you have:
1.1 client -> 1.0 proxy -> 1.1 server
The client will issue a 1.1 request, the proxy will downgrade it
to 1.0, and the server will respond with a 1.1 response.
(but 1.0 compatible, ie no chunked encoding )
The proxy will then blindly forward the response ( 1.1) back to
the client.
If the client was assuming persistent connections, but the 1.0
proxy doesnt support keep-alives, how should the client behave?
How can it recognize that its request path it really 1.0 and not
1.1?
Presumably, the client will assume 1.1 and that persistent connections
are OK, but the proxy willl be closing the connections after each
request.
solution: The client will recognize the closed connection ( at some point )
and re-open a new connection. Unfortunately, some clients will deal
with this in an extremely unpleasant manner, not recognizing the
closed connection immediately.
In general, how should the connection semantics be handled?
The client now beleives it has a 1.1 session, but in fact, it does
not.
issue: keep-alives in server
By default, persistent connections are supposed to be used in 1.1.
When a server receives a downgraded request from a proxy, which
came from a 1.1 client, should it respond with a connection: close?
Issue: (related) the draft says that connection and response version
are hop-by-hop, but it also says that a proxy may act as a 'tunnel'
at any time. These are contradictory, since proxies may downgrade
a request, but tunnel the response, which breaks the hop-by-hop
nature of response version.
--------------273493159D631D6F7C3DE1D2--
--------------ms0B88AE5F29121E1105F8E686
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIGvwYJKoZIhvcNAQcCoIIGsDCCBqwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BSYwggJlMIIBzqADAgECAgIEtTANBgkqhkiG9w0BAQQFADB3MQswCQYDVQQGEwJVUzEsMCoG
A1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsTE0lu
Zm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20wHhcNOTcw
NjE4MDMzNDM0WhcNOTcxMjE1MDMzNDM0WjCBhDELMAkGA1UEBhMCVVMxJjAkBgNVBAoTHU5l
dHNjYXBlIENvbW11bmljYXRpb25zIENvcnAuMRUwEwYDVQQDEwxKb3NoIFIgQ29oZW4xIDAe
BgkqhkiG9w0BCQEWEWpvc2hAbmV0c2NhcGUuY29tMRQwEgYKCZImiZPyLGQBARMEam9zaDBc
MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDOhb62VH0eutOs2TOSlez9LDZ/Npc7WOR0A/noE6GI
sVnEiwsa3smYNsXPNdMOrTV/IeLhIh2WMlog8lAxDGidAgMBAAGjNjA0MBEGCWCGSAGG+EIB
AQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau+hUMbsQukjANBgkqhkiG9w0BAQQF
AAOBgQCD8SxLEPSi8sO9sY3dUNOvFhrZe1IzQ/mPDWFKlMz8VnN+jyPXaL7rfmIhpAz2Q58W
tyU7x5qxw/pTbna9bYL+C/SWyXY6bKSvowl0adPrA0jxSkx1EmSwmpXSgSiotcSZhfWtmcBh
lw/xn5ImodY7lrgybtG3RV6sZAWjsODEVDCCArkwggIioAMCAQICAQEwDQYJKoZIhvcNAQEE
BQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENv
cnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290
Y2EubmV0c2NhcGUuY29tMB4XDTk3MDMyNjAxNDQzOFoXDTk5MDMyNjAxNDQzOFowdzELMAkG
A1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9u
MRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2Nh
cGUuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDBqj7+LT+lh8NH3/vabdgYoEU9
+cebQ84ntFoTnBF9v9LyiF7Hv7KLebqn5SgLQKaOmTFVxfjOlgZeIoR2vwEiYsOpmSe7CGgR
FMcKftyyh/jH4CQwAbwtloXnGcMuoZN3LDQYL/vfokiz56CvegPki4x1pC2TIIwgOVSnRbpA
ZQIDAQABo1UwUzARBglghkgBhvhCAQEEBAMCAAQwHQYDVR0OBBYEFPzgVOgH8ZXeOveZxq76
FQxuxC6SMB8GA1UdIwQYMBaAFPzgVOgH8ZXeOveZxq76FQxuxC6SMA0GCSqGSIb3DQEBBAUA
A4GBAFn32xtcegbE5sWYYYQYzvoGSyCxJMr8WX4/GPHkvqwQ2UrSaY9u/JHK9QQcCq65+so5
7E0AGaZnlMzlQFtZhCSS8AEsGeQLLzsc9g8bhUXsw5fx4LpAy91XcYngi0lwSR/dtss0b2/P
LyHkU9EZZo9nYvDd7h1IKvBHe4N0h3nIMYIBYTCCAV0CAQEwfTB3MQswCQYDVQQGEwJVUzEs
MCoGA1UEChMjTmV0c2NhcGUgQ29tbXVuaWNhdGlvbnMgQ29ycG9yYXRpb24xHDAaBgNVBAsT
E0luZm9ybWF0aW9uIFN5c3RlbXMxHDAaBgNVBAMTE3Jvb3RjYS5uZXRzY2FwZS5jb20CAgS1
MAkGBSsOAwIaBQCgfTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw05NzA5MDQwMTI4MTlaMB4GCSqGSIb3DQEJDzERMA8wDQYIKoZIhvcNAwICASgwIwYJKoZI
hvcNAQkEMRYEFNClVlgr1Z7imjqPf9ATXg1/f5vYMA0GCSqGSIb3DQEBAQUABEB0T8vnRJC7
luUHPxMvjYXg7d+NRZXo+f5auofLRxmcgeDLIrn/ugNWtN+WmyATDp5r2itb7VH0Y8Ldx33D
0rJB
--------------ms0B88AE5F29121E1105F8E686--