Re: Beacon feedback

Hi Anne,
The updated draft is at
https://w3c.github.io/web-performance/specs/Beacon/Overview.html
Please review (comments inline below).

Thanks,
Arvind

On Mon, May 19, 2014 at 2:16 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Sun, May 18, 2014 at 9:25 PM, Arvind Jain <arvind@google.com> wrote:
> > On Sun, May 18, 2014 at 6:00 AM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> "User agents MUST honor the HTTP headers (including, in particular,
> >> redirects and HTTP cookie headers), but MUST ignore any entity bodies
> >> returned in the response" is still there.
> >
> > This one is not mentioned in the processing model (I'm aware that the
> first
> > part of this sentence  that response headers must be honored is redundant
> > with Fetch, but the part about ignoring entity body is not). I felt this
> is
> > important to mention. Please let me know if you strongly feel we should
> > remove the first part, in which case, I can change it into a Note. So
> I'll
> > keep the "ignore entity body" and move the "honor response headers" to a
> > Note. But I like it better the way it is.
>
> 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.


>
>
> >> Because? Also, you did not answer my question about further
> >> restricting this to http/https.
> >
> > I'll add  "restricting to http/https". Why is the current link to
> > "Resolve-a-url" bad?
>
> It seems like a level of indirection that is not warranted.
>

OK fixed. Added the http/https restriction and linked directly to url
parser.


>
>
> >> Because?
> >
> > You asked to file a bug on Fetch. What is the issue with the way we have
> > currently written it?
>
> You're doing this: http://annevankesteren.nl/2014/02/monkey-patch
>
> I added a "authentication flag" to Fetch. By default it is unset and
> should therefore cover your needs. That is, you can remove the
> requirement from your specification and nothing further is required.
>

OK. I've removed the sentence from the spec. Thanks for adding that to
Fetch.


>
> Did you look into proxy authentication?
>

I'm not sure about this. Please help me understand this more. Currently we
don't use it.


>
>
> >> Is it okay if the Beacon-Age header can be set by XMLHttpRequest?
> >> Should it become a restricted header?
> >
> > Seems fine. Do I need to do something in this spec about it?
>
> If it needs to be a restricted header you need to file a bug on Fetch.
> Otherwise nothing needs to be done.
>
>
> >> What about CSP? Should we introduce a "ping" request context for <a
> >> ping> and sendBeacon()? And a ping-src directive or some such maybe.
> >> (Any reason it's sendBeacon() and not sendPing()?)
> >
> > Seems fine. Again, do I need to do something about it in this spec?
>
> 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.


>
>
> --
> http://annevankesteren.nl/
>