I would like to send info from a non-browser based device using http using POST. Because of limitations on the device I need to compress the data I send.

I find if I use POST data format of multipart/form-data to send the data I can have the data automatically go into PHP variables on the server side.

I ahve this working well for uncompressed data but I am not sure what the protocol is for compressed data.

After which header do I start to compress the data:

Content-Type: multipart/form-data
Content-Disposition: data
Content-Transfer-Encoding: binary

If anyone knows where this might be documented please let me know.

Thanks

Greg

    You can program the PHP script that receives the POST to unzip the input.

      I understand the PHP part, what I am not sure about is how to write the http part. Which parts of the header are uncompressed and which parts are compressed?

      Thanks

      Greg

        Everything is uncompressed expect from the content of the POST variable. But the content must be URL encoded. So compress the content and use urlencode() to encode it. Then from the server side, the URL decoding is automatic, so all you have to do is decompress the POST variable.

          I would also recommend to use a format like this:

          POST /url/to/your/script HTTP/1.0\r\n
          Content-Type: application/x-www-form-urlencoded\r\n
          Content-Length: [length of content]\r\n
          \r\n
          variable=[url encoded value]
          

          Edit:
          Replace [length of content] with the length of all the content including the name of the variable

            Your way is not wrong, in fact it may be faster than mine. But I have never used it so I can only give you my opinion for the method I know.

              Hi Greg.. well there is a future project in which the answer to your question will be useful to me, so I looked it more thoroughly.. I made a TCP/IP sniffer to see the request of FireFox when it uploads data. I could read the protocols as well, but this way is much faster for me.. here is how FireFox sends requests with uploaded data:

              POST / HTTP/1.1
              Host: localhost:1234567
              User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
              Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
              Accept-Language: en-us,en;q=0.5
              Accept-Encoding: gzip,deflate
              Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
              Keep-Alive: 300
              Connection: keep-alive
              Referer: http://localhost/test/test.php
              Cookie: dbx-postmeta=grabit=0-,1-,2-,3-,4-,5-,6-&advancedstuff=0+,1-,2+,3-,4+,5-; PHPSESSID=1cc1855d69c1c1ec5a8f11166e4d0968
              Content-Type: multipart/form-data; boundary=---------------------------5272992921246
              Content-Length: [..content length..]
              
              -----------------------------5272992921246
              Content-Disposition: form-data; name="MAX_FILE_SIZE"
              
              2097152
              -----------------------------5272992921246
              Content-Disposition: form-data; name="txtMessage"
              
              message
              -----------------------------5272992921246
              Content-Disposition: form-data; name="file"; filename="image.jpg"
              Content-Type: image/jpeg
              
              [..data..]
              
              

              This came from a <form> with two text inputs "txtMessage" and "MAX_FILE_SIZE". The file input is called "file" and the name of the uploaded file "image.jpg".

              I suppose you have to follow the format of this request. I doubt if the headers you mentioned in your initial post are enough.

              Note that the header writes a boundary, and there are two additional dashes in the content:
              ---------------------------5272992921246
              -----------------------------5272992921246

              Replace [..content length..] with the length of all the output after the initial header.

              Replace [..data..] with your gziped data

              Replace Host: localhost:1234567 with the URL of the PHP page that will handle the upload. The port (:1234567) is not necessary.

              Referer cookies and other headers are probably not critical for your implementation. I copy-pasted them all so that you can have a better understanding.

              The PHP script that will handle this upload should behave exactly like any regular upload. So read the examples in http://us3.php.net/features.file-upload for more. Also, there are several other pages in php.net to explain how to unzip or gunzip. You will find lots of examples.

                Ooops.. one mistake..

                The URL goes to the first line replacing '/'..
                localhost:1234567 should change to the domain of the page

                POST /url/here HTTP/1.1
                Host: www.example.com

                  I am using the Live HTTP Headers in FireFox to see the headers as well.

                  The -- two dashes thru me for a while, it is not well documented.

                  I have not seen the gzip well documented and most of the time it talks about compression from the server to client and not the other way (probably because the http gzip protocol was developed by NetScape?).

                  If you see any documentation on how the gzip should be implemented let me know.

                  I would like to do it in a way that gets my form-data automatically to place itself in php variables if possible the same way uncompressed form-data does.

                  Thank you for your help.

                  Greg

                    Not all browsers support gzip. So when you request a page the browser silently informs the server if it supports gzip. If it does then the server has the option to respond with compressed output.

                    Your case is different. You simulate a browser behaviour and you know that both the client and the server has to do with compressed data. Your request may well be compressed and your PHP script in the server side just has to uncompress the data.

                    The additional work from the server side is something like..

                    if (is_uploaded_file($_FILES['file']['tmp_name'])) {
                      // uncompress $_FILES['file']['tmp_name'] here ...
                    } else {
                      // log Possible file upload attack
                    }
                    

                    Also, the uncompressing process requires the script to know the uncompressed file size. You can transport this through a text message like the "txtMessage" I had in the example above.

                    See the un/compress examples in http://gr2.php.net/manual/en/ref.zlib.php

                      Thank you for all your help. It has helped me out alot to understand how I am going to plan this.

                      Greg

                        gmrobert wrote:

                        The -- two dashes thru me for a while, it is not well documented.

                        It's actually documented quite well if you look in the right place (Section 5.1.1: Composite Media Type Values/Multipart Media Type/Common Syntax. Page 18).

                        The Content-Type field for multipart entities requires one parameter, "boundary". The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF.

                        I have not seen the gzip well documented (probably because the http gzip protocol was developed by NetScape?).

                        See http://www.gzip.org/zlib/rfc-gzip.html or http://www.ietf.org/rfc/rfc1952.txt
                        And http://www.ietf.org/rfc/rfc2616.txt (section 3.5).

                          Write a Reply...