Paul,
my comments inlined...
Paul Sandoz wrote:
> 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."
>
As I mentioned above, its for 7bit transport, such as SMTP. HTTP is 8bit
clean so CTE is not needed.
> Do you mean that the CTE header will be part of the MIME multipart
> message? (see correct examples here [2]).
>
May be incase of SMTP, but I am not sure. [2] talks about SOAP over HTTP
not other transports. See RFC 3023, XML Media Types,
http://www.faqs.org/rfcs/rfc3023.html. Its not just about
Mime/Multipart, in case that there is no multiple parts, there is only
one part - it may apply to 7bit transports and proably we should expose
it thru our decoders.
> 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.
yes.
>
> 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.
>
Thats right. CTE wont apply for our decoders for HTTP transport.
-vivek.
> 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
>
>