Loading ...
Sorry, an error occurred while loading the content.

Re: [json] Compressed JSON

Expand Messages
  • Tom Metro
    ... Yes, though it looks like Content-Type is unchanged, but a Content-Encoding header needs to be added. Here are a couple of articles on this that I found
    Message 1 of 7 , Mar 7, 2006
    • 0 Attachment
      henrik hjelte wrote:
      >> ...I am sending the files to the browser in gzip form and they should
      >> automagiacally decompress, before going to the parser.
      >
      > I think you have to set the proper value of the http response
      > content-type, to a value like text/gzip or text/zip.

      Yes, though it looks like Content-Type is unchanged, but a
      Content-Encoding header needs to be added.

      Here are a couple of articles on this that I found when searching for
      "HTTP Compression":

      http://www.webreference.com/internet/software/servers/http/compression/

      Most newer browsers since 1998/1999 have been equipped to support the
      HTTP 1.1 standard known as "content-encoding." ... Essentially the
      browser indicates to the server that it can accept "content encoding"
      and if the server is capable it will then compress the data and
      transmit it.

      http://www.websiteoptimization.com/speed/tweak/compress/

      HTTP compression uses public domain compression algorithms, like gzip
      and compress, to compress XHTML, JavaScript, CSS, and other text files
      at the server. This standards-based method of delivering compressed
      content is built into HTTP 1.1, and most modern browsers that support
      HTTP 1.1 support ZLIB inflation of deflated documents. In other words,
      they can decompress compressed files automatically...


      So the likely problem is that your server isn't sending the correct
      Content-Encoding header. Also note that your server is supposed to be
      looking at the request headers and *only* sending compressed content if
      the client says it can handle it.

      Whether all this magic is supported by the XMLHttpRequest() API is
      another matter, but being a documented feature of HTTP 1.1 it seems
      likely that the capability is implemented in the lower layer protocol API.

      -Tom

      --
      Tom Metro
      Venture Logic, Newton, MA, USA
      "Enterprise solutions through open source."
      Professional Profile: http://tmetro.venturelogic.com/
    • msf157
      I finally got it working. The headers were being added correctly but the encoding was not. I switched methods of compression and it works perfectly. The
      Message 2 of 7 , Mar 9, 2006
      • 0 Attachment
        I finally got it working. The headers were being added correctly
        but the encoding was not. I switched methods of compression and it
        works perfectly. The browser/platform should auto-decompress on the
        other end if the headers are set correctly. There should be no need
        to use a gzip library, as some suggested.

        To others that do not use compression I highly recomend it. The
        advantage of JSON is the small size, and simplicity to Parse. If
        you are not compressing your streams then you are not taking full
        advantage of the format.

        My JSON went from 5k to 1k, i know these are already small files,
        but my web interface is making dozens of calls a minute and updating
        the screen, that small decrease in size will add tons to the
        unsability of the page for those on slower connections.

        The final solution was to wrap my PHP page with start_gzip and
        end_gzip commands, the browser auto decompresses and parses the
        result wih JS.

        Thanks again to all that left feedback.

        -Marc

        --- In json@yahoogroups.com, Tom Metro <tmetro+json@...> wrote:
        >
        > henrik hjelte wrote:
        > >> ...I am sending the files to the browser in gzip form and they
        should
        > >> automagiacally decompress, before going to the parser.
        > >
        > > I think you have to set the proper value of the http response
        > > content-type, to a value like text/gzip or text/zip.
        >
        > Yes, though it looks like Content-Type is unchanged, but a
        > Content-Encoding header needs to be added.
        >
        > Here are a couple of articles on this that I found when searching
        for
        > "HTTP Compression":
        >
        >
        http://www.webreference.com/internet/software/servers/http/compressio
        n/
        >
        > Most newer browsers since 1998/1999 have been equipped to
        support the
        > HTTP 1.1 standard known as "content-encoding." ... Essentially
        the
        > browser indicates to the server that it can accept "content
        encoding"
        > and if the server is capable it will then compress the data and
        > transmit it.
        >
        > http://www.websiteoptimization.com/speed/tweak/compress/
        >
        > HTTP compression uses public domain compression algorithms,
        like gzip
        > and compress, to compress XHTML, JavaScript, CSS, and other
        text files
        > at the server. This standards-based method of delivering
        compressed
        > content is built into HTTP 1.1, and most modern browsers that
        support
        > HTTP 1.1 support ZLIB inflation of deflated documents. In other
        words,
        > they can decompress compressed files automatically...
        >
        >
        > So the likely problem is that your server isn't sending the
        correct
        > Content-Encoding header. Also note that your server is supposed to
        be
        > looking at the request headers and *only* sending compressed
        content if
        > the client says it can handle it.
        >
        > Whether all this magic is supported by the XMLHttpRequest() API is
        > another matter, but being a documented feature of HTTP 1.1 it
        seems
        > likely that the capability is implemented in the lower layer
        protocol API.
        >
        > -Tom
        >
        > --
        > Tom Metro
        > Venture Logic, Newton, MA, USA
        > "Enterprise solutions through open source."
        > Professional Profile: http://tmetro.venturelogic.com/
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.