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.mo...@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.gr...@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.mo...@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 >> > >> >
