- From: Reitbauer, Alois <Alois.Reitbauer@compuware.com>
- Date: Wed, 13 Nov 2013 03:09:27 +0000
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <5bf4bc27e81d46ee96c016bcd50527db@BLUPR05MB353.namprd05.prod.outlook.com>
Preparing for tomorrows meeting I took the time to have a closer look at the current spec. I think there are a couple of items that need further discussion. Some of them already came up on the mailing list. This is an attempt to put them all together in a list. If you think something is missing let me know: HTTP Methods supported: Currently we set the default to GET allow POST and PUT. I feel we should default to POST. First of all it is technically more correct and second we avoid unwanted proxy caching of GET requests. I also think we could remove PUT entirely. I am not aware of any solution that uses it today. It also adds some unnecessary complexity to the processing model which we can avoid. Size Limits: We set the size limit to 10k, waiting for feedback whether analytics tools need more. An open question is how we handle 413 (Request Entity too large) Responses from a server. Recommended Server Behaviour: Although not necessarily part of the spec it makes sense to define the desired server-side behaviour. A 200 reply for post requests and a 204 reply for GET requests makes most sense here. Data Sending: We had several proposals here and the spec currently says "The User Agent SHOULD make a best effort attempt to eventually transmit the data." First we need to be clear on what eventually means. Most likely the page is unloaded already. This could leave open beacons being around for a long time. We should specify a timeout when a beacon becomes invalid. I propose 30 seconds. This interval could also be taken as time within which the beacon must be transmitted. We should make a commitment here as beacon timeouts will also influence server-side behaviour. After a certain time beacons will most likely no longer be processed any more on the server. Retry Handling: I would not complicate the spec by having any retry handling in it. The browser tries to submit the request. If it fails it fails. There is not a lot anyways you can do in this case on the client side. The only corner case I see here is what to do when the browser is temporarily offline. Alois Reitbauer | Technical Product Manager | Compuware APM The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Compuware Austria GmbH (registration number FN 91482h) is a company registered in Vienna whose registered office is at 1120 Wien, Austria, Am Euro Platz 2 / Geb?ude G.
Received on Wednesday, 13 November 2013 03:10:05 UTC