Edit comment LC-2324 for Mobile Web Best Practices Working Group

Quick access to LC-2267 LC-2268 LC-2269 LC-2270 LC-2289 LC-2316 LC-2317 LC-2318 LC-2319 LC-2320 LC-2321 LC-2322 LC-2323 LC-2324 LC-2327 LC-2328 LC-2329 LC-2358 LC-2359 LC-2360

Comment LC-2324

Comment Shortname:

Commenter: Luca Passani <passani@eunet.no>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeGuidelines for Web Content Transformation Proxies 1.0 W3C Working Draft 6 October 2009 Abstract Status of this Document Table of Contents Appendices 1 Introduction (Non-Normative) 1.1 Purpose 1.2 Audience 1.3 Scope 1.4 Principles 1.4.1 IAB Considerations 1.4.2 Priority of Intention 2 Terminology (Normative) 2.1 Types of Proxy "A transparent proxy is a proxy that does not modify the req... "A transparent proxy is a proxy that does not modify the req... 2.2 Types of Transformation Restructuring content is a process whereby the original layo... Recoding content is a process whereby the layout of the cont... Optimizing content includes removing redundant white space,... 3 Conformance (Normative) 3.1 Classes of Product 3.2 Normative and Informative Parts 3.3 Normative Language for Conformance Requirements 3.4 Transformation Deployment Conformance 4 Behavior of Components (Normative) 4.1 Proxy Forwarding of Request 4.1.1 Applicable HTTP Methods 4.1.2 no-transform directive in Request 4.1.3 Treatment of Requesters that are not Web browsers 4.1.4 Serving Cached Responses 4.1.5 Alteration of HTTP Header Field Values In this section, the concept of "Web site" is used (rather t... 4.1.5.1 Content Tasting 4.1.5.2 Avoiding "Request Unacceptable" Responses 4.1.5.3 User Selection of Restructured Experience 4.1.5.4 Sequence of Requests 4.1.5.5 Original Header Fields 4.1.6 Additional HTTP Header Fields 4.1.6.1 Proxy Treatment of Via Header Field 4.2 Proxy Forwarding of Response to User Agent 4.2.1 Applicable Responses 4.2.2 User Preferences 4.2.3 Receipt of Cache-Control: no-transform 4.2.4 Use of Cache-Control: no-transform 4.2.5 Server Rejection of HTTP Request 4.2.6 Receipt of Vary HTTP Header Field 4.2.7 Link to "handheld" Representation In this document the term current representation means a "sa... 4.2.8 WML Content 4.2.9 Proxy Decision to Transform 4.2.9.1 Alteration of Response 4.2.9.2 Link Rewriting In this document two URIs have the Same-Origin if the scheme... 4.2.9.3 HTTPS Link Rewriting 5 Testing (Normative) A References B Conformance Statement C Internet Content Types associated with Mobile Content D DOCTYPEs Associated with Mobile Content E URI Patterns Associated with Mobile Web Sites F Summary of User Preference Handling G Example Transformation Interactions (Non-Normative) G.1 Basic Content Tasting by Proxy G.2 Optimization based on Previous Server Interaction G.3 Optimization based on Previous Server Interaction, Server has Changed its Operation G.4 Server Response Indicating that this Representation is Intended for the Target Device G.5 Server Response Indicating that another Representation is Intended for the Target Device H Informative Guidance for Origin Servers (Non-Normative) H.1 Server Response to Proxy H.1.1 Use of HTTP 406 Status H.1.2 Use of HTTP 403 Status H.1.3 Server Origination of Cache-Control: no-transform Including a Cache-Control: no-transform directive can disrup... H.1.4 Varying Representations H.1.4.1 Use of Vary HTTP Header Field H.1.4.2 Indication of Intended Presentation Media Type of Representation I Applicability to Transforming Solutions which are Out of Scope (Non-Normative) J Scope for Future Work (Non-Normative) J.1 POWDER J.2 link HTTP Header Field J.3 Sources of Device Information J.4 Inter Proxy Communication J.5 Amendment to and Refinement of HTTP K Acknowledgments (Non-Normative)
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

Francois Daoust wrote:
> For clarification, the guidelines do not build on the assumption that
> GET is not safe.
>
> The mechanism described by Luca is actually recommended by the
> guidelines: send a GET with original headers, then send a request with
> modified headers if the first response is a "request unacceptable"
> response.

Francois, this is not what I meant. What I meant is "content tasting".
Proxies should send a GET with original headers and if they get a
response (which they probably will), they should smell the response and
figure out whether that content may be good enough for mobile (and err
on the side of assuming it is). If the content is likely to be OK for a
mobile device, no transcoding should take place at all.

This is explicitly ruled out by 4.1.5.1:

http://www.w3.org/TR/ct-guidelines/#sec-content-tasting


"The theoretical idempotency of GET requests is not always respected by
servers. In order, as far as possible, to avoid misoperation of such
content, proxies *should* avoid issuing duplicate requests and
specifically *should not* issue duplicate requests for comparison purposes."


There was no reason to add this part, except, as I mentioned in my first
message, to help novarra, whose transcoder does not behave this way.

Luca

Related issues: (space separated ids)

WG Notes: Resolution: http://www.w3.org/2009/12/10-bpwg-minutes.html#added01

Resolution: We agree and have removed the inconsistency in 4.1.5.1. Content tasting whereby the unaltered request is sent first is encouraged by the guidelines.

(Please make sure the resolution is adapted for public consumption)