https://github.com/w3c/navigation-error-logging/pull/30
igrigorik: included the 500 requests yesterday
... 4xx won't be part of it
... only 3xx
yoav: is there a mechanism for site owners to know about 404 errors?
... even they're content errors
igrigorik: 500 are already logged
... 404 can already be extracted
... shooting for the minimal here: just protocol errors
yoav: so 5xx is for gateways that may have lost the requet along the way
igrigorik: yes
... content errors and application errors shoulnd't be included imo
yoav: makes sense
... could be worthwhile to know that logic in the spec btw
... adding a note on why 4xx aren't there
Todd: still little ensure on 5xx
... might make it optional
... it's a little on a the boundary
igrigorik: in our current implementation, we report them. it's convenient for folks that are using it and in fact, they'd prefer more data but I'm pushing back
todd: I'm imagining the case where they wouldn't want to see the 500
igrigorik: [examples like CDNs]
... to start, we could make it optional and see the experience
yoav: opt-in by apps or by implementation?
igrigorik: "user agent MAY report 5xx" and tweaks with experience
... I'll update the proposal to make it optional and add a note on 4xx
https://github.com/w3c/navigation-error-logging/pull/29
igrigorik: unregister report uris
... seveal report uris for reliability purposes
... we'd like to provide a way to remove them
... if the report uri returns a 410, that's a signal it needs to be removed
... second case is for the user agent to GC the report URIs if it wants to
... (such as multiple failures)
todd: does 410 need an age so that the report URI can unblock itself?
igrigorik: not sure
... there is also retry after with the max-age
... you could respond that
... not sure if we need it in the spec
todd: don't think it's important to have in the first iteration but could imagine scenarios for it
igrigorik: I'll open a new bug and iterate there
... can I merge the pull requests?
plh: sure
[others are ok]
igrigorik: can we rename the repo to network-error-logging
plh: can we publish the FPWD for NEL?
[no objection heard]
Resolved: NEL to FPWD
igrigorik: looking at service worker and sync'ing our API with it
... editorial exercise
... moved the Performance interface into PT
... so a bit of clean-up
... also in UT and RT to remove references to window
... since it's also available on worker
plh: did you move Timing-Allow-Origin as well?
igrigorik: not yet but agree to move
plh: I'll do the merge by tomorrow
https://github.com/w3c/hr-time/issues/1#issuecomment-75820353
igrigorik: related to service worker as well
... making the timeline start consistent
... ie all start if the start of the worker (dedicated or shared)
michael: for shared workers, you couldn't sync up a start time
... for dedicated, we were able to be more direct
igrigorik: a worker could start an other worker
michael: as long as they share the start time of the document, it's ok
igrigorik: it seems odd to distinguish
plh: do we have implementation of hrt for worker?
igrigorik: not sure
yoav: would be valuable to have both
igrigorik shared worker doesn't have a document
scribe: could also be a push
... completely detached
igrigorik: the app can communicate the start time of the document (as well as performance.now)
... as a follow up, would be interested to see if it's implemented
todd: I don't think IE does support on worker
http://w3c.github.io/hr-time/#sec-time-origin
[...]
yoav: looks like there is code in chrome for that
... not sure if it's shipped
plh: follow on the issue thread
https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0066.html
igrigorik: new attribute on both NT and RT
... the point at which we route the request to the service worker
... if no SW, it returns 0
plh: can you establish the SW time with one attribute?
http://w3c.github.io/navigation-timing/#h-processing-model
igrigorik: that would be the difference between workerStart and startTime
plh: workerStart is between startTime and linkNegotiationStart?
igrigorik: correct
... I'll create a pull for it
plh: and I'll update the graphic
todd: if you do a fetch and the SW does complex network operations, how do we report that?
igrigorik: not sure how to communicate that
... you would see alll of those in the SW
... but would be opaque to the page
... you would have to move your logic in the service woker
plh: if multiple request, what would you see?
igrigorik: almost like it came from the cache
interface LazyPerformanceEntryList {
bool HasEntryType(string);
PerformanceEntryList getEntries();
PerformanceEntryList getEntriesByType(DOMString entryType);
}
getEntriesByName(DOMString entryName)?
Todd: this looks good to us
... one question: current proposal interplays with performance timeline
... should we hook it earlier? ie performance timeline isn't required
igrigorik: if you want all events, you register your PO right away
yoav: can we unite the concepts and add navigation request as well?
igrigorik: would be odd to have past timing information
... for nav timing, maight be ok, but would be odd for frame timing
todd: can you opt-in? on document load, nav timing and RT are all loaded for you
... with PO, i may want to use that for them
... it feels strange to come up with a new construct and not be able to do the things we did before
igrigorik: there is overlap
[...]
scribe: NT and RT are in a special place
plh: for NT< you'll get it in the observer after the load event
igrigorik: ok. next step is to do a pull request