Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-3399

When using ResponseBuilder to create Response of multiparts, the boundary attribute in the Content-Type Header is missing

    XMLWordPrintableJSON

Details

    • Advanced

    Description

      Hello,
      We have implemented the following method while the output of the Response should be a multipart message.

      @POST
      @Path("

      {destinationAddress}

      /messages/payloads")
      @Consumes("application/xml")
      @Produces(

      {"multipart/related", "multipart/mixed", "multipart/form-data"}

      )
      public Response postMailboxMessagesPayloadRequest(@Context HttpServletRequest request,
      @PathParam("destinationAddress") String destinationAddress,
      @Context ServletContext servletContext,
      JAXBElement<MailboxMessagesPayload> jAXBElement) {
      try

      { List<Attachment> attachments = ((MultipartBody)mwMailboxMessagesPayloadResponse.getBody()).getAllAttachments(); MultipartBody multipartBody = new MultipartBody(attachments); ResponseBuilder responseBuilder = Response.status(HttpURLConnection.HTTP_OK); responseBuilder.type(multipartBody.getType() responseBuilder.entity(multipartBody); Response response = responseBuilder.build(); return response; }

      catch(Exception e){
      }

      The thing is that no matter what we do, we can not have the 'boundary' which is determined by the CXF engine to appear in the Content-Type on the main header.
      As a result no Client will be able to parse the returned message.
      If we try to manually set the Content-Type header while giving it our own 'boundary', the result is that a different boundary is generated for the actual message, while the boundary we set is not the same.

      Attachments

        Activity

          People

            sergey_beryozkin Sergey Beryozkin
            avishyes Avshalom Yeshurun
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - 672h
                672h
                Remaining:
                Remaining Estimate - 672h
                672h
                Logged:
                Time Spent - Not Specified
                Not Specified