- From: Mark Nottingham <mnot@yahoo-inc.com>
- Date: Fri, 11 Jan 2008 17:15:03 +1100
- To: Brad Porter <bwporter@yahoo.com>
- Cc: "WAF WG \(public\)" <public-appformats@w3.org>
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 mnot@yahoo-inc.com
Received on Friday, 11 January 2008 06:15:28 UTC