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