Http-module error response-bodies always returned as string

On Tue, Nov 25, 2014 at 8:49 AM, Johan Mörén <johan.moren at 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>&lt;faultResponse&gt;&lt;errorMessage&gt;number of ids must > be a positive integer larger than > 0&lt;/errorMessage&gt;&lt;/faultResponse&gt; > > Regards, > Johan Mörén > >

On Tue Nov 25 2014 at 6:44:28 PM Christian Grün <christian.gruen at 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 at 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>&lt;faultResponse&gt;&lt;errorMessage&gt;number of ids > must > > be a positive integer larger than > > 0&lt;/errorMessage&gt;&lt;/faultResponse&gt; > > > > Regards, > > Johan Mörén > > > > >

On Tue, Nov 25, 2014 at 7:01 PM, Johan Mörén <johan.moren at 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 at 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 at 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>&lt;faultResponse&gt;&lt;errorMessage&gt;number of ids >> > must >> > be a positive integer larger than >> > 0&lt;/errorMessage&gt;&lt;/faultResponse&gt; >> > >> > Regards, >> > Johan Mörén >> > >> >

On Tue Nov 25 2014 at 7:58:26 PM Christian Grün <christian.gruen at 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 at 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 at 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 at 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>&lt;faultResponse&gt;&lt;errorMessage&gt;number of > ids > >> > must > >> > be a positive integer larger than > >> > 0&lt;/errorMessage&gt;&lt;/faultResponse&gt; > >> > > >> > Regards, > >> > Johan Mörén > >> > > >> > >