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

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.

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

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

Amos
Received on Mon Apr 28 2014 - 01:57:21 MDT