- From: Sean Patterson <SPatterson@Novarra.com>
- Date: Fri, 25 Jul 2008 15:15:55 -0500
- To: "public-bpwg-ct" <public-bpwg-ct@w3.org>
I guess the bigger question here is why Jo has Francois listed in his spam filter (or is the entire w3.org domain?). :-) :-) > -----Original Message----- > From: public-bpwg-ct-request@w3.org [mailto:public-bpwg-ct-request@w3.org] > On Behalf Of Jo Rabin > Sent: Friday, July 25, 2008 6:34 AM > To: public-bpwg-ct > Subject: [Fwd: ACTION-818: Write some text for CT Appendix B.3] > > > Just a quick note to thank Francois for his contribution, and to explain > why I did not acknowledge it when publishing the last draft, and why his > text did not make it into the document. > > Well. It's all a terrible mistake. I found it in my spam folder this > morning. > > Huge apologies to Francois for this terrible insult. In the interests of > leaving the document stable before the LC resolution next Thursday, > Francois has agreed that we can review B.3 later. Any changes we make to > it (post last call) won't be substantive (as it is an example) so won't > affect progress on the Rec track. > > Jo > -------- Original Message -------- > Subject: ACTION-818: Write some text for CT Appendix B.3 > Resent-Date: Wed, 23 Jul 2008 13:48:09 +0000 > Resent-From: public-bpwg-ct@w3.org > Date: Wed, 23 Jul 2008 15:47:32 +0200 > From: Francois Daoust <fd@w3.org> > To: public-bpwg-ct <public-bpwg-ct@w3.org> > > > Hi, > > This is my contribution for Appendix B.3. > > It's a bit long, but it's also the longest scenario we have, I guess. > Jo, feel free to adjust the wording as necessary for this to be > considered as real English ;-) > > Francois. > > > ----- > Steps 1 to 8 are an example of a series of events that may lead a proxy > to choose to optimize its interactions with a Web Site by sending > requests with altered headers directly. > Steps 9 to 12 detail how a server may advise the proxy that the > optimization is not valid for all resources, and the behavior of the > proxy on receipt of such information. > Steps 13 to 16 explain the behavior of the proxy for subsequent requests. > > 1. The user requests resource P on a Web Site S. > 2. The proxy intercepts the request, and requests resource P with > original headers. > 3. The server does not vary its representations for resource P, > determines that the available representation does not meet e.g. the > original Accept header, and returns an HTTP Status 406 Not Acceptable > response. > 4. The proxy receives the unacceptable response, and re-requests > resource P with altered headers. > 5. The server returns the representation of resource P compatible with > the altered headers. > 6. The proxy parses the response, may apply transformation if needed and > possible, and forwards the response to the user. > 7. The user browses the response and clicks on a link to resource Q. > 8. The proxy intercepts the request, determines (by unspecified means) > that resource Q is on the same Web Site S as resource P, remembers the > unacceptable response it received for the request on resource P, and > requests resource Q directly with altered headers. > > 9. The server has available different representations of resource Q > based on the User-Agent and Accept headers, and returns the > representation of resource Q adapted to the altered headers served with > an HTTP Vary header set to "User-Agent, Accept". > 10. The proxy detects the HTTP Vary header, and re-requests resource Q > with original headers. > 11. The server returns the representation of resource Q adapted to the > original headers. > 12. The proxy parses the response, may apply transformation if needed > and possible, and forwards the response to the user. > > 13. The user browses the response and clicks on another link to resource > Z. > 14. The proxy intercepts the request, determines (by unspecified means) > that resource Z is on the same Web Site S as resources P and Q, > remembers that the server varies its representations for resource Q, and > requests resource Z with original headers. > 15. The server has available different representations of resource Z > based on the User-Agent and Accept headers, and returns the > representation of resource Z adapted to the altered headers served with > an HTTP Vary header set to "User-Agent, Accept". > 16. The proxy parses the response, may apply transformation if needed > and possible, and forwards the response to the user. > ----- >
Received on Friday, 25 July 2008 20:15:29 UTC