Re: Beacon feedback

OK I'll make the change for the language as you suggest.

Re. 407, what is your suggestion. I'm not sure what should be done.



On Fri, May 23, 2014 at 10:07 AM, Anne van Kesteren <annevk@annevk.nl>wrote:

> 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 Monday, 26 May 2014 03:00:31 UTC