default-request action is the standard way to obtain the main content.
This action is not configurable.
<flow> <default-request /> </flow>
The action has no effect if the main content is already present in
default-request uses data from the incoming request (accessible in
fit://request/request) 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
requests 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 (see
304 responses are passed, too. If no content was received, a configurable
conf/config.xml is injected to substitute the main content.
If the setting
http/pass-cache-headers is enabled and a client request contains the
If-Modified-Since header, the header is passed to the backend. If the backend responds with a
200 OK status code and a
Last-Modified header value is equal to or earlier than the value from the
If-Modified-Since 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
fit://request/content to 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
Content-Disposition header and all
X- headers. 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:
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>
A machine usable content type is deduced from the
Content-Type header (and maybe the content itself) and set as DC property
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>