I understand your point, Senaka, at least as it raises the idea that we can't just skip all 100 status responses. What if I rephrased the issue to say that we need to get to the last HTTP status line and return it?
What I'm seeing stepping through the axis2_libcurl implementation is that the curl library forwards the entire response back to us. So the response list begins with the HTTP 100 response and continues through to read the body. The curl library has already done the job of recognizing the 100 status and continuing. Now, in the case I saw, the subsequent status was 200 and not an issue. But what if it was something else? Because the axis2_libcurl code returns the 100 and discards all the remaining status lines, the 100 will be the only status the upper logic sees. In the SOAP flow, no one cares about the status, so this issue doesn't affect my needs personally. But for whoever does look at it, e.g., the RESTful flow, the fact that it does not get to see a code it is looking for probably matters. Thus my suggestion that, however the status code is used in the upper layers, axis2_libcurl would return the most useful status line by examining the last one it received from the curl library. It may be, as you suggest, that at some point the upper level logic will need access to all the response status lines. And you are right, that is a larger implementation issue. Today, there is some upper level code looking for a 500 status, and in some cases the axis2_libcurl implementation will hide that status and provide the upper level code only the 100 status. Regards, Bill -----Original Message----- From: Senaka Fernando (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 3:57 AM To: [email protected] Subject: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue [ https://issues.apache.org/jira/browse/AXIS2C-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566063#action_12566063 ] Senaka Fernando commented on AXIS2C-967: ---------------------------------------- Hi Bill, No it is correct to read the first line. Even a 100 continue is a valid HTTP status, [1]. We must process that and then consider any trailing responses. Processing may be checking whether the client has nothing more to send. We can perhaps log a message. What if the server expects the client to send more? Thus, it is not done to simply ignore it. I think it is better if we could have a discussion on this on the dev-list. My concern is with RESTful invocations mainly, where we'd be considering many status codes unlike SOAP that considers 200, 202, and 500. Answering your reverse seek situation. I believe the server requires us to understand a response in order, and we must understand statuses one-by-one and if we can't recognize a status we must report an error and exit, without making any assumptions. Also, I believe that this is not a bug in our implementation. Rather, we need an improvement to understand 100 continue responses. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html Regards, Senaka > libcurl interface assumes first response line is HTTP status, but it might be > HTTP 100 Continue > ----------------------------------------------------------------------------------------------- > > Key: AXIS2C-967 > URL: https://issues.apache.org/jira/browse/AXIS2C-967 > Project: Axis2-C > Issue Type: Bug > Components: transport/http > Environment: Windows XP, Visutal Studio 2005, libxml, libcurl > Reporter: Bill Mitchell > > After receiving an HTTP response, the axis2_libcurl code assumes the first > response line is the HTTP status line, and grabs the status code therein. > While watching this communicate to an IIS server, I noticed that the first > response was an HTTP 1.1/100 Continue, and the real status line was several > lines later. I don't know if IIS sends the 100 Continue all of the time or > just some of the time; regardless, it is allowed in the HTTP RFC 2616. The > libcurl code needs to read through to find the first non-1xx HTTP status > line, or process these headers in reverse order and grab the code from the > last status line received. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
