Component details of a request

Last Updated : Dec 07, 2012 |
Prolog information
Metadata
Keywords:

HTTP Header Setting (Request Headers)

Requests can be made using the GET or POST HTTP method. A GET command checks if an updated version of a document exists using the configuration settings to determine whether to fetch the document or use the cached version. A POST command forces a new fetch of the document irrespective of the configuration settings and bypasses the Cache Validator step. The header settings can be controlled from within the application (for a given document), at the application server level, and at the ASR speech server level for grammars. Common headers include the following:
  • Host: Host information.
  • Accept: Acceptable media types.
  • Referrer: Referring URL.
  • Connection: Connection type, persistent or non-persistent, use close for non-persistent.
  • Cache-Control: maxage, maxstale, no-cache, no-store.
  • Cookie: If Cookies are enabled.
  • If-Modified-Since: Last-Modified from pervious fetch (GET only).
  • Expect: Waiting for continue (POST only).
  • Content-Length: Media size that is used to allocate buffer for fetching documents. Memory allocation is done block by block, if not set.
  • Content-Type: Media type that is used to decide the MIME type of the audio and is set according to the extension/MIME type mapping on the server.
POST requests support multipart or form-data to submit audio to the application server.
accept: */*
host: avb-linux.sv.avaya.com:8080
user-agent: AvayaVXI/2.0
referrer: http://avb-linux.sv.avaya.com:8080/test_promptFile.vxml
connection: close
cache-control: max-age=3600
method=GET
protocol=HTTP/1.1

URL Parsing

In this step, the protocol, the machine name, the port number, and the absolute path of the requested document is determined. This is setup through the IR or EP Administration interface when deploying the application.

Fetch versus Cache

A fetch will be performed rather than using the cache under the following conditions:
  • No maxage configured
  • No cache validator present
  • Validator has expired (or no expiration time is set)
  • An error encountered when reading the cache
The default maxage and maxstale values are configured through the EPM for Experience Portal. The expiration of the cache or the validator is configured on the application server. If expiration is not sent from the application server, the entry expires.

HTTP Header Settings (Response Headers)

  • Pragma: no cache — Do not cache
  • Cache-Control:
    • no-cache, no-store or private — Do not cache
    • maxage, s-maxage — use the max age given in the header
    • must-revalidate — Do not cache
  • Expires:
    • When does this entry expire — no conditional gets before the entry expires
  • Last-Modified
  • Date
In this example, the expiration date is later than the current date, so the cache entry is still valid and will be used. If the “Expires” header is absent, AVB will send conditional HTTP GET with If-Modified-Since and If-None-Match headers to check if the resources has been updated.
HTTP/1.1 200 OK
 Date: Tue, 23 May 2006 22:30:45 GMT
 Server: Apache/2.0.46 (Red Hat)
 Last-Modified: Tue, 28 Feb 2006 17:43:35 GMT
 ETag: "6090ec-29b-5dd53fc0"
 Accept-Ranges: bytes
 Content-Length: 667
 Cache-Control: max-age=86400
 Expires: Wed, 24 May 2006 22:30:45 GMT
 Keep-Alive: timeout=15, max=100
 Connection: Keep-Alive
 Content-Type: text/xml
In this example due to the no-cache settings and 0 value for expiration, no entry will be added to the cache for future requests thus forcing a fetch of the document for each request.
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=65F51939A8D2D86E2D31919FFF5A2DED; Path=/pizza
Cache-Control: no-cache
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Date: Tue, 23 May 2006 23:14:53 GMT
Connection: close

Cache Validation

If a document has previously been fetched and the header response information indicates that the document should be cached, the next time this document is requested, a cache entry will be found and evaluated. The cache validation logic is as follows and uses the maxage and maxstale values. These values can be specified for each individual cacheable resource such as document page, prompt and grammar in the application or on the EP and IR systems (defaults are provided). For EP, they are configured through the EPM and on IR, they are configured by editing the defaults.xml file.
Note:
The maxage and maxstale defined for speech grammars are used by speech servers and the speech server can define and override the behavior of the settings.
Freshness Life Time = maxage from header or “Expires” – “Date”
Staleness = Current Age – Freshness Life Time
Must Revalidate = “must-revalidate” from “Cache-Control”
If Current Age > maxage then the document is Expired
If Staleness < 0 then the document is Not Expired
If Must Revalidate is set then the document is treated as Expired
If Staleness is > maxstale then the document has Expired
If No Freshness Life Time is less than or equal to 0 then the document has Expired

Connections

The method of configuring connections impact performance. Persistent connections saves the time spent in parsing the URL and resolves the hostname using DNS. Configurations that use load balancers or any mechanism that changes host name to IP address mapping of application servers may not use persistent connections. Make sure persistent connections works in your environment before utilizing this option.
Persistent versus Non-Persistent
  • Persistent connections reuses existing sockets within the same call instance.
  • Non-Persistent will open a new socket connection for every request.
  • This is configurable at the process level with the default being persistent.
  • Persistent mode uses a connection table to get a Connection for a host.
  • Persistent and Non-persistent modes resolve host names using DNS and support multiple IPs.
Secured versus Non-Secured
  • Based on the protocol specified in the URL (HTTP or HTTPS)
  • Trusted client certificates are supported
  • OpenSSL is used for Secured Connections

Cookie Support

The AVB supports the use of Cookies as follows:
  • Can be enabled and disabled at the process level
  • Can not be shared across sessions
  • Collects cookies from the server
  • Ensures Expires, Domain and Path cookie attribute matches
  • Does not match request port number
Client requests a document, and receives in the response: 
–    Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT 
When client requests a URL in path "/" on this server, it sends: 
–    Cookie: CUSTOMER=WILE_E_COYOTE
Client requests a document, and receives in the response: 
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/ 
When client requests a URL in path "/" on this server, it sends: 
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001 
Client receives: 
Set-Cookie: SHIPPING=FEDEX; path=/foo 
When client requests a URL in path "/foo" on this server, it sends: 
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX