On Thu, 20 Nov 2003, Martin Stecher wrote:
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.
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?
I agree that we do not have to provide explicit negotiation at this
time (though I disagree that Content-Type is the excuse here;
Content-Type is [ab]used for _encoding_ here).
I think we must document the issue somewhere to warn implementations
that they may see these responses.
Finally, I think it is a security consideration! I may be able to
bypass OPES filters by constructing a request with two ranges
that cover the entire resource being requested. If the server
does not merge (I do not think it has to), I will get the entire
response while some OPES entities will not be able to handle it.
In fact, requesting a resource part by part can probably fool many
OPES entities even if we add Content-Type negotiation. We must
document this. (Removing Range headers from the request is a solution
but is an ugly one because things like PDF viewers will be screwed big
time by that -- Squid proxy had a long history of fighting with those
issues).
5. FTP -> HTTP
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.
and that there is not HTTP connection on the server side. We do not
care about HTTP connections for now, but some extensions might. But
let's not document that, I guess.
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.
I hope you misinterpret RFC 2616! Request-URI is defined as:
URI = "*" | absoluteURI | abs_path | authority
and absoluteURI comes from generic RFC 2396
http_URL is just one documented case (do document HTTP access
semantics such as default TCP port numbers).
IMO, OCP/HTTP applies to any URI scheme as long as message is
HTTP-formatted.
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.
Did the above clarifies why no special handling is needed as far as
URI scheme is concerned?
6. 100 Continue
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.
So, for now, should we say that 100 Continue MUST NOT be forwarded to
callout servers unless their adaptation is negotiated? (and thanks for
the ICAP info).
7. CONNECT method
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.
The latter seems inconsistent. Should we document that both requests
and response are subject to adaptation but the tunnel is not?
9. Concurrent request and response.
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.
I do not have such use cases.
ICAP/1.0 does not support request-body encapsulation in RESPMOD,
so there are no existing services for this feature.
Right.
Is it a good moment to remove support for this application message
part from request profile?
That would be another blow to OCP/HTTP "theoretical" coverage of HTTP
protocol, in addition to "100 Continue" non-support.
How about documenting this deadlock and requiring that OCP agents are
able to handle it like any other resource-limitation issue? Either
OPES processor or callout server can terminate the transaction if the
request body gets too long. Document this as a security concern as
well.
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 ;-)
True. Still, I do not want to drop coverage of potentially useful
cases just because there are some corner cases that can be abused.
Will the above "treat it like any other resource-limitation issue"
loophole work?
Thank you,
Alex.