RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue

[Senaka Fernando <se...@wso2.com>]

Hi again,

Adding more to my previous reply, the thoughts about the error exit for
unrecognized statuses are as follows.

1. We can't assume a default behaviour for any HTTP status, without making
the client aware.

2. Even a 1xx or 2xx or what so ever status should be recognized by the
client side.

3. If we can't recognize it, meaning that our implementation does not know
anything about it, we must log an error instead of seeking for any
immediate ammendments made to the response.

I hope this is justifiable.

This wont apply to the 1xx status messages which after this proposed fix
would be statuses that the client side will understand, but, as a whole to
all other statuses that we can't recognize.

Regards,
Senaka

> 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:jira@apache.org]
>> Sent: Wednesday, February 06, 2008 3:57 AM
>> To: axis-c-dev@ws.apache.org
>> 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: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org