dev@jax-ws.java.net

Re: Stream-based attachment decoding

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 20 Dec 2005 10:41:44 +0100

Vivek Pandey wrote:
>
> 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?
>>
> There are other headers, such as Content-Transfer-Encoding that tells
> the underlying MIME transport encoding, such as for 7 bit transport(such
> as SMTP) a text/xml Cotent-Type data with charset 'utf-8' will have
> content-transfer-encoding="quoted-printable" or "base64".
>

HTTP does not use 'Content-Transfer-Encoding', see [1]:

"HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client."

Do you mean that the CTE header will be part of the MIME multipart
message? (see correct examples here [2]).

If this is the case then it is not a transport header. So it is actually
part of the MIME multipart message (the HTTP content). Thus there is no
issue because it is up to the Decoder to process the MIME related headers.

For an SMTP transport it could be different and i do not know enough
about this yet.

Note that the HTTP transport could use a Content-Encoding header. For
example, to compress messages. But this is a detail of the transport and
the Decoder does not need to know about this.

Paul.

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.4.5
[2]
http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.html#Position_of_Root_Part

-- 
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
+33-4-76188109