[Mono-bugs] [Bug 50530][Min] New - Authenticated POST requests do not work with HTTP/1.0 servers

[bugzilla-daemon@bugzilla.ximian.com]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by helge.hess@opengroupware.org.

http://bugzilla.ximian.com/show_bug.cgi?id=50530

--- shadow/50530	2004-01-29 17:54:54.000000000 -0500
+++ shadow/50530.tmp.14885	2004-01-29 17:54:54.000000000 -0500
@@ -0,0 +1,112 @@
+Bug#: 50530
+Product: Mono/Class Libraries
+Version: unspecified
+OS: SuSE 8.1
+OS Details: 
+Status: RESOLVED   
+Resolution: FIXED
+Severity: Unknown
+Priority: Minor
+Component: Sys.Web
+AssignedTo: gonzalo@ximian.com                            
+ReportedBy: helge.hess@opengroupware.org               
+QAContact: mono-bugs@ximian.com
+TargetMilestone: ---
+URL: 
+Cc: 
+Summary: Authenticated POST requests do not work with HTTP/1.0 servers
+
+Description of Problem:
+I'll try to send an XML-RPC request to the OpenGroupware.org XML-RPC
+daemon. This apparently fails due to: a) the OGo daemon not implementing
+HTTP/1.1, or more exactly the Expect: 100-continue things and b) Mono
+apparently not properly dealing with HTTP/1.0 responses.
+
+Steps to reproduce the problem:
+1. connect OGo XML-RPC daemon with System.Net.WebRequest and POST, 
+   actual content is irrelevant
+
+Actual Results:
+Mono hangs in:
+---snip---
+END: SendRequestHeaders: System.Net.HttpWebRequest
+nread == 0: may be the connection was closed?
+System.Exception: Exception occured while sending request. --->
+System.Net.WebException: The request timed out
+in <0x001de> System.Net.HttpWebRequest:EndGetResponse (System.IAsyncResult)
+in <0x000fb> System.Net.HttpWebRequest:GetResponse ()
+in <0x001ca> .httpclient:Main ()
+--- End of inner exception stack trace ---
+in <0x002e6> .httpclient:Main ()
+---snap---
+
+Expected Results:
+Ack of the 401 sent by the server by reissuing the request with the proper
+credentials.
+
+How often does this happen? 
+Always.
+
+Additional Information:
+
+Mono generates this:
+---snip---
+POST /RPC2 HTTP/1.1
+...
+Expect: 100-continue
+
+<?xml version='1.0'?>
+<a></a>
+---snap---
+
+and my server reponds that:
+---snip---
+HTTP/1.0 401 Authorization Required
+www-authenticate: basic realm="SKYRiX"
+content-length: 0
+---snap---
+
+This makes Mono hang. I do not (yet) fully understand how 100-continue is
+supposed to work, but I guess that Mono is waiting for a "HTTP/1.1 100
+Continue" response which I am of course not sending as a HTTP/1.0 server.
+The HTTP/1.1 spec suggest that some ambitious condition may arise here?
+
+I'm not yet sure what the intended behaviour is according to the HTTP/1.1
+spec, but I guess as soon as I say that I'm HTTP/1.0, Mono should not
+continue doing 100-continue processing and at least should print a warning
+or something?
+I _think_ (not sure) that I'm not doing anything illegal in my response, so
+I prefer blaming Mono ;-)
+
+Personally I wonder whether Mono should just assume HTTP/1.0 until it knows
+for certain that the peer is a HTTP/1.1 server since most servers
+(especially application servers) are still HTTP/1.0 in practice.
+
+------- Additional Comments From helge.hess@opengroupware.org  2003-11-03 19:44 -------
+Created an attachment (id=5854)
+my weird HTTP POST test client
+
+
+------- Additional Comments From gonzalo@ximian.com  2003-11-21 03:10 -------
+Mono uses 1.1 if the user doesn't change the request ProtocolVersion 
+property. And yes, it detects the 1.0 from the server. And don't ever
+try a second Expect: 100-continue if the first one timeouts (2 seconds)...
+
+Can you try again with current CVS?
+
+It would be nice if you provide a simpler test case. Can you try to
+cook a simpler page (may be php or asp.net+apache) that uses POST+auth?
+
+Thanks.
+
+------- Additional Comments From gonzalo@ximian.com  2003-11-27 02:22 -------
+Fixed in CVS.
+
+------- Additional Comments From helge.hess@opengroupware.org  2004-01-29 17:54 -------
+Apparently this is not yet fixed in 0.29 (see mono-list), but I won't reopen until I can 
+verify the issue.
+
+Also I do not really understand the statement: "And don't ever try a second Expect: 
+100-continue if the first one timeouts". Where does this help? All non-100-continue 
+capable servers will return a full HTTP response line - there is no need for a timeout.
+Anyway, I will need to check that out ;-)