Hi,
Here are some open HTTP Adaptations issues that may be worth
discussing at the upcoming F2F meeting. I will skip issues already
documented as XXXs in the draft itself.
1. Security Considerations
Are there really no HTTP-specific considerations in OCP?
Do things like wrong Content-MD5 checksums belong here?
Also see #6,7,9 below; are those related to
security considerations?
2. Scope.
Do we need to clearly say (in one place) what it means
to adapt HTTP? Is HTTP connection adaptation in scope?
Is URL blocking or redirection in scope? Is HTTP
authentication (via callout services) in scope?
This sounds like a simple question, perhaps, but,
as usual, scope is one of the most difficult things
to define. See issues #3,5,6,7 below, for example.
They are all scope-related in some way!
3. Partial Content
Do we need to say anything special about adapting
"206 Partial Content" HTTP responses? There are
two cases here: multipart/byteranges media type and a
single "part" case.
multipart/byteranges are expressed via Content-Type,
not Content-Encoding. Thus, we currently have no
mechanism to negotiate support for those. On the
other hand HTTP does have such a mechanism for its
agents (if you do not support it, you do not ask
for multiple parts).
IMO, we should say something, even if we are not
going to provide explicit support for this
special content type.
4. Authentication and other sensitive information.
Do we need to specify whether authentication information
should be passed "as is" to callout servers by default?
IMO, it should be because we pass all other "sensitive"
information already. We should probably explicitly say
that the processor should treat any sensitive data as
regular data in this context (by default). This places
stringent requirements on callout server security and
trust, but that is how OPES is supposed to work.
5. FTP -> HTTP
HTTP proxies that proxy ftp://host URLs have to
do FTP and transform FTP messages to HTTP responses.
Do we need to mention this case in some way? Is it
special or out of scope (i.e., we assume that all
transformations have been already performed).
6. 100 Continue
100 Continue messages are sent as a part of an HTTP
transaction but they are not true "responses".
What should an OPES processor do about
these? Technically, they can be viewed as another
original application message to be adapted within
the same OCP transaction (multiple original am-ids)!
If we want to avoid multiple original am-ids, but
still want to adapt 100 Continue messages, we can
introduce a notion of "related transactions". Each
100 Continue would cause the processor to start
a new OCP transaction, related to the original
one (so that the request message does not need to
be resent). But, on a technical level, multiple
original am-ids is exactly what is going in here,
I guess.
We have to say whether processor must skip them.
If processor skips them, does it open a [security]
whole for clients or servers to bypass OPES. These
messages do not have bodies, but their headers can
be used to send information that OPES entities may
be interested in.
7. CONNECT method
CONNECT method establishes a tunnel through the
proxy. Should OPES processor adapt just the CONNECT
request and response, or should it stay in the loop
for the tunnel itself? If the processor stays, we
do not have a good mechanism in the current draft
to adapt a bi-directional tunnel, right?
Tunnel adaptation is more like streaming adaptation,
isn't it? That's an unchartered territory for OCP,
including OCP Core.
We have to be explicit what the processor is supposed
to do.
8. SIRs or HTTP WG review
Should we solicit SIRs and/or HTTP WG review of
this. There is no formal HTTP WG, but there is
a semi-alive mailing list that HTTP gurus read.
9. Concurrent request and response.
What happens when the HTTP client is sending a request
body _while_ the HTTP server is sending a response, and the
callout server requested HTTP request body to
adapt the HTTP response. Do we have a deadlock?
The above can happen when the HTTP server is
sending a constant response regardless of the PUT/POST
body or is sending an error message. For example,
an error message can say "I got 1MB of your POST
request and I will not accept any more. Go away!".
OPES has to adapt such a response, but it looks
like we cannot until the client stops and the
client may not stop for another 100MBs (because
it is broken/malicious or because it does not
get the error message that is waiting for our
adaptation).
10. Huge request bodies and RESPMOD
There is no way for the callout server to
skip a huge request body when doing RESPMOD.
Is that acceptable? Should OCP Core support
"skip N original octets" interface (that
does not affect offset/size calculations).
Should HTTP draft support "skip this part
until its end" interface? Instead?
N.B. Does ICAP address #3,5,6,7? ICAP does not have a problem
with #9 and #10 because ICAP does not allow sending request body
in RESPMOD, right?
Note that there are some synchronization issues between OCP Core and
HTTP drafts, but they are probably not worth discussing in public.
Also, some of the above issues might be too technical and
HTTP-specific for the f2f meeting. Again, please pick-and-choose what
you want to discuss.
Thank you,
Alex.
P.S. I think we should have thought of some of the above issues
earlier. On the other hand, I think we did discuss them briefly
but ignored when it came to writing the guts of the draft. I hope
we can "escape" them with little effort, but some look pretty
tricky to me.