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

Quick access to LC-2377 LC-2378

Comment LC-2378

Comment Shortname:

Commenter: Eduardo Casais <casays@yahoo.com>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract Status of this Document Table of Contents 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 2.2 Types of Transformation 2.3 User Interaction 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 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 User Preferences 4.2.2 Receipt of Cache-Control: no-transform 4.2.3 Use of Cache-Control: no-transform 4.2.4 Server Rejection of HTTP Request 4.2.5 Receipt of Vary HTTP Header Field 4.2.6 Link to "handheld" Representation 4.2.7 WML Content 4.2.8 Proxy Decision to Transform 4.2.8.1 Alteration of Response 4.2.8.2 Link Rewriting 4.2.8.3 HTTPS Link Rewriting 5 Testing (Normative) A References B Conformance Statement C Internet Content Types associated with Mobile Content D Internet Content Types associated with Data Content E DOCTYPEs Associated with Mobile Content F URI Patterns Associated with Mobile Web Sites G Summary of User Preference Handling H Example Transformation Interactions (Non-Normative) H.1 Basic Content Tasting by Proxy H.2 Optimization based on Previous Server Interaction H.3 Optimization based on Previous Server Interaction, Server has Changed its Operation H.4 Server Response Indicating that this Representation is Intended for the Target Device H.5 Server Response Indicating that another Representation is Intended for the Target Device I Informative Guidance for Origin Servers (Non-Normative) I.1 Server Response to Proxy I.1.1 Use of HTTP 406 Status I.1.2 Use of HTTP 403 Status I.1.3 Server Origination of Cache-Control: no-transform I.1.4 Varying Representations I.1.4.1 Use of Vary HTTP Header Field I.1.4.2 Indication of Intended Presentation Media Type of Representation J Applicability to Transforming Solutions which are Out of Scope (Non-Normative) K Scope for Future Work (Non-Normative) K.1 POWDER K.2 link HTTP Header Field K.3 Sources of Device Information K.4 Inter Proxy Communication K.5 Explicit Consent K.6 Amendment to and Refinement of HTTP L 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:

Section 4.1.5.5 states the following:

"When forwarding an HTTP request with altered HTTP header fields, in addition
to complying with the rules of normal HTTP operation, proxies must include in
the request additional fields of the form "X-Device-"<original header name>
whose values are verbatim copies of the corresponding unaltered header field
values, so that it is possible to reconstruct the original header field values."

The intent of the statement is that the specific way of naming the backup fields
and the fact that their values are the original, unaltered ones sent by the device
are, together, the indispensable elements serving to restore the original HTTP
header fields.

The construction of the sentence should fully reflect this intent. I suggest
modifying it thus:

"[...], so that it is possible to reconstruct the original header fields."

This makes it clear that the conventions adopted enable servers to reconstruct
the entire HTTP header fields (names and values), not just their values.


E.Casais

Related issues: (space separated ids)

WG Notes: Implemented in draft 1za

Resolution: The group agrees and has integrated the proposed change in the specification.

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