Hi,
here a few comments.
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.
I think that this is out of scope because it is a Content-Type thing.
Either an agent should handle these types or should not care, or
it has to try to get a request profile service into the traffic that
removes the support advertisement of partial content from the
HTTP requests.
Is this something we need to describe in the draft?
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.
Agreed.
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).
As you said, FTP over HTTP to native FTP transformation
has to be done by the last HTTP proxy server and has
nothing to do with HTTP adaptation of OCP.
The only difference to "normal" HTTP is that the URL starts
with ftp.
Since 3.2.2 of RFC 2616 specifies that a http_URL has to
start with "http:", OCP/HTTP does not apply which is a shame
because it works (if the service supports it). Other protocol
prefixes could also be there; it's not only for FTP.
Is there somewhere something said how HTTP proxies should
handle URLs that have another protocol prefix than "http:",
especially if they have another next-hop-proxy and do not
need to do protocol conversion? This could probably be
copied to our case.
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.
I agree that multipe origin am-ids would solve this issue best
but it seems to be the wrong timing to me to change the concept
now and allow them.
In ICAP/1.0 I have never seen an encapsulated 100 Continue
message. But this does not mean that there are no such messages.
I think that
a) most ICAP clients do not send 100 Continue messages to ICAP servers
and
b) most/some ICAP servers will simply return 100 Continue messages
unchanged
or apply some header filters usually without effect since those messages do
not have many header fields in praxis
While ICAP/1.0 has no transaction concept, it is o.k. to send two separate
RESPMOD messages, one for the 100 Continue and one for the final response.
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.
A typical ICAP/1.0 client would generate a REQMOD request for
a CONNECT request but would not try a RESPMOD request
for the response or tunneled data.
HTTPS proxies can generate REQMOD/RESPMOD messages for the
decoded HTTP of course.
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).
This is indeed a problem. Do we have use cases where a response profile
OCP service needs to see the original request body? Filters I can think of
that use the request-body part better belong to request profile.
ICAP/1.0 does not support request-body encapsulation in RESPMOD,
so there are no existing services for this feature.
Is it a good moment to remove support for this application message part
from request profile?
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?
Removing request-body part would solve this too ;-)
Regards
Martin