Re: 409 status code

On Mar 26, 2014, at 10:16 AM, Mike O'Neill wrote:

> Thought of an interoperability problem with the 409. If script on a page (accessed with DNT set) does a PUT update against an Azure storage blob (assuming it supports CORS), a 409 SC might be taken by the UA or add-on as a third-party rejection of DNT.

By interop problem, I meant something that you actually encounter in
practice.  PUT services typically require user authentication and always
retain the data collected (by definition).  Hence, DNT is not a relevant
concern.  If the script is doing this for the sake of tracking, then
it already has access to the window.doNotTrack value and can change
its behavior before the PUT request is sent.

Also, CORS-enabled scripts cannot be on third party sites.
That has the same effect as hosting your site on that third party,
which means the first party has no control over data collected and
no ability to adhere to DNT.  It introduces far more security and
privacy concerns than we have addressed with DNT.  I think you should
bring this up when we return to compliance.

Regardless, what matters for status codes is: how would receiving a
different status code change the behavior of the user agent?
In both cases, resolving the conflict is not something the UA can
do on its own -- it has to present the message body to the user
so that the user can resolve it.  That is why we don't need a new
status code.

....Roy