You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Bill Mitchell (JIRA)" <ji...@apache.org> on 2008/02/06 08:51:13 UTC
[jira] Created: (AXIS2C-967) libcurl interface assumes first
response line is HTTP status, but it might be HTTP 100 Continue
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
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first
response line is HTTP status, but it might be HTTP 100 Continue
Posted by 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
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
Posted by Bill Mitchell <bm...@austin.rr.com>.
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:senaka@wso2.com]
Sent: Wednesday, February 06, 2008 9:18 AM
To: axis-c-dev@ws.apache.org
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: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.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: 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
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first
response line is HTTP status, but it might be HTTP 100 Continue
Posted by Senaka Fernando <se...@wso2.com>.
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
RE: [jira] Commented: (AXIS2C-967) libcurl interface assumes first response line is HTTP status, but it might be HTTP 100 Continue
Posted by Bill Mitchell <bm...@austin.rr.com>.
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
[jira] Commented: (AXIS2C-967) libcurl interface assumes first
response line is HTTP status, but it might be HTTP 100 Continue
Posted by "Senaka Fernando (JIRA)" <ji...@apache.org>.
[ 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