On 11/01/2008, at 4:46 PM, Brad Porter wrote:
The no-server-modification requirement originally arose in the voice
browser working group due to the practical experience of the
participant companies that in many large IT-based companies, the
website environment is a shared environment that supports segmented
ownership of documents and content, but not segmented ownership of
website configuration. Given this is a per-resource policy, it made
sense to associate the policy meta-data directly with the resource.
This is why the original NOTE only focused on the Processing
Instruction and did not include the HTTP headers.
Further, there are a number of cases that voice browser working
group participants identified where the resources are static and can
be properly cached. Proper HTTP caching was heavily used for static-
only content in the voice browser realm given the tighter response
time requirements expected on the phone. Therefore, requiring
server validation would potentially require sites to invoke a
dynamic pathway for static XML data, or worse eliminate effective
caching altogether.
That's the beauty of the server-side model; it works very well with
caching.
E.g., if the request is
GET /foo HTTP/1.1
Host: www.example.com
Referer-Root: http://other.example.org/
The response could be
HTTP/1.1 200 OK
Cache-Control: max-age=3600
Vary: Referer-Root
...
which tells a cache that it can serve that response to other clients,
*as long as* they send the same Referer-Root header. The cache ends up
enforcing the server's policy on its behalf, without any new software.
Cheers,
--
Mark Nottingham [EMAIL PROTECTED]
