default-request action is the standard way to obtain the main content.
This action is not configurable.
<flow> <default-request [force-query-rebuild="true"]/> </flow>
The action has no effect if the main content is already present in
default-request uses data from the incoming request (accessible in
to define the request for the source server. The recipe is:
http/pass-cache-headersis enabled (see
Cookieheader from the special FIT cookies
This derives a new request to the source server from the incoming request.
The request itself is carried out as any other request and
may also be combined with other requests in a parallel
action. After the response was received, the
response body is stored in
fit://request/content/main as usual.
The main response status is checked for non-content responses. Redirects are
passed downstream. If the setting
http/pass-cache-headers is enabled
304 responses are passed, too. If no content was received, a
is injected to substitute the main content.
If the setting
http/pass-cache-headers is enabled and a client request
If-Modified-Since header, the header is passed to the backend.
If the backend responds with a
200 OK status code and a
header value is equal to or earlier than the value from the
request header, FIT automatically terminates the flow and sends a
304 Not Modified
response without a body to the client.
Since this is the main content, another copy is stored in
fit://request/content. This location is special in
that it is the default
in/out for all flow actions that modify content.
It is also the input for the
parse action that reads
text input and either continues the flow with a parsed DOM or terminates the
engine for non-DOM content (such as CSS or JS).
After the flow has finished, the engine expects
contain the main content as a DOM. Adaptive Components, image
scaling, URL rewriting and any other
built-in action will work on this DOM to craft the final response.
Finally the original status code and headers of the main response will be
passed downstream. This may include caching headers, the
header and all
Any upstream communication errors are translated into a
502 status (except
for timeouts, which are indicated by a
504 HTTP status code).
This is the basic modus operandi of the FIT engine.
If the above recipe for defining the source request is not suitable for your needs, you have three options:
Browsers follow strict rules for URL construction when HTML forms are sent as
requests. However, most URLs are constructed by backend systems that are not
required to follow the same encoding rules. For many characters, URL encoding is
optional, and some servers may require certain characters to be encoded. A
server may even choose different separators for key-value-pairs besides
Therefore, the original incoming query string is used for outgoing requests, whenever possible.
Although the data source
fit://request/request provides a parsed
<query> elements for convenient access from the
Flow and XSL transformations,
the actual URL sent in the backend request is usually read from the
There are two cases in which a new query string will be re-assembled and re-encoded:
When a request encoding conversion is configured for a source with the
<encoding> option or when the
To recode key and value strings or to add/overwrite single parameters, it is
assumed that the query string follows the
This behavior can also be configured manually. For example, if query
parameters are modified by an
fit://request/request. The action option
force-query-rebuild="true" will force the query string to be constructed from
<query> elements to reflect changes not applied to the
Another way to deal with backends requiring certain characters not to be URL
encoded, is the
<query-encoding raw="…" /> request
After the action terminates, the response parameters and data is stored for later use.
All headers and the status code is stored in
fit://request/content/main/response which is accessible with
<response content="main" url="fit://site/public/?output=bar" protocol-version="1.1" status="200" statusText="OK"> <header name="Date" value="Wed, 02 Mar 2016 16:04:34 GMT"/> <header name="Server" value="Apache"/> <header name="Content-Type" value="text/html"/> <body src="fit://request/content/main"/> </response>
The response data can also be used to examine request errors. In that case, the
will be zero or negative:
<response content="main" url="http://example.com/" protocol-version="1.1" status="-1" statusText="Loading http://example.com/ is not allowed"/>
<response content="main" url="http://blackhole.webpagetest.org/" protocol-version="0.0" status="-1" statusText="Connection timed out after 3003 milliseconds"/>
A machine usable content type is deduced from the
Content-Type header (and
maybe the content itself) and set as DC
content/<type>. A typical content
section in the DC may look like this:
<content> <html/> <mime>text/html</mime> </content>
This is useful to restrict execution of Flow actions for certain content types:
<flow> <default-request /> <dump if="content/mime = 'image/bmp'" /> <regex pattern="..." replace="..." if="content/js" /> <parse /> <xslt src="..." if="content/html" /> </flow>