Re: Examining the 'no server modification' requirement

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