Previous Up Next


p:http-request

p:http-request — Interact with other systems over HTTP.

Synopsis

<p:declare-step type="p:http-request">
     <p:input port="source"/>
     <p:output port="result"/>
     <p:option name="byte-order-mark"/>                            <!-- boolean -->
     <p:option name="cdata-section-elements" select="''"/>         <!-- ListOfQNames -->
     <p:option name="doctype-public"/>                             <!-- string -->
     <p:option name="doctype-system"/>                             <!-- anyURI -->
     <p:option name="encoding"/>                                   <!-- string -->
     <p:option name="escape-uri-attributes" select="'false'"/>     <!-- boolean -->
     <p:option name="include-content-type" select="'true'"/>       <!-- boolean -->
     <p:option name="indent" select="'false'"/>                    <!-- boolean -->
     <p:option name="media-type"/>                                 <!-- string -->
     <p:option name="method" select="'xml'"/>                      <!-- QName -->
     <p:option name="normalization-form" select="'none'"/>         <!-- NormalizationForm -->
     <p:option name="omit-xml-declaration" select="'true'"/>       <!-- boolean -->
     <p:option name="standalone" select="'omit'"/>                 <!-- "true" | "false" | "omit" -->
     <p:option name="undeclare-prefixes"/>                         <!-- boolean -->
     <p:option name="version" select="'1.0'"/>                     <!-- string -->
</p:declare-step>

Description

The p:http-request step allows you to interact with other systems over HTTP. You describe the interaction that you want to have with the system in the form of a c:request document sent to the source input port. The response that comes back from the system is returned in the result port. The step provides a lot of flexibility in how the response is presented.

This step is actually quite complicated because it attempts to provide a uniform interface to all of the possible HTTP methods, with and without authentication, and to handle sending and receiving both single and multipart message bodies that may or may not be XML.

Don't let the all of the possible complexity persuade you into thinking that it has to be complex. Here's a simple example that retrieves the XProc specification from the W3C website:

  1   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request method="GET"
  5                    href="http://www.w3.org/TR/xproc/langspec.xml"/>
          </p:inline>
        </p:input>
      </p:http-request>

If most of your web interactions are simple HTTP “GET” requests, it may be useful to write a wrapper that provides direct support for those simple cases. In the examples below, you'll find a cx:http-get pipeline that simplifies the above example to a single line:

<cx:http-get href="http://www.w3.org/TR/xproc/langspec.xml"/>

Now let's look at the step in all it's generality. Everything begins with the request. A c:request element has the following form:

  1 <c:request
      method = NCName
      href? = anyURI
      username? = string
  5   password? = string
      auth-method? = string
      send-authorization? = boolean
      override-content-type? = string
      detailed? = boolean
 10   status-only? = boolean>
        (c:header*, (c:body | c:multipart)?)
    </c:request>

