The HTTP serializer performs streaming. If its input data consists of a stream of short character SAX events, such as those produced by the Request generator the URL generator, the SQL processor, or converter processors, it is possible to serialize an "infinitely" long document.
HTTP Serializer
- 1. Scope
- 2. Configuration
- 3. Content Type
- 4. Binary Mode
- 4.1. Input Document Format
- 4.2. Example
- 5. Text Mode
- 5.1. Input Document Format
- 5.2. Character Encoding
- 5.3. Specifying Headers
- 5.4. Example
1. Scope
Serializers are processors with no XML output. A serializer, just like any processor, can access files, connect to databases, and take actions depending on its inputs.
The HTTP serializer supports decoding binary or text data encapsulated in XML documents and sending it into an HTTP response. Typically, this means sending data back to a client web browser. This can be done in a Servlet environment or a Portlet environment.
2. Configuration
The configuration consists of the following optional elements:
Element Name | Type | Purpose | Default Value |
---|---|---|---|
status-code | valid HTTP status code | HTTP status code sent to the client | SC_OK (HTTP code 100) |
error-code | valid HTTP error code | HTTP error code sent to the client | none |
content-type | content type, without any attributes | Indicates the content type to send to the client (see decision algorithm below). | application/octet-stream for binary mode, text/plain for text mode
|
force-content-type | boolean |
Indicates whether the content type provided has precedence (see
decision algorithm below). This requires a
content-type element.
|
false |
ignore-document-content-type | boolean | Indicates whether the content type provided by the input document should be ignored (see decision algorithm below). | false |
encoding | valid encoding name | Indicates the text encoding to send to the client (see decision algorithm below). | utf-8 |
force-encoding | boolean |
Indicates whether the encoding provided has precedence (see
decision algorithm below). This requires an
encoding element.
|
false |
ignore-document-encoding | boolean | Indicates whether the encoding provided by the input document should be ignored (see decision algorithm below). | false |
header |
Adds a custom HTTP header to the response. The nested elements
name and value contain the name and
value of the header, respectively. You can add multiple headers.
|
none | |
cache-control/use-local-cache | boolean | Whether the resulting stream must be locally cached. For documents or binaries that are large or known to change at every request, it is recommended to set this to false. | true |
empty-content | boolean | Forces the serializer to return an empty content, without reading its data input. | false |
Example:
3. Content Type
The content type sent to the HTTP output is determined according to the following priorities:
-
Use the content type in the
content-type
element of the configuration ifforce-content-type
is set totrue
. -
Use the content type set in the input document with the
content-type
attribute, if any, unless theignore-document-content-type
element of the configuration is set totrue
. -
Use the content type in the
content-type
element of the configuration, if specified. -
Use
application/octet-stream
in binary mode, ortext/plain
in text mode.
4. Binary Mode
4.1. Input Document Format
The binary mode is enabled when the root element of the input document
contains an xsi:type
attribute containing a reference to the
xs:base64Encoding
type.
In this mode, all the character content under the root element is considered as Base64-encoded binary content according to the binary document format, for example:
An optional content-type
attribute provides information about
the content type of the document. This attribute may be used to set the HTTP
content-type
header, as discussed above.
4.2. Example
Here is an example connecting the URL generator to the serializer, and the appropriate configurations:
5. Text Mode
5.1. Input Document Format
The text mode is enabled when the root element of the input document
contains an xsi:type
attribute containing a reference to the
xs:string
type.
In this mode, all the character content under the root element is considered as text content according to the text document format, for example:
An optional content-type
attribute provides information about
the content type of the document. This attribute may be used to set the HTTP
content-type
header, as discussed above. In text mode, the
content-type
attribute can also have a charset
parameter providing a hint at the preferred character encoding for the text,
as discussed below, for example text/plain; charset=iso-8859-1
.
Note that the XML input document infoset internally represents characters
in Unicode and therefore does not require encoding information.
5.2. Character Encoding
The character encoding sent to the HTTP output is determined according to the following priorities:
-
Use the encoding in the
encoding
element of the configuration ifforce-encoding
is set totrue
. -
Use the encoding set in the input document with the
content-type
attribute, if any, unless theignore-document-encoding
element of the configuration is set totrue
. -
Use the encoding in the
encoding
element of the configuration, if specified. -
Use
utf-8
.
5.3. Specifying Headers
RFC 2183
describes the Content-Disposition
HTTP header, used by web
browsers to decide how to display an attachement. A value of
inline
means that a browser will try to use a plugin to display
for example a PDF file. A value of attachement
causes the
browser to ask the user to save the file, optionally proposing a file name.
The following two example show how it is possible to specify such headers
with the HTTP serializer:
Using a plugin:
Saving a file to disk:
5.4. Example
Here is an example connecting the URL generator to the serializer, and the appropriate configurations:
When using the command-line mode, instead of sending the output through HTTP, the HTTP serializer sends its output to the standard console output. In such a case, the parameters that do not affect the content of the data, such as content-type, status-code, etc. are ignored.
The HTTP serializer sends the cache control HTTP headers, including
Last-Modified
, Expires
and Cache-Control
.
The Content-Type
and Content-Length
headers are also
supported.