Re: [squid-users] https forward request

Thank you very much Henrik, now I have an idea what's the problem is. By the
way where can I find this client_side.c files?

Thanks

Mike

----- Original Message -----
From: Henrik Nordstrom <hno@marasystems.com>
To: Mike Pascual <mpascual@global3holdings.com>
Cc: Squid Users <squid-users@squid-cache.org>
Sent: Saturday, August 17, 2002 3:21 AM
Subject: Re: [squid-users] https forward request

> Mike Pascual wrote:
> > i'm sorry i forgot to include my interface, -i eth1
> > here's the information you needed..
>
>
> As suspected the final request sent by your browser is quite serverely
> malformed, and therefore rejected by Squid.
>
> Your trace contains 6 requests. The first 5 of them is looking alright,
like
> the following:
>
> T browser:1610 -> squid:3128 [AP]
> 43 4f 4e 4e 45 43 54 20 77 77 77 2e 73 70 65 65 CONNECT www.spee
> 63 68 6d 61 63 68 69 6e 65 73 2e 6f 72 67 3a 34 chmachines.org:4
> 34 33 20 48 54 54 50 2f 31 2e 30 0d 0a 55 73 65 43 HTTP/1.0..Use
> 72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61 r-Agent: Mozilla
> 2f 34 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 /4.0 (compatible
> 3b 20 4d 53 49 45 20 35 2e 30 3b 20 57 69 6e 64 ; MSIE 5.0; Wind
> 6f 77 73 20 39 38 3b 20 44 69 67 45 78 74 29 0d ows 98; DigExt).
> 0a 48 6f 73 74 3a 20 77 77 77 2e 73 70 65 65 63 .Host: www.speec
> 68 6d 61 63 68 69 6e 65 73 2e 6f 72 67 0d 0a 43 hmachines.org..C
> 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a 20 30 ontent-Length: 0
> 0d 0a 50 72 6f 78 79 2d 43 6f 6e 6e 65 63 74 69 ..Proxy-Connecti
> 6f 6e 3a 20 4b 65 65 70 2d 41 6c 69 76 65 0d 0a on: Keep-Alive..
> 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61 63 68 65 Pragma: no-cache
> 0d 0a 0d 0a ....
> ##
> T squid:3128 -> browser:1610 [AP]
> 48 54 54 50 2f 31 2e 30 20 32 30 30 20 43 6f 6e HTTP/1.0 200 Con
> 6e 65 63 74 69 6f 6e 20 65 73 74 61 62 6c 69 73 nection establis
> 68 65 64 0d 0a 0d 0a hed....
>
>
> The "Content-lentgh: 0" header is a bit dubious (technically should not be
> there), but it does not matter.
>
> But the last request in the trace is not looking that great...
>
> T browser:1612 -> squid:3128 [AP]
> 43 4f 4e 4e 45 43 54 CONNECT
> ##
> T browser:1612 -> squid:3128 [AP]
> 20 6d 71 31 77 65 62 63 32 2e 73 70 65 65 63 68 mq1webc2.speech
> 6d 61 63 68 69 6e 65 73 2e 6f 72 67 3a 34 34 33 machines.org:443
> 20 48 54 54 50 2f 31 2e 30 0d 0a 48 6f 73 74 3a HTTP/1.0..Host:
> 20
> ##
> T browser:1612 -> squid:3128 [AP]
> XX XX XX 2e YY YY 2e ZZ 2e ZZ 00 00 40 01 00 00 XXX.YY.Z.Z..@...
> 64 0a 85 00 64 0a 85 00 21 00 00 0d 0a 0d 0a d...d...!......
> ##
> T squid:3128 -> browser:1612 [AP]
> 48 54 54 50 2f 31 2e 30 20 34 30 30 20 42 61 64 HTTP/1.0 400 Bad
> 20 52 65 71 75 65 73 74 0d 0a 53 65 72 76 65 72 Request..Server
> 3a 20 53 71 75 69 64 2f 32 2e 34 2e 53 54 41 42 : Squid/2.4.STAB
> 4c 45 36 0d 0a 4d 69 6d 65 2d 56 65 72 73 69 6f LE6..Mime-Versio
>
>
>
> Problems:
>
> 1. The request is split in multiple packets (not a problem for Squid, but
> different from all the other requests).
>
> 2. The Host header is that of the proxy IP address. Not the requested
> destination servers like all other requests (again, not a problem for
Squid,
> but different from all the other requests)
>
> 3. The Host header ends with binary garbage. This is a problem.
>
> 4. None of the other requests headers send in the prior request is seen.
>
>
>
>
> You might be able to workaround the broken browser problem by commenting
out
> the "Requesthedar contains NULL characters" test in client_side.c
>
>
> #if IGNORE_THIS
> if (strlen(inbuf) != req_sz) {
> debug(33, 1) ("parseHttpRequest: Requestheader contains NULL
> characters\n");
> xfree(inbuf);
> return parseHttpRequestAbort(conn, "error:invalid-request");
> }
> #endif
>
> but I cannot guarantee this will work.. you might find that this triggers
> other apparent errors in Squid then as some parts of the code might
correctly
> assume that request headers do not contain binary garbage (specifically
null
> characters)
>
> Regards
> Henrik
>
Received on Fri Aug 16 2002 - 14:53:12 MDT