Subject: Re: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-02.txt

From: Dzonatas Sol <[email-masked]>
Date: Wed, 01 Jun 2011 13:26:09 -0700

"
Proposed:

5.9.  strict-xhtml

    o  Browser Hint Name: strict-xhtml
    o  Description: Validation is enforced or is required before any 
expected requests
        or responses are allowed and processed. This hint neither 
prescribes any
        particular validation scheme nor prescribes any methods of 
invocation either
        before or after any given validation scheme.
    o  Value Type: true | false
    o  Contact: [email-masked]
"

One example, if an intermediary detects javascript comments within tags 
(i.e. <script>// comments</script>, <script>/* comments */</script>) 
then those may be changed to XML style comments (<? comments ?>), 
removed, or aborted with one of the HTTP status 4XX codes. That example 
could be activated by the POST method with descriptors, and the hint 
reveals these methods are already allowed. They were proven comments 
that were not requested.

That hint makes more sense in reverse POST events, gentler like how 
sandboxes work yet without specific emulation or virtual machine code.

On 05/30/2011 11:28 PM, Mark Nottingham wrote:
> FYI. Diffs at:
>    http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-browser-hints-02
>
> Changelog:
>    - removed Ref header and rearranged referer-based hints
>    - added 'prefixlist' value type
>    - changed omit-cookies from list of cookie names to prefixlist
>    - added caching advice for 404s
>
> Feedback appreciated, as always.
>
>
>
> Begin forwarded message:
>
>    
>> From: [email-masked]
>> Date: 31 May 2011 4:22:29 PM AEST
>> To: [email-masked]
>> Subject: I-D Action: draft-nottingham-http-browser-hints-02.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>> 	Title           : HTTP Browser Hints
>> 	Author(s)       : Mark Nottingham
>> 	Filename        : draft-nottingham-http-browser-hints-02.txt
>> 	Pages           : 9
>> 	Date            : 2011-05-30
>>
>>    Over time, Web browsers have adapted how they use HTTP based upon
>>    common server configurations and behaviours.  While this is necessary
>>    in the common case, it can be detrimental for performance and
>>    interoperability.
>>
>>    This document establishes a mechanism whereby origin servers can make
>>    available hints for browsers about their preferences and
>>    capabilities, without imposing overhead on their interactions or
>>    requiring support for them.
>>
>>    This is intended to allow browsers to safely optimise connections to
>>    servers.
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-02.txt
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>      
> --
> Mark Nottingham   http://www.mnot.net/
>
>
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>    

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Jun 2011 07:05:51 +1000

Browser-hints are targeted at browsers; see the requirements in the draft.

On 02/06/2011, at 6:26 AM, Dzonatas Sol wrote:

>   o  Description: Validation is enforced or is required before any expected requests
>       or responses are allowed and processed. This hint neither prescribes any
>       particular validation scheme nor prescribes any methods of invocation either
> One example, if an intermediary detects javascript comments within tags (i.e. <script>// comments</script>, <script>/* comments */</script>) then those may be changed to XML style comments (<? comments ?>), removed, or aborted with one of the HTTP status 4XX codes. That example could be activated by the POST method with descriptors, and the hint reveals these methods are already allowed. They were proven comments that were not requested.
> 
> That hint makes more sense in reverse POST events, gentler like how sandboxes work yet without specific emulation or virtual machine code.
>

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 01 Jun 2011 14:28:10 -0700

Exactly, thanks.

In "1.  Introduction":
"
    These are just two examples of common, conservative behaviour by
    browsers that is good for interoperability, but potentially bad for
    performance in certain circumstances.

    This memo proposes a mechanism whereby a HTTP server can advertise
    hints for browsers (and other clients), so that communication with
    them can be optimised.
"

Updated for requirements of RFC2119:

"
Proposed:

5.9.  strict-xhtml

   o  Browser Hint Name: strict-xhtml
   o  Description: Validation SHOULD be enforced by the browser or SHOULD be
       required by the HTTP client/server that are related to the 
mechanisms, as
       described by section 1, before any expected requests or responses are
       allowed and processed. This hint neither prescribes any 
particular validation
       scheme nor prescribes any methods of invocation either before or 
after any
       given validation scheme.
   o  Value Type: true | false
   o  Contact: [email-masked]
"

On 06/01/2011 02:05 PM, Mark Nottingham wrote:
>> One example, if an intermediary detects javascript comments within tags (i.e.<script>// comments</script>,<script>/* comments */</script>) then those may be changed to XML style comments (<? comments ?>), removed, or aborted with one of the HTTP status 4XX codes. That example could be activated by the POST method with descriptors, and the hint reveals these methods are already allowed. They were proven comments that were not requested.
>>

--

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Jun 2011 07:38:07 +1000

If you can convince a browser to implement that, great.

On 02/06/2011, at 7:28 AM, Dzonatas Sol wrote:

>      required by the HTTP client/server that are related to the mechanisms, as
>      allowed and processed. This hint neither prescribes any particular validation
>      scheme nor prescribes any methods of invocation either before or after any
>      given validation scheme.

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 01 Jun 2011 14:54:19 -0700

Without my specific implementation, let me point out the implied 
strictness of the .XXX domain. I've known implementations that try the 
cookie-cutter approach to create walled gardens around minorities, yet 
those implementations have only broken families by blind's eye to 
enforcement of rules that separate kids from parents in any way, 
especially those in potentially exploited situations or uncontrolled 
conditions.

Instead of those cookie-cutter cases, the most successful guideline is 
no age, no sex, and no location. The "strict-xhtml" hint can help 
balance these well known experiences.

--

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 01 Jun 2011 16:12:19 -0700

For non-.XXX domains, there is also this Assembly approved 
implementation, already: 
http://www.leginfo.ca.gov/pub/11-12/bill/asm/ab_0151-0200/ab_155_bill_20110502_amended_asm_v97.html

That begs the question on how browsers need to implement the wholesaler 
perspective or else what compliant implementations exist due to http 
status code 402 (obvious optimization), which "strict-xhtml" may help 
filter-in currency per state by presence.

On 06/01/2011 02:54 PM, Dzonatas Sol wrote:
>>>>> One example, if an intermediary detects javascript comments within 
>>>>> tags (i.e.<script>// comments</script>,<script>/* comments 
>>>>> */</script>) then those may be changed to XML style comments (<? 
>>>>> comments ?>), removed, or aborted with one of the HTTP status 4XX 
>>>>> codes. That example could be activated by the POST method with 
>>>>> descriptors, and the hint reveals these methods are already 
>>>>> allowed. They were proven comments that were not requested.
>>>>>
>>>>> That hint makes more sense in reverse POST events, gentler like 
>>>>> how sandboxes work yet without specific emulation or virtual 
>>>>> machine code.
>>>>>

--