Re: /bzr/squid3/trunk/ r13384: Bug 1961: pt1: URL handling redesign

On 04/28/2014 04:57 AM, Amos Jeffries wrote:
> On 28/04/2014 5:35 a.m., Tsantilas Christos wrote:
>> Unfortunately this is not build with ecap.
>>
>> The ecap uses the HttpMsg::protocol, to describe protocol for both
>> requests and responses.
>> Looks that HttpReply::protocol was never set (Am I loosing something?).
>
> That is correct. HttpReply::protocol no longer exists.

>
>>
>> Is it a bad idea to replace HttpMsg::protocol with a virtual method,
>> which return HttpRequest::url.getScheme() for HttpRequest objects, and
>> HttpReply::sline.protocol for HttpReply objects?
>>
>
> Those two protocol details should be kept separate because replies do
> not have a URL or Scheme in their first-line. It is possible for the
> request URL scheme "protocol" to be anything, but the reply message
> syntax/"protocol" should always be one of HTTP 0.9/1.0/1.1 or ICY 1.0 at
> present.

Exactly. But for ECAP we are sending both requests and replies.

>
> What the eCAP field needs to be set to depends on its definition:
>
> * If it is sending the scheme/protocol of the URL *in* the message then
> it should be the url.getScheme() string on requests and a value
> signifying non-existent on replies

We are passing to ECAP reply or request HTTP messages. The HTTP reply
message, may have different scheme/protocol from the HTTP request cause
the reply.
For example to an https://.... request we may pass to ECAP an HTTP/1.0
or HTTP/1.1 reply because of the SSL-bump.

The protocol information included in HTTP replies. Currently we can
recognize only HTTP 0.9/1.0/1.1 or ICY replies but these are the only
replies which can be sent to ECAP...

>
> * If it is sending the scheme of the URL which the message was generated
> *for* then the reply has a "request" member which can be used to access
> the URL details of the request which triggered this reply.
>
> * If it is sending an indicator of what syntax message to parse, then
> the http_ver member should be used instead for both requests and replies.
>
> * If it is sending the on-wire protocol used to communicate with the
> current client or peer/server. Then we have nothing currently to signal
> that. I have one untested patch coming up but for now the best
> workaround that can be used is http_ver for both requests and replies.

My opinion is that we need to send to ECAP the scheme of the url for
HTTP requests and protocol information included in headers for replies.
At least as temporary solution to allow ECAP compile for now, which also
is compatible with the current behaviour.

A virtual method provides these information for HttpMsg objects, I
believe, it is a good solution.
If we have problem with definitions, we can name it with a name
different than the "HttpMsg::protocol()". eg
HttpMsg::estimatedProtocol() or something like this...

>
> Amos
>
>
Received on Tue Apr 29 2014 - 14:47:51 MDT