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
