Yes, Senaka, I did not understand your comment the way you intended. Logging the fact that the 1xx messages were overridden by a later message would be a good transitional solution. At least until we learn how frequent this situation arises, whether this is the normal first response to every message to an IIS server. And, certainly, the code could be structured to return the first non-1xx response, although I hope there is no way that the curl library can cause such a situation. So a forward scan for the status lines is a better solution than a reverse scan.
As this does not seem to affect the SOAP path -- the SOAP layers don't seem to check the status -- I was not in a hurry to fix this as my application environment lets me exercise lots of SOAP paths, but not many other paths. But if I come up with a clean coding fix, I'll attach it to the issue. Thanks, Bill -----Original Message----- From: Senaka Fernando [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 9:18 AM To: [email protected] Subject: RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue Hi Bill, Yes, I believe what you say is perfectly correct. The issues for SOAP as well as RESTful calls are addressed in your logic. But, I believe you did not properly understand what I meant. I apologize for not making myself clear. We must not simply discard the status and go ahead and read the next status line in the response and neither should we return the 100 continue to the upper layer. Instead, the higher layers must have the capability of setting up an optional behaviour to address such status messages. May be we can provide a callback function. Therefore, for the moment we can log a debug message saying "100 continue recieved", add a TODO comment, and go ahead with your logic. On a later date we can replace that debug meassage and the comment with some useful implementation, like performing some user defined action. Obviously someone who is not expecting a 100 continue response may just ignore setting the callback, but, for those who are keen, we will preseve their freedom of choice. I hope that this would solve your issue as well as mine. :)... Regards, Senaka > 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.plu gin.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] > > --------------------------------------------------------------------- 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]
