On 25/06/2016 10:06 p.m., joe wrote: > thank for the debug option > without deny the POST i dont see any POST packet lol!!and it supose to to go > trough ecap right ?? Maybe yes, maybe no. > since all acl HTTP_STATUS_OK http_status 200 without any restriction should > present POST or GET im right or missing something That is correct. > and the debug > -- > 2016/06/25 13:42:46.640 kid1| 11,2| client_side.cc(2346) parseHttpRequest: > HTTP Client local=2.21.69.58:80 remote=10.4.4.61:58805 FD 11 flags=33 > 2016/06/25 13:42:46.640 kid1| 11,2| client_side.cc(2347) parseHttpRequest: > HTTP Client REQUEST: > --------- > GET /XignCode/PatchReal/oGHcjbcstNrSKR/List/current.rev HTTP/1.1 > Host: cdn.dominationsgame.com > Accept: */* > > > ---------- > 2016/06/25 13:42:46.773 kid1| 11,2| http.cc(2234) sendRequest: HTTP Server > local=192.192.192.212:7094 remote=2.21.69.58:80 FD 13 flags=1 > 2016/06/25 13:42:46.773 kid1| 11,2| http.cc(2235) sendRequest: HTTP Server > REQUEST: > --------- > GET /XignCode/PatchReal/oGHcjbcstNrSKR/List/current.rev HTTP/1.1 > Accept: */* > Host: cdn.dominationsgame.com > Cache-Control: max-age=259200 > Connection: keep-alive > You see how these are a "Client REQUEST" on arrival and a "Server REQUEST" on outgoing? The replies are the same, just in the other order. What we are looking for in that log now is the POST requests arriving, and what they look like on outgoing after eCAP (or not) has done its thing to them. You want to catch one that worked and one that did not and see what the difference is (if any). By that I mean the difference in both what Squid is changing and what the eCAP adapter is changing. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
