Kohsuke Kawaguchi wrote:
> Vivek Pandey wrote:
>
>> Kohsuke,
>>
>> Just contentType in Decoder.decode(inputStream, contentType) may not
>> be sufficient.
>>
>> for example AttachmentStreamDecoder would need information about other
>> HTTP header parameters, such as Multipart/Related header parameters,
>> such as boundary and start. What we need here is something like
>> ContentType from JavaMail, that can give easy access to the Mime
>> parameters or the assumption here is that decode gets the compelte
>> stream that includes the HTTP headers?
>
>
> Oh wait, isn't the Content-type header like:
>
> Content-Type: multipart/related;
> boundary="--=_outer_boundary"; type="multipart/alternative"
>
> in one line? If so, decoder does get the whole thing, not just
> "multipart/related". Given that, do we still need to change the signature?
>
I do not think we need to expose all the transport headers to the Decoder.
The SOAP 1.2 MIME type can have optional parameters [1], action and
charset. The Fast Infoset SOAP MIME type can have the optional action
parameter. IIRC the text/xml MIME type can also have parameters (like
charset)
It seems necessary to separate out the content type from the parameters
so that the correct decoder can be chosen by the transport pipe.
Therefore changing the signature to say be:
Decoder.decode(InputStream, inputStream, String contentType, String
parameters)
might be OK. i.e. we split the 'Content-Type' string into two. If the
String == "" then there are no parameters.
Paul.
[1]
http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#ietf-draft
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109