Re: compressed body in HTTP POST request; using Jabber for IM
Aha.. misread "content-encoding" as "content-type".. I suspect that gzip is *not* an encoding, which is something like Base64, Uuencode or Quoted-printable and is used to ensure that binary data will pass unmolested through mail transport agents (MTA's) which are only required to handle ASCII, and allowed to insert line breaks. My advice would now be to investigate the MIME form data encoding, within which gzip would be a valid Content-type, and could probably be ungzipped by a filter. d *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressed body in HTTP POST request; using Jabber for IM
> We were thinking of using either Tomcat or JBoss for the server, Unless you're not going to use http with JBOSS You'll find that JBOSS is Bundled with Tomcat for the web app container.. >From my extensive and brain deadening reading of the MIME rfcs I don't think you be violating the spec you quote if you used *any* legal MIME content-type (including X- ones), you might find that it just isn't supported at both ends.. Hmm. You could easily, and usefully, extend Tomcat to add this if it is not present. d. *** The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient (or responsible for delivery of the message to the intended recipient) please notify us immediately on 0141 306 2050 and delete the message from your computer. You may not copy or forward it or use or disclose its contents to any other person. As Internet communications are capable of data corruption Student Loans Company Limited does not accept any responsibility for changes made to this message after it was sent. For this reason it may be inappropriate to rely on advice or opinions contained in an e-mail without obtaining written confirmation of it. Neither Student Loans Company Limited or the sender accepts any liability or responsibility for viruses as it is your responsibility to scan attachments (if any). Opinions and views expressed in this e-mail are those of the sender and may not reflect the opinions and views of The Student Loans Company Limited. This footnote also confirms that this email message has been swept for the presence of computer viruses. ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressed body in HTTP POST request; using Jabber for IM
On Wed, 2004-02-11 at 10:10, Adrian German wrote: > One last question would be about the relative performance of compressed > HTTP vs. technologies currently used for Instant Messaging such as > Jabber. I know that this is too general but I'd be very interested to > know if (in your experience, or just in your opinion) Jabber-like > technologies are clearly superior, or clearly inferior, or simply not > comparable with compressed HTTP for the kind of applications mentioned > above (ministations in the field connecting to server periodically and > transmitting data). I thank you in advance and am looking forward to any > replies. There's been a fair bit of work done at my job site on Jabber wrapped in Ruby - http://rubyforge.org/projects/jabber4r/ - to connect to servers and send status messages for a distributed agent society - http://cougaar.org/. The status messages we're sending around are usually pretty small - they top out at about 20K - so this may not be comparable to what your doing. FWIW, I think Jabber might add a bit more complexity then you need - Jabber is a messaging protocol and so it's tuned for little messages flying all over the place. What you're doing sounds like a good match for the things you suggested - compressed HTTP, zipped SMTP as Serge suggested, or maybe even FTP. Yours, tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: compressed body in HTTP POST request; using Jabber for IM
Adrian German wrote: The application we are building involves a few hundred (perhaps thousand) devices/stations which are distributed in a fairly large territory (say, the size of Indiana) which act as mini-browsers and send information to a server (to which they connect, authenticate and all that) periodically. Now the line on which they communicate is dial-up (gsm/gprs), so being able to compress the POST requests would keep the costs down. Also, these stations/browsers might be behind a firewall, so the TCP connection can only be initiated from a station to the server and not the other way around. We were thinking of using either Tomcat or JBoss for the server, and it was not clear to us if the server would be able to handle properly a compressed request. If it does it already then maybe we missed it, and we apologize and we'd be very grateful for any pointers. Have you considered sending information using SMTP and zip attachments? You could then use James (http://james.apache.org) to handle the zips and do whatever is appropriate. You would still need a minibrowser for retrieving information, but this might be an efficient way to send data from lots of clients. SMTP is easy for the client, and while James isn't as friendly to develop with as I'd like, it could work. Just a random idea. -- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
compressed body in HTTP POST request; using Jabber for IM
Folks, I have a question and I hope that someone could help me clarify it. RFC 2616 says that the presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. The question I have is this: Does the RFC allow a POST request to contain "Transfer-Encoding: gzip" header *followed* by a compressed body? Does Tomcat support the processing of such a request? Does Apache? If they don't and we try to extend the sources to accommodate this, would that be a possible breach of specs? The application we are building involves a few hundred (perhaps thousand) devices/stations which are distributed in a fairly large territory (say, the size of Indiana) which act as mini-browsers and send information to a server (to which they connect, authenticate and all that) periodically. Now the line on which they communicate is dial-up (gsm/gprs), so being able to compress the POST requests would keep the costs down. Also, these stations/browsers might be behind a firewall, so the TCP connection can only be initiated from a station to the server and not the other way around. We were thinking of using either Tomcat or JBoss for the server, and it was not clear to us if the server would be able to handle properly a compressed request. If it does it already then maybe we missed it, and we apologize and we'd be very grateful for any pointers. One last question would be about the relative performance of compressed HTTP vs. technologies currently used for Instant Messaging such as Jabber. I know that this is too general but I'd be very interested to know if (in your experience, or just in your opinion) Jabber-like technologies are clearly superior, or clearly inferior, or simply not comparable with compressed HTTP for the kind of applications mentioned above (ministations in the field connecting to server periodically and transmitting data). I thank you in advance and am looking forward to any replies. ... Adrian P.S. Granted this may not be the forum to ask such a question. In that case let me just take back all of the above back and simply wish you a Happy Wednesday! ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
