- From: Anne van Kesteren <notifications@github.com>
- Date: Tue, 05 Jan 2021 23:49:23 -0800
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1132/755142776@github.com>
> if the user hits Cancel on the auth prompt, then the request proceeds in order to display the response body from the server. Ah yeah, that's a good point. I haven't played with 407 and naïvely thought that if that was declined you would end up with a network error. If they are no different from 401s the new capability is mostly getting access to them without user interaction. > we return the 401/407 response to the Service Worker and we don't show the auth prompt at all. So, I would not expect a prompt when you hand the response to the service worker, but rather when the service worker hands the response to the browsing context navigating. Or is that what you meant? The main risk I see with revealing 407 is that sites can figure out the user is behind a proxy. As discussed in https://github.com/whatwg/fetch/issues/1007 there might be various ways to do this already, but perhaps this gives them more bits of information? Unsure. (I don't think it's a problem for sites to access a 401, they can do so already with `fetch()`.) (Another somewhat-related question I have is how you handle cross-origin nested browsing contexts navigating to such responses, but maybe we should tackle that separately.) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/fetch/issues/1132#issuecomment-755142776
Received on Wednesday, 6 January 2021 07:49:36 UTC