Re: p:http-request - implementing HEAD

On Tue, Apr 13, 2010 at 1:34 PM,  <Toman_Vojtech@emc.com> wrote:
> Hi folks,
>
> I am currently adding support for the HTTP HEAD method to p:http-request
> in Calumet. What do you think is the expected/preferred behavior of the
> following pipeline:
>
> ...
> <p:http-request>
>  <p:input port="source">
>    <p:inline>
>      <c:request xmlns:c="http://www.w3.org/ns/xproc-step"
>          method="HEAD"
>          href="...">
>      </c:request>
>    </p:inline>
>  </p:input>
> </p:http-request>
> ...
>
> Because c:request/@detailed is not specified and therefore defaults to
> "false", the response should be handled according to these rules in the
> XProc spec:
>
> "
> 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 Section 7.1.10.4,
> "Converting Response Entity Bodies".
> "
>
> Obviously, with the HEAD method, there is no response body, so should
> p:http-request fail with a dynamic error in this case? Or should it
> produce some kind of an empty c:body (or c:multipart/c:body) element?

I have used in the past c:empty nested in c:body .... and I forgot to
mention/raise this

> The same probably applies to other methods such as DELETE.

ditto

>
> My inclination is to raise a dynamic error, but perhaps there are people
> who feel differently. Norm, how does Calabash deal with this case?

I think this violates 'principle of least surprise' from user pov.

James Fuller

Received on Tuesday, 13 April 2010 11:46:21 UTC