Robert,
Thanks for the clarification! Your thoughts make it more clear
that the scoping issue (already marked as unresolved!) plays a crucial
role here:
HTTP/OCP agents are not HTTP agents. They are not adapting
HTTP protocol as a whole. They are adapting isolated HTTP messages
only. They are not adapting HTTP connections, they are not adapting
1xx mechanism, they are not adapting HTTP cache, they are not adapting
TCP flow underneath HTTP connections, etc. HTTP/OCP scope is an atomic
HTTP message. Other OCP Core extensions can be written to adapt other
things if needed.
Furthermore, we acknowledge that HTTP introduces relationship
between HTTP messages. HTTP/OCP handles one kind of such relationship:
a given HTTP response being adopted is related to a single HTTP
request. This relationship is handled via optional original parts, a
negotiated HTTP profile feature.
The fact that _multiple_ HTTP responses may be related to a
single HTTP request when 1xx responses are present is acknowledged,
but is out of the draft scope. In other words, HTTP/OCP does not have
a mechanism to relate multiple HTTP responses to a single request as a
part of a single OCP transaction. It is possible to express that
relationship via OCP Core extensions, but the HTTP/OCP specification
does not do that.
Consequently, callout server (OCP server) MUST be able to
handle all HTTP responses, including 1xx responses. OPES processor
(OCP client) MAY NOT forward 1xx responses to a callout server. If
OPES processor forwards 1xx responses to a callout server, and
negotiated profile requires forwarding of request parts, then OPES
processor MUST forward those request parts. Informally, this means
that callout servers may receive identical request parts multiple
times: each time the processor forwards a 1xx response and one time
the processor forwards the final response.
Similarly, HTTP upgrade and other HTTP mechanisms are out of
HTTP/OCP scope. The OPES processor MAY forward HTTP message to the
callout server. Informally, this implies that the processor may
forward only a subset of messages. HTTP semantics related to messages
such as Continue or Upgrade is beyond HTTP/OCP specification scope.
Do you see what I am getting at? Will the above scoping rules work
well enough?
Alex.
P.S. The idea may become more clear if you consider adapting protocols
with a large number of control messages/dialogs. For example, the
same scoping rules above are meant to apply well to SMTP.
On Sat, 2003-11-22 at 02:58, Alex Rousskov wrote:
On Fri, 21 Nov 2003, Robert Collins wrote:
On Fri, 2003-11-21 at 08:59, Alex Rousskov wrote:
Huh? This seems orthogonal: the handshaking involved in rfc 2616
uploads is essentially a buffering mechanism, the adaptation device
must handle the client and server ends as per HTTP semantics. So
far, the callout protocols have no 'send / don't send' concepts in
them, so the semantics there are clear. The corollary is that 100
continue must (not MUST) be sent http/1.1 clients without delay, and
the adaptation device implement buffering before sending to the http
origin / delaying of reads from the client as appropriate for local
policy.
Robert,
I am sorry but I do not understand what you mean. Can you
rephrase please? We are trying to decide what to do when the origin
server responds with 100 Continue before sending 200 OK; there is no
mechanism in current OCP Core to handle multiple original application
messages for the same transaction.
Yep.
Are you saying that 100 Continue mechanism is essentially
external to HTTP messages being adapted? Like, for example, HTTP
connections or TCP ACKs are external to the messages that flow on
those connections -- we adapt messages and not the connections or
ACKs. If so, the suggested "MUST NOT forward" rule seems appropriate.
I guess I'm saying that things emerge from the OCP protocol and the http
protocol. Documenting them would make sense :}.
1) Information status messages MUST be dealt with in the HTTP
guidelines. That means that outside of the OCP environment, protocol
behaviour must be enforced by the adaptation client in whatever degree
of cooperation with OCP we design... That includes 100 continue, and 101
upgrade likewise, and ANY 1XX interim response. (RFC 2616 10.1 - all 1xx
status codes MUST be delivered to the client UNLESS a proxy initiated
the request for that particular 1xx response.)
2) 100 is a special case of these, where the semantics of uploads and
resource management requirements on a http-proxy-like device ensure
there will be some mechanism that can be exploited to implement the 100
semantics (From an external perspective)
3) 101 upgrade has ocp issues if the response circumvents OCP - as
a) the client will know they have switched
b) the OCP infrastructure won't [know they have switched].
c) respmod logic may not even be able to handle the upgraded protocol -
i.e. what if it's a rtsp stream? or a TLS encoded session? (And as more
servers support Upgrade to TLS, port 80 adaptation could be circumvented
quite easily (*))
4) all of the above are no more than special case ramifications of ANY
Http reverse proxy scenario : they are not unique to the adaption
environment, yet they will impact it heavily.
Or are you saying that 100 Continue messages must be forwarded
to the callout server for some reason?
Well I'm not sure.. thats the crux of it.
If you don't give OCP visibilty to 1XX series messages, then OCP cannot
(for instance) handle any messages that goes through a protocol upgrade.
Likewise, we place extra buffering overhead on the adaptation client
when it must treat the OCP subsystem as (for all intents and purposes)
an HTTP/1.0 client.
Conversely, if you expose the 100 and 101 messages (And any extensions
that involve 1XX messages - remember they MAY arrive unexpectedly), then
you may as well use http for OCP as you've just stuffed the remainder of
the protocol in there.
We've got an issue in squid, where I'm currently designing 100 series
message support, that relates to this, getting all 100 series messages
via the internal pipeline requires significant changes, to have a
multiple-response per transaction concept. 100-Continue is easy by
comparison, as it's literally no more than removing a status flag to
allow the clients req buffer to flow upwards - and issue a notification
to the client to effect the same.
(*) Which comes back to the trust issues discussed already, and the
issue of who is authoritative for the delivered content: if the adapting
device is authoritative, it should implement appropiate policy and
request transformations to ensure that upgrades to tls happen at it's
client facing side, not at the origins - which means it MUST have an
appropriate TLS certificate etc etc etc.
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.