Feature Requests item #2996445, was opened at 2010-05-04 11:08
Message generated for change (Comment added) made by sjaakvs
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=2996445&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: download
Status: Open
Resolution: Rejected
Priority: 5
Private: No
Submitted By: Sjaak (sjaakvs)
Assigned to: Daniel Stenberg (bagder)
Summary: Support for HTTP SOAP Fault

Initial Comment:
SOAP stands for Simple Object Access Protocol.
SOAP over HTTP(S) is send as a POST text/xml with a SOAPAction header field.

libcurl works fine for this, except when setting the option FAILONERROR. Then the SOAP Fault document is passedto the client.

This is because the SOAP Fault is defined to be a HTTP code 500 "Internal server error". The (Soap Fault) text/xml document that MUST follow should explain the error reason in more detail. So for SOAP over HTTP code 500 is NOT an HTTP error but more as 'Error document follows'.

Adjustment of libcurl is needed to pass the SOAP Fault document as a fault document is needed. Regardless of FAILONERROR.
Currently I modified http.c for this so that a HTTP POST resulting in HTTP code 500 just continues. It's better to also test for the SOAPAction request header. Or make a specific/generic switch for SOAP so that the transport layer is prepared, since SOAP can be passed over other protocols as well.

More details in: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ (section 6.1.1 & 6.2 & 4.4)

----------------------------------------------------------------------

>Comment By: Sjaak (sjaakvs)
Date: 2010-05-06 12:18

Message:
@bagder
I agree to not change curl specific for SOAP.
Setting FAILONERROR is most convenient so that curl will handle errors and
stops on an error. Not setting will need additional understanding about
authentication errors for example. In general disabling the DATA is fine
here. Only the error number and a simple string is enough.

However it's also convenient to let the caller decide on a specific error
if only the simple string is sufficient (and fail) or to continue to get
additional error detail data send by the HTTP server.

So why not implement a callback function to let the user decide on a error
(HTTP 400 or higher) if it likes the curl to fail or to continue.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-05-04 11:15

Message:
I disagree with both the suggestion and the change.

First, libcurl sends HTTP as defined by the HTTP spec(s). Error codes 500
and upwards are clearly errors so if you ask libcurl to not report anything
back on errors you will not get anything for 500 codes. But why on earth
would you DISABLE the data if you instead actually WANT the data for this
case? It doesn't make any sense.

I don't see any reason for hardcoding SOAP-awareness into libcurl to
suddenly not follow the HTTP spec. It is dead simple for you to just adapt
your code for it instead.

----------------------------------------------------------------------

Comment By: Sjaak (sjaakvs)
Date: 2010-05-04 11:12

Message:
Second section should end with: Then the SOAP Fault document is NOT passed
to the client.

----------------------------------------------------------------------

Comment By: Sjaak (sjaakvs)
Date: 2010-05-04 11:09

Message:
Forgot to set category

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350976&aid=2996445&group_id=976
Received on 2010-05-06