W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > January 2009

Re: p:http-request - conflicting content-type information for body parts

From: Florent Georges <fgeorges@fgeorges.org>
Date: Mon, 26 Jan 2009 18:55:12 +0100
Message-ID: <ebaca5bf0901260955k64489970nc8cc5a62a19cd4a4@mail.gmail.com>
To: Toman_Vojtech@emc.com
Cc: public-xml-processing-model-comments@w3.org

2009/1/26 ? wrote:

>>     It is a dynamic error (err:XC0020) if the value of a
>>     header specified via c:header (e.g. Content-Type)
>>     conflicts with the value for that header that the step
>>     and/or protocol implementation must set.
>>       -- http://www.w3.org/TR/xproc/#err.inline.C0020

> Is it really so? I thought that the error is for something
> else, like if use a value that is not valid/supported for
> given header.

  I think that the "must set" in "conflicts with the value for
that header that the step and/or protocol implementation must
set" refers to those headers that the step has to set itself
from other info (as Content-Type from @content-type.)

  And I don't think this is the responsibility of the processor
to throw an error for an "invalid" header value, I would instead
send the request as it is set by the user, and let the server
respond with an error if appropriated (and I think that this is
the way the step is actually designed.)

>> What about content-type="text/xml; utf-8" and c:header
>> Content-Type set to "text/xml" for instance?  Do they
>> conflict?

> Interesting question... I would say that there is no conflict
> here. One of the content-type values will be completely
> ignored, in my opinion.

  Yes, I think so.  But in this case, I think we should act as
if @encoding had been set to "utf-8."  BTW, if I am right, it is
not possible to set the header Content-Type without setting
@content-type to a value also.  Why not say this attribute is by
default the value of the corresponding header, if any?


Florent Georges
Received on Monday, 26 January 2009 17:56:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:28:26 UTC