Subject: RE: HTTP Adaptations issues for f2f discussion

From: "Martin Stecher" <[email-masked]>
Date: Fri, 21 Nov 2003 09:30:51 +0100

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