HTTP Client Module

The HTTP Client module provides a way to send an HTTP request and deal with its response from XPath expressions. The homepage of the module is: http://expath.org/modules/http-client/. There are also specific info for the implementation for Saxon.

Todo

Look for issues in this issue list.

This user-level HTTP Client GUI for Mac OS X can be of some interest while developing or debugging a component using the EXPath HTTP Client.

Testing

See this interesting discussion about testing HTTP Client implementations.

A web application has been deployed at http://expath.org/modules/http-client/test/, to help testing the HTTP Client implementations. The idea is to maintain, within the same effort, suites of test cases divided into two parts. Each case define the call to http:send-request() to issue, and the assertions to check on the server part. The server sends back an XML document, either <pass>...</pass> when everything is ok or a failure document with the causes of failure.

The server part is developed in Java as a WAR file, and the test suites use Jeni's XSpec framework. Actually I had to change a few things in the XSpec code as for now, what I think are bugs, but have reported them. So hopefully they should be integrated within the main branch. I wrote also a simple implementation to generate XQuery testing modules, alongside the XSLT stylesheet supported by XSpec. (note: all those changes are in the XSpec trunk, and we expect to make a new XSpec release within the next few weeks)

Schemas

Markus Pilman, from the FLWOR foundation, contributed an XSD schema for the elements in the http:* namespace (request, response, header, etc.): File:Http-client-mpilman.xsd.

Serialization

Proposed change to the current draft, regarding the serialization of bodies. It should be possible to set any serialization parameter, as defined in XSLT and XQuery Serialization 1.1. Consistently with the current definition of fn:serialize(), @use-character-maps cannot be used. The @include-content-type serialization parameter does not make sense here, and is not available on the http:body element. Its value is always "yes". The @format attribute, which was introduced after xsl:result-document, has been removed too (at least one leading XSLT 2.0 processor does not allow an extension function to access the named output definitions, see this thread).

The @src attribute is not in Serialization 1.1. It is mutually exclusive with all other attributes (except the required @media-type). The method "binary" has been added too (must be defined precisely, but normally should only accept xs:base64Binary and xs:hexBinary items and serialize them as binary).

<http:body media-type = { string }
           src? = uri
           method? = { "xml" | "html" | "xhtml" | "text" | "binary"
             | qname-but-not-ncname }
           byte-order-mark? = { "yes" | "no" }
           cdata-section-elements? = { qnames }
           doctype-public? = { string }
           doctype-system? = { string }
           encoding? = { string }
           escape-uri-attributes? = { "yes" | "no" }
           indent? = { "yes" | "no" }
           normalization-form? = { "NFC" | "NFD" | "NFKC" | "NFKD"
             | "fully-normalized" | "none" | nmtoken }
           omit-xml-declaration? = { "yes" | "no" }
           standalone? = { "yes" | "no" | "omit" }
           suppress-indentation? = { qnames }
           undeclare-prefixes? = { "yes" | "no" }
           output-version? = { nmtoken }>
   any*
</http:body>