Johan

On Tue Nov 25 2014 at 7:58:26 PM Christian Grün <christian.gruen@gmail.com> wrote:

Hi Johan,

I modified both the server- and client-side HTTP code to make it more
"erwartungskonform". Could you possibly check out the latest stable
snapshot [1] and give me feedback?

Thanks,
Christian

[1] http://files.basex.org/releases/latest/

On Tue, Nov 25, 2014 at 7:01 PM, Johan Mörén <johan.moren@gmail.com> wrote:
> Hi Christian
>
> No it's another container, a Camel route on a Karaf instance exposed as a
> REST-service. I'm pretty sure this is due to the handling of error in
> HttpPayload.java I'm still on BaseX 7.9 if that matters. But when i checked
> the code i peeked into the master branch.
>
> Regards,
> Johan Mörén
>
>
> On Tue Nov 25 2014 at 6:44:28 PM Christian Grün <christian.gruen@gmail.com>
> wrote:
>>
>> Hi Johan,
>>
>> Thanks for bringing this up. I currenly try to find out if this is a
>> server-side or client-side issue. Is the web service you are talking
>> to (on port 9595) a BaseX instance, too?
>>
>> Thanks in advance,
>> Christian
>>
>>
>> On Tue, Nov 25, 2014 at 8:49 AM, Johan Mörén <johan.moren@gmail.com>
>> wrote:
>> > Hi
>> >
>> > I have a REST service that communicates details about any errors that
>> > occurs
>> > during execution via a an XML-payload in the response body.
>> >
>> > I have noticed that the http-module ignores the content-type header of
>> > the
>> > response if the status-code is > 399. Then it is flagged as being in
>> > error
>> > and in HttpPayload this line forces the content type of the body to
>> > text/plain
>> >
>> > HttpPayload.java
>> > // error: use text/plain as content type
>> > final String ct = error ? TEXT_PLAIN : utype != null ? utype :
>> > contentType(ctype);
>> >
>> > Overriding the content type via the override-media-type attribute of
>> > http:request doesn't help either in this case.
>> >
>> > Is there any special reason that error response-bodies are handled in
>> > this
>> > way? To my knowledge it is very common that REST services provides error
>> > information by sending it in the response body.
>> >
>> > I guess that changing the default behaviour might break existing
>> > implementations. But perhaps an additional attribute in the http-request
>> > could flag that the media-type of the content-type should be used even
>> > with
>> > error-responses. Or perhaps via an additional option in the
>> > http:send-request() function.
>> >
>> >
>> > Exampel of request and response where this error occurs.
>> >
>> > Request:
>> > http:send-request(<http:request override-media-type="application/xml"
>> > href="{'http://localhost:9595/sequencegenerator/objectInstanceId/' ||
>> > '0'}"
>> > method="get"/>)
>> >
>> > Response:
>> > <http:response xmlns:http="http://expath.org/ns/http-client"
>> > status="400"
>> > message="Bad Request">
>> > <http:header name="nbrOfIds" value="0"/>
>> > <http:header name="typeOfId" value="objectInstanceId"/>
>> > <http:header name="Transfer-Encoding" value="chunked"/>
>> > <http:header name="breadcrumbId"
>> > value="ID-2013M-2-local-61198-1416819131884-37-54"/>
>> > <http:header name="User-Agent" value="Java/1.7.0_45"/>
>> > <http:header name="Accept" value="text/html, image/gif, image/jpeg, *;
>> > q=.2, */*; q=.2"/>
>> > <http:header name="Content-Type" value="application/xml"/>
>> > <http:header name="Server" value="Jetty(8.1.15.v20140411)"/>
>> > <http:body media-type="text/plain"/>
>> > </http:response><faultResponse><errorMessage>number of ids
>> > must
>> > be a positive integer larger than
>> > 0</errorMessage></faultResponse>
>> >
>> > Regards,
>> > Johan Mörén
>> >
>> >