|
|
cURL Mailing List Monthly Index Single Mail
curl-tracker mailing list Archives
[ curl-Bugs-2210686 ] Using NTLM proxy will lose form-data. Makes NTLM unusable.
From: SourceForge.net <noreply_at_sourceforge.net>
Date: Fri, 21 Nov 2008 10:56:02 +0000
Bugs item #2210686, was opened at 2008-10-30 23:10
Please note that this message will contain a full copy of the comment thread,
Initial Comment:
It basically makes libcurl's NTLM proxy unusable for us, because while it doesn't happen every connection, it happens more like 1/10 connections, and we fire off hundreds of connections. And sometimes it will reliably happen on a certain URL, meaning certain URLs are unaccessable.
This bug appears more often using the multi interface, especially when firing off one connection quickly after the last has been completed.
The timing seems to be the most important thing. A delay before one connection and the next, seems to make the bug less likely to occur. However, sometimes the bug always appears even if we are talking about the first connection. So this behaviour is quite random, but it appears to have something to do with timing, and reusing of connections.
This bug also appears in the curl command line tool. But it's much rarer probably because it doesn't reuse connections quite as often as an application will, due to the fact that the tool will quit and be reopened once per connection.
Here is my debug trace. I did this using libcurl, as a C API, so I tried to make my debug function output text like libcurl's although it's not exactly the same. What's the problem? No form data! I've removed sensitive information from this example by replacing with ****
== Info: Expire cleared
Proxy-Authorization: NTLM *************************
Host: *******.com
Pragma: no-cache
Accept: */*
Proxy-Connection: Keep-Alive
Content-Length: 0
<= Recv header: HTTP/1.1 200 OK
<= Recv header: Date: Thu, 30 Oct 2008 13:45:44 GMT
<= Recv header: Server: Apache/2.2.8 (Ubuntu) mod_jk/1.2.25 mod_ssl/2.2.8 OpenSSL/0.9.8g
<= Recv header: Keep-Alive: timeout=15, max=100
<= Recv header: Transfer-Encoding: chunked
<= Recv header: Content-Type: text/plain
<= Recv header: Proxy-connection: Keep-Alive
<= Recv header:
=> Send data
Sometimes, with the exact same connection code... I see this instead amoungst the (long) debug output.
"
------------------------------9ea4b9344a58
Content-Disposition: form-data; name="lea"
Content-Type: application/binary
le2
"
----------------------------------------------------------------------
>Comment By: Theodore H. Smith (boytheouk)
Message:
Basically, I had assumed that REALbasic is single threaded (that's what
Everything worked then! I have to create and destroy a multi handle in the
So that's great.
This bug is not really a bug, just an error in my code caused by not
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Message:
Do note that we now should deal with 7.19.1 since that's been released in
This report will therefore be set to 'pending' now.
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
However, we are working with some schools, who have NTLM networks set up,
That's what I've been told.
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Message:
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
The error I get from my server is: "Undefined 'lea'"
If you look for that text in the file: "5~" you'll see that line near the
At this point, I'm in the GUI seeing an error message of "The server gave
However... on "6~" we see that we DO send an "lea", and the server instead
So... I'm doing the same thing on 5 and 6. But 5 fails. I don't know why.
On some other URLs, no matter how many times I try to redo it, it fails.
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
I have curl in two places on the PC. I have curl.exe the command line
my curl.exe says: curl 7.19.0 (i586-pc-mingw32msvc) libcurl/7.19.0
my libcurl says: libcurl/7.19.0 OpenSSL/0.9.8h zlib/1.2.3 libssh2/0.18
Hopefully it doesn't make a difference. I am experiencing this
I am unable to find out if the problem appears with curl.exe, right this
I'm not sure this will help, because I am seeing the problem in
C:\Documents and Settings\Administrator\Desktop>curl.exe -V
The trace I gave you was a complete trace of a failiure. I didn't give
I'll have to work on getting you the code to replicate this. My current
Thanks a lot.
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Message:
I would like a more complete trace dump from the POST. Does it really only
I'd also like to see the code for a full app (as small as possible) that
Unfortunately, I don't personally have a NTLM proxy to try against.
----------------------------------------------------------------------
Comment By: Theodore H. Smith (boytheouk)
Message:
curl 7.19.0 (i386-apple-darwin9.5.0) libcurl/7.19.0 OpenSSL/0.9.7l
I also tried this on the PC. Same result.
curl 7.19.0 (i586-pc-mingw32msvc) libcurl/7.19.0 zlib/1.2.3
Please let me know what other information is needed.
----------------------------------------------------------------------
Comment By: Daniel Stenberg (bagder)
Message:
----------------------------------------------------------------------
You can respond by visiting:
These mail archives are generated by hypermail. |
Page updated November 12, 2010.
web site info