Re: Beacon feedback

On Fri, May 23, 2014 at 7:43 AM, Arvind Jain <arvind@google.com> wrote:
> On Thu, May 22, 2014 at 10:34 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
>> 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.
>
> I understand that leaving out this sentence keeps the spec fully specified.
> But in a normal case of fetching a request, you'd use the entity body of the
> response. In this case, we want to discard it - to the extent that the
> browser could even close the connection after receiving the header. When we
> started discussing the spec, there were many questions explicitly about what
> would the browser do with the entity body, and whether a 302 would be
> followed for the Beacon request or is it strictly a fire and forget model.

Sure, but in the end you are using fetch and all this follows from
that algorithm. This should be no more than an informative note,
definitely not a requirement. I could maybe see a case for something
along the lines of "Once a response is a returned, the fetch MAY be
terminated.". (You don't get a response until redirects are followed
and given you follow redirects you need to get at least that far.)


>> 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.
>
> We definitely don't want to show the authentication dialog just like we
> don't want to do it for 401.

Are you sure? As this actually indicates a problem in the user's
setup. Would also be the only API that does this as far as I know.


-- 
http://annevankesteren.nl/

Received on Friday, 23 May 2014 17:07:36 UTC