]> git.ipfire.org Git - thirdparty/squid.git/commitdiff
Fix eCAP to build after patch r13384
authorChristos Tsantilas <chtsanti@users.sourceforge.net>
Sat, 3 May 2014 10:53:56 +0000 (13:53 +0300)
committerChristos Tsantilas <chtsanti@users.sourceforge.net>
Sat, 3 May 2014 10:53:56 +0000 (13:53 +0300)
The HttpMsg::protocol removed with "Bug 1961: pt1: URL handling redesign" patch,
and as a result the eCAP squid subsystem does not build because used this memberto implement libecap::RequestLine and libecap::StatusLine classes.
The HttpMsg::protocol used to hold the protocol part of the request URI.
However the libecap::FirstLine::protocol() is meant for things like
 * the HTTP-Version part of HTTP messages (in RFC 2616 terminology) or
 * the ICAP-Version part of ICAP messages (in RFC 3507 terminology).
It is not related to the URI.

This patch fix this and now libecap::RequestLine and libecap::StatusLine
implemented to return the protocol information from request or status line
of headers.

src/adaptation/ecap/MessageRep.cc

index bb06ede8a56a4dee9a75ef13d8ce1a466651a830..cbca93693c4a6d585a547af2e3ca14d99c648de8 100644 (file)
@@ -135,7 +135,7 @@ libecap::Name
 Adaptation::Ecap::FirstLineRep::protocol() const
 {
     // TODO: optimize?
-    switch (theMessage.protocol) {
+    switch (theMessage.http_ver.protocol) {
     case AnyP::PROTO_HTTP:
         return libecap::protocolHttp;
     case AnyP::PROTO_HTTPS:
@@ -179,7 +179,7 @@ void
 Adaptation::Ecap::FirstLineRep::protocol(const Name &p)
 {
     // TODO: what happens if we fail to translate some protocol?
-    theMessage.protocol = TranslateProtocolId(p);
+    theMessage.http_ver.protocol = TranslateProtocolId(p);
 }
 
 AnyP::ProtocolType