- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 28 Apr 2015 04:07:51 +0000
- To: "Roy T. Fielding" <fielding@gbiv.com>
- Cc: Kari Hurtta <hurtta+ietf@siilo.fmi.fi>, HTTPBIS working group mailing list <ietf-http-wg@w3.org>, Tim Bray <tbray@textuality.com>
Roy T. Fielding <fielding@gbiv.com>: (Mon Apr 27 21:45:54 2015) > Right, that implementation can be ignored -- it is an application-specific hack > defined incorrectly in every respect (wrong class, wrong behavior, wrong > dependence on response extension header fields, wrong use of x-*, etc.). > > ....Roy Yes, for application that new use does not cause problems https://msdn.microsoft.com/en-us/library/gg651019 | If an X-MS-Location header is present in the response, all subsequent requests SHOULD use the URL | specified within the X-MS-Location header. If the server does not provide an X-MS-Location header in | its response to the client, then the full Autodiscover command process is followed, as specified in | [MS-ASCMD]. Probably right thing to do anyway (that is: run Autodiscover) There was https://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0919.html | Would immensely appreciate an error code for legal interference. If same code is used for something other, is this screwing collected statistics? But in practise this ActiveSync runs on https, so it unlikely(?) that interfering party is able to insert that new exit code so that client accepts connection. https://msdn.microsoft.com/en-us/library/ee178067%28v=exchg.80%29.aspx | There are no special security considerations specific to this specification. It is recommended that | communication between the client and server occur across an HTTP connection secured by the Secure | Sockets Layer (SSL) protocol. | | When connecting to a server using SSL, clients are required to support server certificates that use the | Subject Alternative Name for domain names, as specified in [RFC4985], as well as wildcard certificate | names, as specified in [RFC2818] and [RFC3280]. I guess that this "An HTTP Status Code to Report Legal Obstacles" in practise apply only to http connections -- https connections just fails (or clients/browsers ignore certificate error?). ( Perhaps somewhere trusted CA can do that, but I think that discussion goes out of scope. And this case perhaps that http status code is not used anyhow. https://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0900.html ) / Kari Hurtta >> On Apr 27, 2015, at 4:39 AM, Kari Hurtta <hurtta+ietf@siilo.fmi.fi> wrote: >> >> >> >> An HTTP Status Code to Report Legal Obstacles >> http://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-00 >> >> http://tools.ietf.org/html/draft-ietf-httpbis-legally-restricted-status-00#section-3 >> 451 Unavailable For Legal Reasons >> >> >> >> I do not know that is this dangerous, but someone seems >> already use 451 code. >> >> >> 3.1.5.2.2 HTTP Error 451 >> https://msdn.microsoft.com/en-us/library/gg651019 >> >> >> Perhaps someone may misclassify ActiveSync redirection >> as "Unavailable For Legal Reasons". >> >> Seems that ActiveSync can not misclassify >> "Unavailable For Legal Reasons" as redirection >> bacause it needs X-MS-Location: header field. >> >> I noticed that from Wikipedia. >> >> https://en.wikipedia.org/wiki/List_of_HTTP_status_codes >> >> >> This is most likely not serius problem. And 451 is not >> listed on >> >> https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml >> >> so this is mostly Microsoft's problem. >> >> >> / Kari Hurtta >> ( not member of HTTPBIS working group (mailing list) ) >> >> >> >> >
Received on Tuesday, 28 April 2015 12:29:00 UTC