tags 379732 patch
thanks
> Via: 1.1 Application and Content Networking System Software 5.3.5
This was an interesting header. Could it be that Cisco Application
and Content Networking System is filtering the connection, and failing
at it?
I think it was probably that that caused the problem, rather than the
destination server, else everyone would get it.
However I've figured out what it doesn't like about it. It seems that the
http header was using \n for EOL, and the HTTP spec requires \r\n [1].
I've attached a patch to fix the problem. With this on it now works fine on
my machines at work now.
Richard.
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4
diff -ur popularity-contest-1.33.orig/popcon-upload popularity-contest-1.33/popcon-upload
--- popularity-contest-1.33.orig/popcon-upload 2006-07-28 08:39:04.000000000 +0100
+++ popularity-contest-1.33/popcon-upload 2006-07-28 08:42:56.000000000 +0100
@@ -83,15 +83,13 @@
my $formlen = length($form);
#Send data
-print $remote <<"EOF";
-POST $submiturl HTTP/1.1
-User-Agent: popcon-upload
-Host: $host
-content-type: multipart/form-data; boundary=$boundary
-content-length: $formlen
-
-$form
-EOF
+print $remote "POST $submiturl HTTP/1.1\r\n";
+print $remote "User-Agent: popcon-upload\r\n";
+print $remote "Host: $host\r\n";
+print $remote "Content-Type: multipart/form-data; boundary=$boundary\r\n";
+print $remote "Content-Length: $formlen\r\n";
+print $remote "\r\n";
+print $remote "$form";
#Get answer
my($answer)="";
