- From: Arvind Jain <arvind@google.com>
- Date: Thu, 14 Nov 2013 13:57:27 -0800
- To: Chase Douglas <chase@newrelic.com>
- Cc: "Reitbauer, Alois" <Alois.Reitbauer@compuware.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAOYaDdM1n=EQO4F5Sw4YYfxLp+_-XEsQ6K2PyGxx5=T7x9hCCQ@mail.gmail.com>
OK. Dumb question: how do we compress the payload in sendBeacon() (assuming we know the server can handle it)? On Thu, Nov 14, 2013 at 9:57 AM, Chase Douglas <chase@newrelic.com> wrote: > I don't think it makes sense to require gzip. The UA can denote whether > gzip is used by setting the Content-Encoding header. As for whether the UA > knows if the server accepts gzip encoding or not, I think that's simply > covered by the fact that the javascript code must already know how to > encapsulate data that is transmitted to the server. This doesn't seem any > different from knowing whether to send XML or JSON or plaintext. > > > On Wed, Nov 13, 2013 at 7:51 PM, Arvind Jain <arvind@google.com> wrote: > >> Could we make accepting gzipped body a requirement for a server >> supporting Beacon? >> >> Arvind >> >> >> On Wed, Nov 13, 2013 at 5:23 PM, Reitbauer, Alois < >> Alois.Reitbauer@compuware.com> wrote: >> >>> Would make sense. However, the user agent does not know whether the >>> beacon server accepts gzip encoding. >>> >>> >>> Alois Reitbauer | Technical Product Manager | Compuware APM >>> >>> >>> ------------------------------ >>> *From:* Chase Douglas <chase@newrelic.com> >>> *Sent:* Wednesday, November 13, 2013 5:42 PM >>> *To:* Reitbauer, Alois >>> *Cc:* public-web-perf@w3.org >>> *Subject:* Re: [Beacon] Review of current spec >>> >>> On Tue, Nov 12, 2013 at 7:09 PM, Reitbauer, Alois < >>> Alois.Reitbauer@compuware.com> wrote: >>> >>>> Size Limits: >>>> >>>> We set the size limit to 10k, waiting for feedback whether analytics >>>> tools need more. >>>> >>> >>> Is it possible to add an option to have the UA compress the data with >>> gzip before sending? The UA obviously can receive gzip compressed data, so >>> why not also optimize message sizes on transmission? >>> 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 Thursday, 14 November 2013 21:57:56 UTC