[Rabbit-dev] Proxy auth error

[Mindaugas Žakšauskas]

Hi,

Is here anybody using proxy authentication? The authentication
generally works apart from rare cases when it doesn't :)

I was trying to go to http://www.espnstar.com and got strange behaviour.
Scenario:
- entered username/password and tried to browse a site (OK)
- went to www.espnstar.com, all content got retrieved, but not fully (OK)
- at some point I was asked for u/p again. Entering u/p doesn't help,
proxy is asking these credentials again and again (FAIL)

Looking the logs, I can see following:

X.X.X.X - - 21/Jan/2011:23:17:59 GMT
"nnect-Enabled%20Plug-In%20%2832-bit%29%20%3BRealJukebox%20NS%20Plugin%3BWindows%20Media%20Player%20Plug-in%20Dynamic%20Link%20Library%3BMicrosoft%AE%20DRM%3B&AQE=1
HTTP/1.1" 407 380 [0, 3684]

<..>

X.X.X.X - - 21/Jan/2011:23:19:05 GMT
"%20G2%20LiveConnect-Enabled%20Plug-In%20%2832-bit%29%20%3BRealJukebox%20NS%20Plugin%3BWindows%20Media%20Player%20Plug-in%20Dynamic%20Link%20Library%3BMicrosoft%AE%20DRM%3B&AQE=1
HTTP/1.1" 407 380 [0, 3696]

It looks like the GET request is ill-formed or something. However if I
go to the site without proxy, it works. I have also tried to search
for any of these strings and got no luck.
Can anybody reproduce the same problem with their rabbit instance? Thanks.

m.

[Robert Olofsson]

On Fri, 21 Jan 2011 23:25:56 +0000

Post by Mindaugas Žakšauskas
Is here anybody using proxy authentication? The authentication
generally works apart from rare cases when it doesn't :)

Bugs that are hard to reproduce gives less bug reports :-)

Post by Mindaugas Žakšauskas
I was trying to go to http://www.espnstar.com and got strange behaviour.
...
X.X.X.X - - 21/Jan/2011:23:17:59 GMT
"nnect-Enabled%20Plug-In%20%2832-bit%29%20%3BRealJukebox%20NS%20Plugin%3BWindows%20Media%20Player%20Plug-in%20Dynamic%20Link%20Library%3BMicrosoft%AE%20DRM%3B&AQE=1
HTTP/1.1" 407 380 [0, 3684]

Yes, that definitely looks like the http parser has failed in reading the
request. Is there any pattern to this?

Is it possible to get any kind of wire trace for this? or is
it happening too seldom?

Can you sniff the traffic and see how one or two working header looks?

What it looks like is that the a persistent and pipelined connection
has used too much content and mistakenly read the first part of the
second header, causing the second header to start a bit late.

IF this is the actual bug, then I very much want to fix the problem,
but I may need some help in tracking it down.

That site seems to work well for me, but perhaps that depends on the
network between the client and the proxy or some other part of the
network.

Does that site work if you do *not* use any proxy authentication?

/robo

[Mindaugas Žakšauskas]

Hi,

Post by Robert Olofsson
Yes, that definitely looks like the http parser has failed in reading the
request. Is there any pattern to this?

Initially I thought this was caused by auth layer but it appears that
the actual culprit is the hotfix I did for "Request-URI Too Long"
problem (see earlier thread). So I should have replied to the previous
thread instead, sorry about that! Basically I have swapped jars
(removed the patch) and the problem has disappeared.

Post by Robert Olofsson
Is it possible to get any kind of wire trace for this? or is
it happening too seldom?

Quite seldom, I'd say. Now I have found out that this also happens for
itv.com. Maybe it is related to Flash presence?

Post by Robert Olofsson
Can you sniff the traffic and see how one or two working header looks?

Any preference on how you would like me to do it? tcpdump, wireshark,
httpfox, etc.?

m.

[Robert Olofsson]

On Sun, 23 Jan 2011 16:50:37 +0000

Post by Mindaugas Žakšauskas
Initially I thought this was caused by auth layer but it appears that
the actual culprit is the hotfix I did for "Request-URI Too Long"
problem (see earlier thread). So I should have replied to the previous
thread instead, sorry about that! Basically I have swapped jars
(removed the patch) and the problem has disappeared.

Ok, now I am a bit confused.
Is the problem present in the current release?
Is the problem only with a patched version?
Do the problem disappear if you run rabbit version X (for some value of X)?

Post by Mindaugas Žakšauskas
Any preference on how you would like me to do it? tcpdump, wireshark,
httpfox, etc.?

Not really, anything will work. If you do tcpdump you want to make sure
that you get all the content though.

/robo

[Mindaugas Žakšauskas]

Hi,

Post by Robert Olofsson
Ok, now I am a bit confused.
Is the problem present in the current release?
Is the problem only with a patched version?
Do the problem disappear if you run rabbit version X (for some value of X)?

Sorry for confusion and let me explain.

Originally I was using v4.7 when I got the "URI request too long"
issue. To which I have applied patch you have sent me.
So this problem occurs when running with the patch and does not when
running without (just bare v4.7).
Ignore the proxy auth bit, it was my original suspicion which was
misleading. But I am running with proxy auth on - both with and
without the patch.

If you want, I can try running it with the newest version of Rabbit.
Btw - I have just realized there's 4.9, did I miss the announcement?
Does 4.9 have the same patch incorporated?

Post by Robert Olofsson

Post by Mindaugas Žakšauskas
Any preference on how you would like me to do it? tcpdump, wireshark,
httpfox, etc.?

Not really, anything will work. If you do tcpdump you want to make sure
that you get all the content though.

OK, here's what I've done:
1. installed Wireshark (http://www.wireshark.org/). Great tool!
2. cleared browser history
3. entered www.espnstar.com to my URL bar.
4. I was asked for proxy auth where I have entered my credentials
5. most of the site has loaded, and at the end of it the
authentication pop-up came out again (looks like this was coming from
an external resource, e.g. Facebook script that was integrated with
the site or something).
6. launched Wireshark on my local box and started capturing
7. hit the refresh button
8. got the same behaviour as in #5, the only difference is that site
loaded much faster as most of the data was cached. This was later
proved by packet dump containing plenty of HTTP 304s.
9. stopped Wireshark capture session and filtered out all TCP
streams(*) apart from the one that had extra authentication popup
details. It appears that the offending bit actually doesn't come from
the original site conversations (espnstar) but from Facebook and/or
w88.go.com (see dump details).
10. Removed sensitive data from the dump (marked with XXXXXXXXXXX). If
this mailing list doesn't allow attachments, I am happy to put it
somewhere else.

(*) "TCP Streams" in Wireshark, as I understand them, are the
client-server conversations joined into one file. They should be
readable using a simple text editor when exported.

As I mentioned earlier, the same scenario can also happen if step 3 is
done against http://www.itv.com.

If you want, I can run a similar session with non-patched Rabbit v4.7. Or v4.9.

m.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: espn-auth
Type: application/octet-stream
Size: 9012 bytes
Desc: not available
URL: <http://khelekore.org/pipermail/rabbit-dev/attachments/20110123/5d14b32b/attachment.obj>