Announcement Announcement Module
Collapse
No announcement yet.
HttpRequestHandlingMessagingGateway behavior when Content-Type is null in 2.2.2 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • HttpRequestHandlingMessagingGateway behavior when Content-Type is null in 2.2.2

    Running into a problem with HttpRequestHandlingMessagingGateway. We have devices that are messaging into our system via HTTP. These clients are NOT sending a Content-Type in the payload.

    The issue seems to start manifesting itself in HttpRequestHandlingMessagingGateway.actualDoHandle Request(...). "isReadable()" is returning false (because the Content-Type is null) and as such the requestBody is null


    Code:
    	private Message<?> actualDoHandleRequest(HttpServletRequest servletRequest, HttpServletResponse servletResponse) throws IOException {
    
    //snip for clarity
    			Object requestBody = null;
    			if (this.isReadable(request)) {
    				requestBody = this.extractRequestBody(request);
    			}
    			HttpEntity httpEntity = new HttpEntity(requestBody, request.getHeaders());
    further down in actualDoHandleRequest we have the following logic

    Code:
    			LinkedMultiValueMap<String, String> requestParams = this.convertParameterMap(servletRequest.getParameterMap());
    
    //snip
    
    			if (payload == null) {
    				if (requestBody != null) {
    					payload = requestBody;
    				}
    				else {
    					payload = requestParams;
    				}
    			}
    Our transformer downstream expects a byte[] to be the payload, but it is a LinkedMultiValueMap because of this logic. If the Content-Type is set to "application/octet-stream" it does the right thing.

    We cannot control the device behavior as we already have them deployed and we ran into this when moving from 1.0.4 to 2.2.2.

    Am I misunderstanding/misusing something here?

    Thanks,
    Al

  • #2
    Yes, looking at the RFC, it seems we should assume 'application/octet-stream' if the content type header is missing...

    7.2.1 Type
    ...
    ... If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
    This is a SHOULD, not a MUST, but I think it's a reasonable default. Please open a JIRA issue... https://jira.springsource.org/browse/INT

    In the meantime, you could add a custom Servlet Filter to the DispatcherServlet (in web.xml) to add the missing content-type to the request.

    Comment

    Working...
    X