ietf-openproxy
[Top] [All Lists]

RE: HTTP Adaptations issues for f2f discussion

2003-11-21 01:31:05

Hi Alex,


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.

Of course, sorry.
Although I had this in mind, I found that http_uri paragraph and got confused. 
Was somehow too late yesterday.

Did the above clarifies why no special handling is needed as far as
URI scheme is concerned?

Yes.


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).

Seems reasonable.


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?

Yes.



9. Concurrent request and response.

...

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.

OK, but let's somehow introduce that paragraph in a way that the reader 
understands again that most OCP services do not ask for request-body in 
response profile and that this is therefore not a common problem.


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?

Yes. Due to the lack of use cases and limited likelihood that someone will use 
this feature extensivly, we can probably do without the skip extension here.


Martin