Camel
  1. Camel
  2. CAMEL-324

bad content length header value in http response

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3.0
    • Fix Version/s: 1.3.0
    • Component/s: camel-http
    • Labels:
      None

      Description

      By default HttpBinding class copies all request header attributes from the request to the response including 'Content-Length'. So the consequence is that the response is declaring the same size as the request which can lead to serious truncation problems!

      the workaround is simply to add the line:
      out.removeHeader("Content-Length");
      in the writeResponse method of the httpbinding class allowing jetty to set the right value.

        Activity

        Hide
        Gary Tully added a comment -

        Hi Alex,
        I am having difficulty reproducing the behaviour you describe. In writeResponse[1] on trunk, the headers are correctly copied from the out message, not from the request. The out message defaults to an empty DefaultMessage which would have no headers.

        Would it be possible to provide a test route or xml config fragment or some more detail?

        Thanks,
        Gary.

        http://svn.apache.org/viewvc/activemq/camel/trunk/components/camel-http/src/main/java/org/apache/camel/component/http/HttpBinding.java?view=markup

        Show
        Gary Tully added a comment - Hi Alex, I am having difficulty reproducing the behaviour you describe. In writeResponse [1] on trunk, the headers are correctly copied from the out message, not from the request. The out message defaults to an empty DefaultMessage which would have no headers. Would it be possible to provide a test route or xml config fragment or some more detail? Thanks, Gary. http://svn.apache.org/viewvc/activemq/camel/trunk/components/camel-http/src/main/java/org/apache/camel/component/http/HttpBinding.java?view=markup
        Hide
        Alex Cichowski added a comment -

        Sure, here is a route that reproduces the problem. This simply routes a java serialized, base64 encoded request (and returns the response back) to the echoService on a http channel:

        from("direct:echoService").marshal().serialization().beanRef("base64Encoder")
        .to("http://localhost:8088/echoService").beanRef("base64Decoder").unmarshal().serialization();

        from("jetty:http://localhost:8088/echoService").beanRef("base64Decoder")
        .unmarshal().serialization().to("bean:echoService").marshal().serialization().beanRef("base64Encoder");

        I think the problem comes from the [un]marshall processor that copies the complete in message (with headers) to the out message before setting the [un]marshalled body in the out message. Here is the code:

        Message in = exchange.getIn();
        Object body = in.getBody();

        // lets setup the out message before we invoke the dataFormat
        // so that it can mutate it if necessary
        Message out = exchange.getOut(true);
        out.copyFrom(in);

        Thanks,
        Alex.

        Show
        Alex Cichowski added a comment - Sure, here is a route that reproduces the problem. This simply routes a java serialized, base64 encoded request (and returns the response back) to the echoService on a http channel: from("direct:echoService").marshal().serialization().beanRef("base64Encoder") .to("http://localhost:8088/echoService").beanRef("base64Decoder").unmarshal().serialization(); from("jetty: http://localhost:8088/echoService ").beanRef("base64Decoder") .unmarshal().serialization().to("bean:echoService").marshal().serialization().beanRef("base64Encoder"); I think the problem comes from the [un] marshall processor that copies the complete in message (with headers) to the out message before setting the [un] marshalled body in the out message. Here is the code: Message in = exchange.getIn(); Object body = in.getBody(); // lets setup the out message before we invoke the dataFormat // so that it can mutate it if necessary Message out = exchange.getOut(true); out.copyFrom(in); Thanks, Alex.
        Hide
        Gary Tully added a comment -

        yea, it is the marshaller that does the copy, but going to any different exchange would do it.

        One option is to add a .removeHeader("Content-Length") to your route rather than in the camel source. However I don't think this should be necessary, imho the Content-Length headers should never be copied/propagated from a HttpMessage.

        I have posted to the dev list to get some feedback before I prepare a patch for this.

        Show
        Gary Tully added a comment - yea, it is the marshaller that does the copy, but going to any different exchange would do it. One option is to add a .removeHeader("Content-Length") to your route rather than in the camel source. However I don't think this should be necessary, imho the Content-Length headers should never be copied/propagated from a HttpMessage. I have posted to the dev list to get some feedback before I prepare a patch for this.
        Hide
        Roman Kalukiewicz added a comment -

        In CAMEL-254 there was similar problem described. The solution implemented there was to skip a set of headers while building the HTTP request, so headers was on Camel message, but were ignored by the endpoint.

        Show
        Roman Kalukiewicz added a comment - In CAMEL-254 there was similar problem described. The solution implemented there was to skip a set of headers while building the HTTP request, so headers was on Camel message, but were ignored by the endpoint.
        Hide
        Gary Tully added a comment -

        This patch takes the lead from the jmsBinding and the fix for CAMEL-254. I pulled the skip code from HttpProducer into HttpBinding so it can be reused in the jetty component.
        The option to override the set of ignored headers is provided via the IgnoredHeaders accessors

        Show
        Gary Tully added a comment - This patch takes the lead from the jmsBinding and the fix for CAMEL-254 . I pulled the skip code from HttpProducer into HttpBinding so it can be reused in the jetty component. The option to override the set of ignored headers is provided via the IgnoredHeaders accessors
        Hide
        Hadrian Zbarcea added a comment -

        Patch applied with thanks!

        Show
        Hadrian Zbarcea added a comment - Patch applied with thanks!
        Hide
        Claus Ibsen added a comment -

        Closed all 1.3 tickets

        Show
        Claus Ibsen added a comment - Closed all 1.3 tickets

          People

          • Assignee:
            Gary Tully
            Reporter:
            Alex Cichowski
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development