Response headers in p:http-request

Section 7.1.9.3 says:

======
The value of the detailed attribute determines the content of the result
document. If it is "true", the response to the request is handled as
follows:
...
2. Each response header whose name does not start with "Content-" is
translated into a c:header element.
...
Otherwise (the detailed attribute is not specified or its value is "false"),
the response to the request is handled as follows:

1. If the media type (as determined by the override-content-type attribute
or the Content-Type response header) is an XML media type, the entity is
decoded if necessary, then parsed as an XML document and produced on the
result output port as the entire output of the step.

2. Otherwise, the entity body of the response is converted into a c:body or
c:multipart element via the rules given in the next section.
======

It seems unclear to me how are headers handled when detailed is "false" or
not specified. Are they handled at all? If not, this should be explicitly
said. If they are handled, how? The same way?

In addition, I'm wondering, why should the "Content-type" not be a c:header
element? Why should all other "Content-*" headers be practically hidden?


Also, I'd like to propose an additional child element of c:header, perhaps
called c:parameter that will hold the name and value of parameters in the
header. The "value" attribute of the c:header can still contain the raw
value of the header.

A particular use case for that which I have in mind is getting the "charset"
parameter out of a "Content-type" header, and which so far seems to be
hidden altogether. So for example, a response header could be:
<c:header name="Content-type" value="text/html; charset=utf-8">
	<c:parameter name="text/html" value=""/>
	<c:parameter name="charset" value="utf-8"/>
</c:header>
(PHP for one has a function that could actually translate a raw header into
an array. I can imagine translating that array into XML elements. Thus, this
shouldn't be that hard for implementers to implement)

And of course, this may as well provide useful for easily parsing custom
headers.


Regards,
Vasil Rangelov

Received on Sunday, 3 February 2008 15:32:32 UTC