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

On 30/04/2014 2:47 a.m., Tsantilas Christos wrote:
> 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...

Do you mean ECAP is supposed to be receiving the syntax/protocol type of
the headers?

That means ...

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

 ... this ^^^ HttpMsg::http_ver ??

>>
>> * 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 - 19:31:29 MDT