Uploaded image for project: 'Spring Web Services'
  1. Spring Web Services
  2. SWS-520

HTTP Accept header field contains invalid type, and omits text/xml

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.5.7
    • Fix Version/s: 1.5.8
    • Component/s: Core
    • Labels:
      None
    • Environment:
      Spring/WS client,

      Description

      The Spring-WS client sends an HTTP Accept request-header field that is invalid according to the HTTP 1.1 spec.

      The header that the Spring-WS client sends is:

      Accept: text/html, image/gif, image/jpeg, ; q=.2, */; q=.2

      The fourth media-range in this field does not include the mandatory "/" and subtype.

      The definition of the Accept header in the HTTP 1.1 spec (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) is:

      Accept = "Accept" ":"
      #( media-range [ accept-params ] )

      media-range = ( "/"

      ( type "/" "*" )
      ( type "/" subtype )
      ) *( ";" parameter )

      I would have also expected the Accept header field to contain "text/xml" explicitly (for SOAP 1.1), and not to Accept "text/html", "image/gif" or "image/jpeg".

      My spring-client-context.xml is:

      <?xml version="1.0" encoding="UTF-8"?>

      <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans.xsd">

      <bean id="messageFactory" class="org.springframework.ws.soap.axiom.AxiomSoapMessageFactory">
      <property name="payloadCaching" value="false" />
      </bean>

      <bean id="webServiceTemplate" class="org.springframework.ws.client.core.WebServiceTemplate">
      <property name="marshaller" ref="marshaller" />
      <property name="unmarshaller" ref="marshaller" />
      <property name="defaultUri" value="http://localhost:8079/jibx-ws-seismic/soap/quake-service" />
      <property name="messageFactory" ref="messageFactory"/>
      </bean>

      <!-- A JiBX-based payload marshaller/unmarshaller. -->
      <bean id="marshaller" class="org.springframework.oxm.jibx.JibxMarshaller">
      <property name="targetClass" value="com.sosnoski.seismic.common.Query" />
      </bean>
      </beans>

        Activity

        nigel.charman Nigel Charman created issue -
        Hide
        nigel.charman Nigel Charman added a comment -

        Oops, some of the text got a bit mangled. The Accept header field sent by Spring-WS client is:

        Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
         

        and the text from the HTTP spec should read:

               Accept         = "Accept" ":"
                                #( media-range [ accept-params ] )
         
               media-range    = ( "*/*"
                                | ( type "/" "*" )
                                | ( type "/" subtype )
                                ) *( ";" parameter )
         

        Show
        nigel.charman Nigel Charman added a comment - Oops, some of the text got a bit mangled. The Accept header field sent by Spring-WS client is: Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2   and the text from the HTTP spec should read: Accept = "Accept" ":" #( media-range [ accept-params ] )   media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter )  
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        The Accept header is actually set by the JDK HttpURLConnection, so as a workaround you can inject the CommonsHttpMessageSender into the template, instead of the default HttpUrlConnectionMessageSender.

        I'll see whether we can fix this header in 1.5.8

        Show
        arjen.poutsma Arjen Poutsma added a comment - The Accept header is actually set by the JDK HttpURLConnection, so as a workaround you can inject the CommonsHttpMessageSender into the template, instead of the default HttpUrlConnectionMessageSender. I'll see whether we can fix this header in 1.5.8
        arjen.poutsma Arjen Poutsma made changes -
        Field Original Value New Value
        Fix Version/s 1.5.8 [ 11236 ]
        Hide
        nigel.charman Nigel Charman added a comment -

        The CommonsHttpMessageSender does provide a workaround since it omits the Accept header field . The spec says "If no Accept header field is present, then it is assumed that the client accepts all media types.". I'd suggest that this isn't strictly true, and you may want to consider explicitly setting the Accept types for all the MessageSender implementations.

        Thanks for your help.

        Show
        nigel.charman Nigel Charman added a comment - The CommonsHttpMessageSender does provide a workaround since it omits the Accept header field . The spec says "If no Accept header field is present, then it is assumed that the client accepts all media types.". I'd suggest that this isn't strictly true, and you may want to consider explicitly setting the Accept types for all the MessageSender implementations. Thanks for your help.
        arjen.poutsma Arjen Poutsma made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        This is now fixed for Axiom; SAAJ already set the Accept header itself.

        Show
        arjen.poutsma Arjen Poutsma added a comment - This is now fixed for Axiom; SAAJ already set the Accept header itself.
        arjen.poutsma Arjen Poutsma made changes -
        Resolution Fixed [ 1 ]
        Status In Progress [ 3 ] Resolved [ 5 ]
        Hide
        nigel.charman Nigel Charman added a comment -

        The fix works for me. Thanks

        Show
        nigel.charman Nigel Charman added a comment - The fix works for me. Thanks
        Hide
        arjen.poutsma Arjen Poutsma added a comment -

        Closing old issues

        Show
        arjen.poutsma Arjen Poutsma added a comment - Closing old issues
        arjen.poutsma Arjen Poutsma made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        7d 6h 35m 1 Arjen Poutsma 02/Jun/09 1:08 AM
        In Progress In Progress Resolved Resolved
        20m 56s 1 Arjen Poutsma 02/Jun/09 1:29 AM
        Resolved Resolved Closed Closed
        1067d 5h 34m 1 Arjen Poutsma 04/May/12 7:03 AM

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            nigel.charman Nigel Charman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: