Http-module error response-bodies always returned as string
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
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
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
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
Thanks Christian! I will try out the code tomorrow at work! Thanks for the fast feedback! Regards, 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
participants (2)
-
Christian Grün -
Johan Mörén