The method attribute must be one of the HTTP methods (one of the methods supported by the system with which you're interacting). The href attribute identifies the URI that you want to interact with. The username, password, auth-method, and send-authorization attributes control authentication, see the section called “HTTP Authentication”, below. The override-content-type attribute allows you to change the interpretation of the result; the detailed and status-only attributes control how much detail is exposed in the result, see the section called “Interpreting the response”, also below.

The content of the c:request consists of any number of c:header elements, followed optionally by a c:body or a c:multipart.

A c:header element allows you to send additional HTTP headers with the request:

  1 <c:header
      name = string
      value = string />

The name and value attributes specify the name and value of the header, respectively. As we'll see below, the c:header element is also used to present the headers that the server sends back.

If you're doing an HTTP “GET”, then you don't send any content to the server, but for HTTP “POST” or “PUT” requests (among others), data is sent to the server using a c:body or c:multipart elements.

The HTTP request is formulated from the elements in the request and transmitted to the host specified by the href attribute.

Formulating the request

The c:body element holds the body (or in the case of a multipart message, each of the body parts) of the message:

  1 <c:body
      content-type = string
      encoding? = string
      id? = string
  5   description? = string>
        any content
    </c:body>

The content-type attribute specifies the media type of the body or body part, for example, “application/xml” “text/plain”, or “image/png”. In HTTP terms, this is the value used for the Content-Type header. The encoding is used for images and other non-text types, see the section called “Binary content”, below.

In some applications, usually multipart requests, it may be useful or necessary to specify a Content-ID or Content-Description in the request. You can specify these values with the id and description attributes, respectively.

After establishing the headers for a request body, the processor has to actually package it up for transmission to the server. Exactly how this packaging is done depends on the content-type specified.

  • If the content type specifies an XML media type, then the body is serialized using the options specified on the p:http-request and the resulting serialized form is sent to the server. In other words, if the body is XML, the processor does what you'd expect to send the XML over the wire.

  • If the content type does not specify an XML media type, or if an encoding is specified, then the content of the c:body element is sent directly. In this case, you must have constructed the c:body so that it contains exactly, and only, the characters that you want sent. In other words, you have to encode it before you put it in the c:body element.

Multipart requests

Sometimes you want to send more than a single document to the server. Some systems address this by specifying a specific packaging system, such as sending a single ZIP file containing all the parts, but other systems use “multipart MIME” for the packaging. In p:http-request this is supported through the use of the c:multipart element:

  1 <c:multipart
      content-type = string
      boundary = string>
        c:body+
  5 </c:multipart>

The content-type specified must be a multipart media type. If it's not specified, a value of “multipart/mixed” is used.

In the request sent to the server, all of the parts are sent in a single stream. The boundaries between each part are identified with a boundary string. It's your responsibility to specify the boundary string and it's critically important that you specify a value that will not occur in the (possibly encoded) representations of any of the parts.

Each individual c:body part is handled as described above.

Interpreting the response

How the processor interprets the part (or parts) that are returned depends critically on the value of the content type header that the server sends. A content type of “application/xml” is naturally going to be processed quite differently than a content type of “image/png”. If the c:request specifies an override-content-type, then that value is used to determine how the part (or parts) are interpreted. Even if an override is specified, however, the actual content type sent by the server will be presented in the c:header, if there is one.

In the discussion below, “content type” refers to the content type that the processor is using, either the one the server sent or the one the request specified, as appropriate.

If you make an HTTP request, your presumably expecting some sort of response. Sometimes you need to be able check the status code, inspect the headers, interrogate the relationships between the parts, etc.

In this case, you want the response to include all of the detail that it can. The XProc processor provides this in the form of a c:response element:

  1 <c:response
      status? = integer>
        (c:header*, (c:body | c:multipart)?)
    </c:response>

The response's status code is encoded in the status attribute and the headers and entity body are returned in c:header and c:multipart or c:body content.

But often, you know that you're going to get back, for example, a single XML document. If you expect the step to succeed and you just want the document back, it's tedious to have to remember to unpack it from inside the c:response wrapper every time. To alleviate this tedium, the c:request allows you to specify whether or not you want a “detailed” response:

  • If detailed is “true”, you get back a c:response element containing all the headers and the body or bodies.

  • If detailed is not specified or is explicitly “false”, the body (or each of the bodies) is converted into an XML representation and returned.

In other words, you can get all the detail if you want, but the default is just to return the document (or sequence of documents) that the server sends back in its response.

The output of a p:http-request must be XML, so the body (or each of the bodies) has to be converted into an XML representation. For media types (images, binaries, etc.) that can't be represented as a sequence of Unicode characters, the response is base64 encoded and then returned in a c:body element. If the content is base64-encoded, the encoding attribute on c:body will be set to “base64”.

If the media type isn't XML but can be represented as a sequence of Unicode characters, the content of the c:body element will be those characters. In this case, there will be no encoding attribute on the c:body.

If the response is an XML media type, the content of the constructed c:body element is the result of decoding the body as necessary, then parsing it with an XML parser. If the content is not well-formed, the step fails.

In the case of a multipart response, the same rules apply when constructing a c:body element for each body part encountered.

There's one more special case. If the status-only attribute on the c:request is “true”, the result document will always be a c:response containing only header information. The response will not be processed to produce a c:body or c:multipart element at all.

HTTP Authentication

Several attributes on the c:request control if and how authentication is performed.

If the username attribute is specified, the username, password, auth-method, and send-authorization attributes are used to handle authentication according to the selected authentication method.

The username and password specify the authentication credentials of the user. The auth-method specifies the expected authentication method. If the authentication method is “Basic” or “Digest”, authentication is handled as per [RFC 2617]. Other values are allowed, but their meaning is implementation-defined.

Authentication generally requires several messages sent back and forth between the client and the server. The client requests access, the server responds with a challenge, the client replies with appropriate credentials, and then the server sends back the actual response. If you're using basic authentication, you can avoid one round trip by setting send-authentication to “true”. If you do, the credentials are sent on the first request. This only works for basic authentication, however, because other methods require information from the challenge to construct the credentials.

Supporting other protocols

In the case of simple “GET” requests, implementors are encouraged to support as many protocols as practical. In particular, pipeline authors may attempt to use p:http-request to load documents with computed URIs using the file: scheme.

Binary content

Several steps use “base64” encoding to transmit binary data through an XProc pipeline. The encoding attribute controls the decoding of the element content for formulating the request.

A value of “base64” indicates the element's content is a base64 encoded string whose byte stream should be sent as the message body. An implementation may support encodings other than base64 but these encodings and their names are implementation-defined.

Cookies

With one exception, in version 1.0 of XProc, the p:http-request step does not provide any standard mechanisms for managing cookies. Pipeline authors that need to preserve cookies across several p:http-request calls in the same pipeline or across multiple invocations of the same or different pipelines will have to rely on implementation-defined mechanisms.

The exception arises in the case of redirection. If a redirect response includes cookies, those cookies are forwarded as appropriate to the redirected location when the redirection is followed.

This behavior allows the p:http-request step to interoperate with web services that use cookies as part of an authentication protocol.

HTML content

HTML isn't always (in fact, rarely is) well-formed XML. But it can be represented in Unicode, so by the rules in the section called “Interpreting the response”, any content identified as text/html will be encoded as (escaped) text or base64-encoded in the c:body element.

If you want to treat the HTML content as XML, you can attempt to convert it into XML using the p:unescape-markup step.

Errors

Error Description
err:C0040 Occurs if the document element of the document that arrives on the source port is not c:request.
err:C0006 Occurs if the method is not specified on a c:request.
err:C0005 Occurs if the request contains a c:body or c:multipart but the method does not allow for an entity body being sent with the request.
err:C0004 Occurs if the status-only attribute has the value true and the detailed attribute does not have the value true.
err:C0003 Occurs if a username or password is specified without specifying an auth-method, if the requested auth-method isn't supported, or the authentication challenge contains an authentication method that isn't supported.
err:C0020 Occurs if the the user specifies a value or values that are inconsistent with each other or with the requirements of the step or protocol.

Examples

Most of the examples in this section interact with small web services hosted at http://tests.xproc.org/. These services were designed to help test various aspects of the p:http-request step. As such, they tend to be small and simple, if not particularly useful.

This example does a simple “get”.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/fixed-xml"
                       method="get"/>
 10       </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <doc>
<title>Sample document</title>
<p>Hello world!</p>
</doc>

This example does a “post”. The web service always returns the same fixed RDF.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/fixed-rdf"
                       method="post">
 10           <c:body content-type="application/xml">
                <c:any-content/>
              </c:body>
            </c:request>
          </p:inline>
 15     </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<rdf:Description rdf:about="">
<dc:title>Hello world!</dc:title>
5 </rdf:Description>
</rdf:RDF>

This example is like the previous, except that the web service returns plain text.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/fixed-text"
                       method="post">
 10           <c:body content-type="application/xml">
                <c:any-content/>
              </c:body>
            </c:request>
          </p:inline>
 15     </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:body xmlns:c="http://www.w3.org/ns/xproc-step"
content-type="text/plain; charset=&#34;utf-8&#34;">Hello world!
</c:body>

This example also does a “post”, but it gets back binary.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/fixed-binary"
                       method="post">
 10           <c:body content-type="application/xml">
                <c:any-content/>
              </c:body>
            </c:request>
          </p:inline>
 15     </p:input>
      </p:http-request>
    
      <p:string-replace match="/c:body/text()"
                        replace="'… base64-binary-content-elided …'"/>
 20 </p:pipeline>
Output
1 <c:body xmlns:c="http://www.w3.org/ns/xproc-step"
content-type="image/png"
encoding="base64">… base64-binary-content-elided …</c:body>

This example shows a c:multipart result.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/fixed-multipart"
                       method="get"/>
 10       </p:inline>
        </p:input>
      </p:http-request>
    
      <p:string-replace match="c:body[@encoding='base64'
 15                     replace="'… base64-binary-content-elided …'"/>
    </p:pipeline>
Output
1 <c:multipart xmlns:c="http://www.w3.org/ns/xproc-step"
content-type="multipart/related; boundary=&#34;=-=-=-=-=&#34;"
boundary="=-=-=-=-="><c:body content-type="text/html">&lt;html xmlns='http://www.w3.org/1999/xhtml'&gt;
&lt;head&gt;
5 &lt;title&gt;Hello world!&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
&lt;h1&gt;&lt;img src='helloworld.png' alt='Hello World!' /&gt;&lt;/h1&gt;
&lt;p&gt;This is a hello world document.&lt;/p&gt;
10 &lt;/body&gt;
&lt;/html&gt;
</c:body>… base64-binary-content-elided …</c:multipart>

This example posts to an “echo” service that just sends back whatever it receives.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:wrap-sequence wrapper="c:body"/>
    
      <p:add-attribute match="/c:body"
                       attribute-name="content-type"
                       attribute-value="application/xml"/>
 10 
      <p:wrap-sequence wrapper="c:request"/>
    
      <p:set-attributes match="/c:request">
        <p:input port="attributes">
 15       <p:inline>
            <dummy href="http://tests.xproc.org/service/echo"
                   method="post"/>
          </p:inline>
        </p:input>
 20   </p:set-attributes>
    
      <p:http-request/>
    </p:pipeline>
Input Output
1 <doc xmlns:c="http://www.w3.org/ns/xproc-step">
<p>This is what gets sent.</p>
</doc>
 
1 <doc xmlns:c="http://www.w3.org/ns/xproc-step">
<p>This is what gets sent.</p>
</doc>

As you can see, we use other XProc steps to build up the request wrapper for p:http-request.

Here's an alternative way to construct the c:request document:

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:insert match="/c:request/c:body" position="first-child">
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/service/echo"
                       method="post">
 10           <c:body content-type="application/xml"/>
            </c:request>
          </p:inline>
        </p:input>
      </p:insert>
 15 
      <p:http-request/>
    </p:pipeline>
Input Output
1 <doc xmlns:c="http://www.w3.org/ns/xproc-step">
<p>This is what gets sent.</p>
</doc>
 
1 <doc xmlns:c="http://www.w3.org/ns/xproc-step">
<p>This is what gets sent.</p>
</doc>

Here we attempt and fail to connect to a password-protected web service.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/basic-auth"
                       method="get"/>
 10       </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:body xmlns:c="http://www.w3.org/ns/xproc-step"
content-type="text/html; charset=&#34;iso-8859-1&#34;">&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;
&lt;html&gt;&lt;head&gt;
&lt;title&gt;401 Authorization Required&lt;/title&gt;
5 &lt;/head&gt;&lt;body&gt;
&lt;h1&gt;Authorization Required&lt;/h1&gt;
&lt;p&gt;This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
10 credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.&lt;/p&gt;
&lt;p&gt;Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.&lt;/p&gt;
15 &lt;/body&gt;&lt;/html&gt;
</c:body>

Unfortunately, the results aren't very useful. By specifying detailed, we can get more information:

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/basic-auth"
                       method="get"
 10                    detailed="true"/>
          </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:response xmlns:c="http://www.w3.org/ns/xproc-step"
status="401">
<c:header name="Date" value="Wed, 14 Apr 2010 12:15:54 GMT"/>
<c:header name="Server" value="Apache"/>
5 <c:header name="WWW-Authenticate"
value="Basic realm=&#34;TestAuthentication&#34;"/>
<c:header name="Vary" value="Accept-Encoding"/>
<c:header name="Content-Length" value="520"/>
<c:header name="Content-Type"
10 value="text/html; charset=iso-8859-1"/>
<c:body content-type="text/html; charset=&#34;iso-8859-1&#34;">&lt;!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"&gt;
&lt;html&gt;&lt;head&gt;
&lt;title&gt;401 Authorization Required&lt;/title&gt;
&lt;/head&gt;&lt;body&gt;
15 &lt;h1&gt;Authorization Required&lt;/h1&gt;
&lt;p&gt;This server could not verify that you
are authorized to access the document
requested. Either you supplied the wrong
credentials (e.g., bad password), or your
20 browser doesn't understand how to supply
the credentials required.&lt;/p&gt;
&lt;p&gt;Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.&lt;/p&gt;
&lt;/body&gt;&lt;/html&gt;
25 </c:body>
</c:response>

Now at least we can see the status code.

If you want simply to test whether or not you can access a resource, specifying both detailed and status-only simplifies things even further.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/basic-auth"
                       method="get"
 10                    detailed="true"
                       status-only="true"/>
          </p:inline>
        </p:input>
      </p:http-request>
 15 </p:pipeline>
Output
1 <c:response xmlns:c="http://www.w3.org/ns/xproc-step"
status="401">
<c:header name="Date" value="Wed, 14 Apr 2010 12:15:59 GMT"/>
<c:header name="Server" value="Apache"/>
5 <c:header name="WWW-Authenticate"
value="Basic realm=&#34;TestAuthentication&#34;"/>
<c:header name="Vary" value="Accept-Encoding"/>
<c:header name="Content-Length" value="520"/>
<c:header name="Content-Type"
10 value="text/html; charset=iso-8859-1"/>
</c:response>

Finally, let's send the correct username and password so that we can actually get the resource!

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/basic-auth"
                       method="get"
 10                    detailed="true"
                       auth-method="Basic"
                       username="testuser"
                       password="testpassword"/>
          </p:inline>
 15     </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:response xmlns:c="http://www.w3.org/ns/xproc-step"
status="200">
<c:header name="Date" value="Wed, 14 Apr 2010 12:16:14 GMT"/>
<c:header name="Server" value="Apache"/>
5 <c:header name="Accept-Ranges" value="bytes"/>
<c:header name="Vary" value="Accept-Encoding"/>
<c:header name="Content-Length" value="174"/>
<c:header name="Content-Type"
value="text/html; charset=utf-8"/>
10 <c:body content-type="text/html; charset=&#34;utf-8&#34;">&lt;html xmlns='http://www.w3.org/1999/xhtml'&gt;
&lt;head&gt;
&lt;title&gt;Basic authentication test&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
15 &lt;h1&gt;Basic authentication test&lt;/h1&gt;
&lt;p&gt;Success!&lt;/p&gt;
&lt;/body&gt;
&lt;/html&gt;
</c:body>
20 </c:response>

If you have a tool that will allow you to watch HTTP traffic on the network, such as HTTP Scoop, then with it enabled, you'll see that the XProc processor and the server perform a little dance:

  1. XProc requests the page,

  2. the web server declines, asserting authentication is required

  3. XProc tries again, sending the credentials

  4. the web server sends back the representation.

By adding send-authorization="true", you can reduce the dance by two steps: the XProc processor will send the credentials initially and the web server will respond with the representation.

This only works for basic authentication. If you use basic authentication you really should use https: as passwords are otherwise sent unencrypted, visible to anyone with traffic monitoring tool as described above.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:xlink="http://www.w3.org/1999/xlink"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
  5 
      <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/basic-auth"
 10                    method="get"
                       detailed="true"
                       auth-method="Basic"
                       username="testuser"
                       password="testpassword"
 15                    send-authorization="true"/>
          </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:response xmlns:c="http://www.w3.org/ns/xproc-step"
status="200">
<c:header name="Date" value="Thu, 15 Apr 2010 12:47:53 GMT"/>
<c:header name="Server" value="Apache"/>
5 <c:header name="Accept-Ranges" value="bytes"/>
<c:header name="Vary" value="Accept-Encoding"/>
<c:header name="Content-Length" value="174"/>
<c:header name="Content-Type"
value="text/html; charset=utf-8"/>
10 <c:body content-type="text/html; charset=&#34;utf-8&#34;">&lt;html xmlns='http://www.w3.org/1999/xhtml'&gt;
&lt;head&gt;
&lt;title&gt;Basic authentication test&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
15 &lt;h1&gt;Basic authentication test&lt;/h1&gt;
&lt;p&gt;Success!&lt;/p&gt;
&lt;/body&gt;
&lt;/html&gt;
</c:body>
20 </c:response>

The detailed and status-only attributes aren't just for authentication. You can use them for unprotected resources as well. Here's an example that uses detailed on an ordinary resource.

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/helloworld.xml"
                       method="get"
 10                    detailed="true"/>
          </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <c:response xmlns:c="http://www.w3.org/ns/xproc-step"
status="200">
<c:header name="Date" value="Wed, 14 Apr 2010 12:16:24 GMT"/>
<c:header name="Server" value="Apache"/>
5 <c:header name="Last-Modified"
value="Wed, 03 Mar 2010 22:02:44 GMT"/>
<c:header name="ETag"
value="&#34;559da1a-ce-480eca44d2900&#34;"/>
<c:header name="Accept-Ranges" value="bytes"/>
10 <c:header name="Content-Length" value="206"/>
<c:header name="Content-Type" value="application/xml"/>
<c:body content-type="application/xml">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
15 <title>Hello world!</title>
</head>
<body>
<h1>
<img src="helloworld.png" alt="Hello World!"/>
20 </h1>
<p>This is a hello world document.</p>
</body>
</html>
</c:body>
25 </c:response>

Without detailed="true", you just get back the resource:

  1 <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
                xmlns:c="http://www.w3.org/ns/xproc-step"
                version="1.0">
    
  5   <p:http-request>
        <p:input port="source">
          <p:inline>
            <c:request href="http://tests.xproc.org/docs/helloworld.xml"
                       method="get"/>
 10       </p:inline>
        </p:input>
      </p:http-request>
    </p:pipeline>
Output
1 <html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Hello world!</title>
</head>
5 <body>
<h1>
<img src="helloworld.png" alt="Hello World!"/>
</h1>
<p>This is a hello world document.</p>
10 </body>
</html>

Just like the first example!