On Sun, 31 Jul 2005, Benjamin Carlyle wrote:
I've collected some research to date on several aspects of how the
protocol will be handled by proxies, but my chief unknown at present is
how the returned updates will be handled. My model is that a new 1xx
series return code be introduced to carry these messages, and that a
typical subscription consist of (request using SUBSCRIBE method (or
similar), 1xx response * n, final non-1xx response). My hope is that
these can be intermingled on a single persistent connection as follows,
in a conversation that is in some ways similar to pipelining:
1) SUBSCRIBE resourceA HTTP/1.1
2) receive 1xx response with initial state information for A
3) SUBSCRIBE resourceB HTTP/1.1
4) receive 1xx response with initial state information for B
5-n) receive 1xx responses intermingled for both A and B
This is not a valid HTTP sequence. There must be some form of non-informal
response to the first SUBSCRIBE requests before the next request can be
processed.
I know that proxies should pass the unknown SUBSCRIBE method through without interpretation
except for invalidating any associated cache entry. I understand that unexpected 1xx series
responses should be passed back to the client instead of being interpreted.
Not really. 1xx is hop-by-hop but usually forwarded end-to-end. Exception
is in case a request is upgraded by a proxy such that additional 1xx is
used not expected by the end client in which case these responses should
not be forwarded.
1xx also requires HTTP/1.1 which not all proxies are supporting yet. Squid
is still HTTP/1.0 (with persistent connections).
* Could a proxy timeout because it fails to receive a non-1xx-series response in an
appropriate time?
Yes.
Are there any other considerations for a single client and server with
the proxy in-between?
Yes. The proxy is quite likely to send the second request over another TCP
connection. The RFC strongly discourages proxies from pipelining client
requests, and also strongly states that connection management is
independent on client and server sides of the proxy.
* When multiple clients make subscribe requests to the same server through a proxy will
their calls be intermingled (pipelined?) such that the 1xx responses for one client might be
directed back to the other client? Are there starvation issues to consider here?
No.
But you must remeber that there is no client==connection relation when
using a proxy. Requests from all clients will be distributed among the
currently open connections to the server. So each connection will se
intermingled requests from various clients.
If you can think of any other major issues off the top of your head I
would also be grateful. I hope that what I will propose can work with
existing proxies well enough to allow a later upgrade path for proxies
to handle things more cleanly with explicit awareness of the request
method.
As long as you stay within the connection management rules of HTTP you
should be fine.
If HTTP connection management does not fit your needs then HTTP is not the
protocol to use.
For a protocol to work correctly over HTTP it must
a) Not depend persistent on connections. HTTP connections are by
definition hop-by-hop transport links, not end-to-end. (8.1.3)
b) Each request must be self-contained (logical from 'a') only relying
on it's own data and connected state information known to be possessed by
the server at the time the request was sent. If there is session sequence
dependency on other requests then a request must not rely on
information/actions not yet acknowledged by a non-informal message by the
server. (8.1.2.2)
c) Replaying of the same request should not be harmful if a safe or
indempotent method is used (9.1)
d) Slight reordering of requests may be expected. This applies both on
pipelined and requests sent over separate connections. A proxy is allowed
to split a pipeline and send the requests in parallell on separate
connections if it desires.
On a related side note Microsoft managed to violate both 'a' and 'b' when
they implemented their NTLM over HTTP authentication scheme (NTLMSSP
connection oriented messaging over HTTP for purpose of authentication),
resulting in a number of significant problems.
Regards
Henrik
