- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 22 May 2014 19:34:28 +0200
- To: Arvind Jain <arvind@google.com>
- Cc: Jonas Sicking <jonas@sicking.cc>, Jatinder Mann <jmann@microsoft.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>, Mike West <mkwst@google.com>
On Thu, May 22, 2014 at 3:52 PM, Arvind Jain <arvind@google.com> wrote: > On Mon, May 19, 2014 at 2:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> How is the second part not covered in Fetch? It does not say user >> agents have to do anything with the entity body. > > It seems to me that this is an important detail that is good to mention > explicitly. We had lot of questions on how to handle the beacon response > when designing the API. So I'd like to keep it there. If you have more information on what kind of confusion there was that'd be great. I'd like Fetch to be as clear as possible. Can you at least remove the bit about headers and redirects? There's no platform API that can configure not to follow redirects so there should not be any confusion there. > OK fixed. Added the http/https restriction and linked directly to url > parser. Excellent. >> Did you look into proxy authentication? > > I'm not sure about this. Please help me understand this more. Currently we > don't use it. When there's a 407 response, whether there's going to be an authentication dialog and whether we want to avoid that in this case because the site might already have gone away. In general we don't really have a good story for this. Mostly curious how sendBeacon() implementations are handling this. >> Yes, you need to set the context field of the request to ping. > > Still trying to figure this out. Any help would be greatly appreciated. In step 10 you create a new request. Request has a field called context: http://fetch.spec.whatwg.org/#concept-request-context For sendBeacon() it should be set to the ping value. -- http://annevankesteren.nl/
Received on Thursday, 22 May 2014 17:35:01 UTC