Your message dated Sun, 09 Dec 2007 08:28:49 -0300
with message-id <[EMAIL PROTECTED]>
and subject line Closing very old bug which seems not to be present anymore
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: libwww-perl
Version: 5.69-3
Severity: normal
*** Please type your report below this line ***
Hello,
There is visibly a bug in the LWP package.
I discovered that POST with the "-C" option doesn't work all the time.
Yes, a nice non-deterministic stuff!!
The credentials I used are ':admin', meaning no username, only a
password.
Before finding a workaround I had to write a script that repeated the
POST
command till POST behaved correctly.
You'll see the script, with a 1s pause in the loop for better
interpretation
of the tcp dump.
You'll see 3 first wrong attempts of POST then a correct one in 2 steps:
first without authentication neither data form followed immediately
by a second successful attempt.
This is NOT due to the server side as the server responses were exactly
the same but the POST requests were different! (data form attached or
not)
The full trace is available at http://www.teuwen.org/files/post-fails
I tried this stuff on a laptop & a desktop,
both with KNOPPIX + apt-get install libwww-perl
Here is the bash script I ran:
while [ $TRY == 1 ] ; do
echo -n "wl_ssid=none&wl_key=1&wl_key1=&wl_key2=&action=Apply" | \
POST -C ':admin' \
http://$AP_IP/linksys.cgi 2>/dev/null|grep "have been saved"
>/dev/null \
&& { echo -e "\nSettings should be set"; TRY=0;} \
|| echo -n ".";
sleep 1
done
Observing TCP streams around the POST:
Packet 11 @6.01s) POST /linksys.cgi
including the form but without authentication:
=> POST /linksys.cgi HTTP/1.1.
TE: deflate,gzip;q=0.3.
Connection: TE, close.
Host: 192.168.1.1.
User-Agent: lwp-request/2.01.
Content-Length: 52.
Content-Type: application/x-www-form-urlencoded.
.
wl_ssid=none&wl_key=1&wl_key1=&wl_key2=&action=Apply
<= HTTP/1.0 401 Unauthorized.
Server: httpd.
Date: Thu, 01 Jan 1970 00:00:12 GMT.
WWW-Authenticate: Basic realm="Linksys WRT55AG".
Content-Type: text/html.
Connection: close.
.
<HTML><HEAD><TITLE>401 Unauthorized</TITLE></HEAD>
<BODY BGCOLOR="#cc9999"><H4>401 Unauthorized</H4>
Authorization required.
</BODY></HTML>
But POST exits without further attempts with the following error
message:
<HTML>
<HEAD><TITLE>An Error Occurred</TITLE></HEAD>
<BODY>
<H1>An Error Occurred</H1>
500 Can't read entity body: Connexion ré-initialisée par
le correspondant
</BODY>
</HTML>
The error code looks different!!
Server replied 404 and POST says 500
Packet 22 @7.51s) idem
Packet 33 @8.96s) idem
Packet 44 @10.35s) Now the form is not included (neither the
authentication)
=> POST /linksys.cgi HTTP/1.1.
TE: deflate,gzip;q=0.3.
Connection: TE, close.
Host: 192.168.1.1.
User-Agent: lwp-request/2.01.
Content-Length: 52.
Content-Type: application/x-www-form-urlencoded.
.
<= HTTP/1.0 401 Unauthorized (as usual)
Packet 55 @10.41s) form & authentication are included, response is OK
=> POST /linksys.cgi HTTP/1.1.
TE: deflate,gzip;q=0.3.
Connection: TE, close.
Authorization: Basic OmFkbWlu.
Host: 192.168.1.1.
User-Agent: lwp-request/2.01.
Content-Length: 52.
Content-Type: application/x-www-form-urlencoded.
.
wl_ssid=none&wl_key=1&wl_key1=&wl_key2=&action=Apply
So we see the last call to POST worked corectly, the first attempt
fails because there is no authentication (but the form in not sent
neither)
then POST reacts immediately and sends the request with authentication.
The workaround I'm using currently is to replace
POST -C ':admin'
by
POST -H 'Authorization: Basic OmFkbWlu'
Phil.
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux hypocras 2.4.22-xfs #1 SMP Fr Sep 19 17:55:45 CEST 2003 i686
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Versions of packages libwww-perl depends on:
pn libdigest-md5-perl Not found.
ii libhtml-parser-perl 3.28-3 A collection of modules that
parse
ii libhtml-tree-perl 3.17-1 represent and create HTML syntax
t
ii libmime-base64-perl 2.20-1 MIME/Base64 decoding for Perl
ii libnet-perl 1:1.16-1 Implementation of Internet
protoco
ii liburi-perl 1.23-1 Manipulates and accesses URI
strin
ii perl [libmime-base64-perl] 5.8.0-18 Larry Wall's Practical Extraction
ii perl-modules [libnet-perl] 5.8.0-18 Core Perl modules.
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,
This bug is very old (4 years), and I cannot reproduce it with current
versions of libwww-perl (stable and testing), so it seems not very
useful to leave it open. From what I observe, it doesn't send the
credentials on the first try as a security measure, only after receiving
a 401 response with the WWW-Authenticate header it retries with the
Authorization header present, and it does consistently.
My guess is that maybe the problem was in the linksys stuff, not sending
the appropriate headers; and tcpdump is not the best tool here, POST can
give enough debugging:
$ echo -n "test=1" | POST -C :admin -SeUd http://myhost/
POST http://myhost/
Authorization: Basic OmFkbWlu
User-Agent: lwp-request/2.07
Content-Length: 6
Content-Type: application/x-www-form-urlencoded
POST http://myhost/ --> 401 Authorization Required
POST http://myhost/ --> 401 Authorization Required
Connection: close
Date: Sun, 09 Dec 2007 11:21:22 GMT
Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch7 mod_ssl/2.2.3
OpenSSL/0.9.8c mod_perl/2.0.2 Perl/v5.8.8
WWW-Authenticate: Basic realm="Usuario Kwiki"
Content-Length: 559
Content-Type: text/html; charset=iso-8859-1
Client-Date: Sun, 09 Dec 2007 11:21:22 GMT
Client-Peer: 200.69.248.17:80
Client-Response-Num: 1
Client-Warning: Credentials for '' failed before
Title: 401 Authorization Required
here it fails, because I obviously passed the wrong credentials. But as
you can see, there are two 401 responses. Only in the second try it sent
the credentials.
Please, if you can reproduce this bug again, reopen it.
--
Martín Ferrari <[EMAIL PROTECTED]>
signature.asc
Description: Esta parte del mensaje está firmada digitalmente
--- End Message ---
