[Sake Blok <sake@xxxxxxxxxx>]

On Fri, Jun 05, 2009 at 10:24:41AM -0400, Alan Snyder wrote:
> I'm looking at a packet that wireshark interprets as having 2 http
> headers. This packet between a piece of software and a http proxy
> (squid)... i'm trying to debug a connection problem. In wireshark,
> when i look at this first packet which is the http connect, there are
> 2 http headers! the first header lists
> 
> proxy-connect-hostname ...
> proxy-connect-port ...
> 
> ...and the 2nd seems to be the normal http fields...
> 
> CONNECT ...
> Host ...
> Upgrade...
> Connection...
> 
> What i'm trying to figure out is where the first header is coming
> from... looking at the packet i dont see any additional bytes which
> store this data. It seems to be extracted from real header.

If all is well, the proxy-connect-hostname/port headers should be
enclosed in "[...]", which means that the fields are indeed generated by
Wireshark, based on information found in the packet.

> It's
> confusing because it's listed as a completely separate header, after
> the TCP data. Here's the raw packet...
> 
> 0000  00 16 c7 ca a2 3f 00 14  4f 00 f2 72 08 00 45 00   .....?.. O..r..E.
> 0010  00 87 bc 1f 40 00 40 06  48 ee 0a 01 08 f5 0a 05   ....@.@. H.......
> 0020  18 69 ae 9b 76 2a 61 df  ec 85 37 ac b1 56 50 18   .i..v*a. ..7..VP.
> 0030  60 f4 35 dd 00 00 43 4f  4e 4e 45 43 54 20 31 30   `.5...CO NNECT 10
> 0040  2e 31 2e 38 2e 33 36 3a  34 32 36 20 48 54 54 50   .1.8.36: 426 HTTP
> 0050  2f 31 2e 31 0d 0a 48 6f  73 74 3a 20 31 30 2e 31   /1.1..Ho st: 10.1
> 0060  2e 38 2e 33 36 3a 34 32  36 20 0d 0a 55 70 67 72   .8.36:42 6 ..Upgr
> 0070  61 64 65 3a 20 54 4c 53  2f 31 2e 30 0d 0a 43 6f   ade: TLS /1.0..Co
> 0080  6e 6e 65 63 74 69 6f 6e  3a 20 55 70 67 72 61 64   nnection : Upgrad
> 0090  65 0d 0a 0d 0a                                     e....
> 
> Now, I have another packets that is practically identical to this one
> (except for checksums, timestamps, etc), and that one in wireshark
> only shows 1 http header...
> 
> 0000  00 16 c7 ca a2 3f 00 14  4f 00 f2 72 08 00 45 00   .....?.. O..r..E.
> 0010  00 87 bc 37 40 00 40 06  48 d6 0a 01 08 f5 0a 05   ...7@.@. H.......
> 0020  18 69 af 74 76 2a 66 4a  c1 4f 3e ce aa d2 50 18   .i.tv*fJ .O>...P.
> 0030  60 f4 35 dd 00 00 43 4f  4e 4e 45 43 54 20 31 30   `.5...CO NNECT 10
> 0040  2e 31 2e 38 2e 33 36 3a  34 32 36 20 48 54 54 50   .1.8.36: 426 HTTP
> 0050  2f 31 2e 31 0d 0a 48 6f  73 74 3a 20 31 30 2e 31   /1.1..Ho st: 10.1
> 0060  2e 38 2e 33 36 3a 34 32  36 20 0d 0a 55 70 67 72   .8.36:42 6 ..Upgr
> 0070  61 64 65 3a 20 54 4c 53  2f 31 2e 30 0d 0a 43 6f   ade: TLS /1.0..Co
> 0080  6e 6e 65 63 74 69 6f 6e  3a 20 55 70 67 72 61 64   nnection : Upgrad
> 0090  65 0d 0a 0d 0a                                     e....
> 
> ... it's the same http connect to the same proxy from the same host,
> so with respect to IP and TCP they're basically the same. I've been
> googling around for some insight but it's hard to google "http" since
> any urls listed in a web page are a match... uggh!

They should be listed the same indeed. The reason for the extra HTTP
header is that when the proxied connection is using the SSL protocol
after the initial HTTP connection, you are still able to filter on the
destination server ip and port.

Could you provide a capture file with two tcp sessions (one with one
header, the other with two headers)? Then I can have a look at the
different behavior.

(I used text2pcap on your text output, but then the behavior is not
visible unfortunately)

Cheers,
     Sake