From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Mark A. Hershberger" Newsgroups: gmane.emacs.devel Subject: Re: encoding and content-length for url-http.el Date: Fri, 10 Jun 2005 13:14:41 -0400 Message-ID: <1118423681.8854.58.camel@localhost.localdomain> References: <1118418076.8854.41.camel@localhost.localdomain> <87u0k69fhn.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0410802341==" X-Trace: sea.gmane.org 1118435144 23714 80.91.229.2 (10 Jun 2005 20:25:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 10 Jun 2005 20:25:44 +0000 (UTC) Cc: Emacs Development Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 10 22:25:39 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Dgq41-0007Vf-8c for ged-emacs-devel@m.gmane.org; Fri, 10 Jun 2005 22:25:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DgqBD-0007m3-1w for ged-emacs-devel@m.gmane.org; Fri, 10 Jun 2005 16:32:39 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Dgq9L-000795-1h for emacs-devel@gnu.org; Fri, 10 Jun 2005 16:30:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Dgq9H-00077Z-58 for emacs-devel@gnu.org; Fri, 10 Jun 2005 16:30:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Dgq9D-00072Q-4B for emacs-devel@gnu.org; Fri, 10 Jun 2005 16:30:37 -0400 Original-Received: from [64.124.179.97] (helo=superman.everybody.org) by monty-python.gnu.org with esmtp (TLS-1.0:RSA_AES_128_CBC_SHA:16) (Exim 4.34) id 1Dgpuu-0004jZ-QR for emacs-devel@gnu.org; Fri, 10 Jun 2005 16:15:48 -0400 Original-Received: from 66.216.169.50.static.dejazzd.com ([66.216.169.50] helo=[192.168.1.20]) by superman.everybody.org with esmtpsa (TLS-1.0:RSA_ARCFOUR_MD5:16) (Exim 4.50) id 1DgpuJ-0004Qn-Sq; Fri, 10 Jun 2005 15:15:20 -0500 Original-To: Stefan Monnier In-Reply-To: <87u0k69fhn.fsf-monnier+emacs@gnu.org> X-Mailer: Evolution 2.3.2 X-SA-Exim-Connect-IP: 66.216.169.50 X-SA-Exim-Mail-From: mah@everybody.org X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on superman.everybody.org) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:38535 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:38535 --===============0410802341== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hzQVtsZNMC09okwsaVLG" --=-hzQVtsZNMC09okwsaVLG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-06-10 at 15:47 -0400, Stefan Monnier wrote: > > - (length url-request-data)) > > + (string-bytes url-request-data)) >=20 > I must say I haven't looked at the code, but it's anything but > a no-brainer. I'd rather say that it's obviously wrong. `string-bytes' > will give you the number of bytes used by Emacs for the internal > representation of the string, not the number of bytes that the string wil= l > use on the write. So I was wrong. But length is even more obviously wrong than string-bytes. The description for length says "If the string contains multibyte characters, this is not necessarily the number of bytes in the string; it is the number of characters. To get the number of bytes, use `string-bytes'." Which is why I thought this was a no-brainer. We want number of bytes, not number of characters. RFC2616 says "The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient" > If the change from length to string-bytes solves your problem, it means t= hat > url-request-data is not unibyte (i.e. not a seq of bytes, but a seq of > chars), in which case using `binary' when sending can't be right. I've been using the patch successfully for some time on unicode strings (seq of chars). It works for me and works were what is currently in CVS fails. I'm quite willing to concede that its wrong, but I've had trouble finding documentation for this stuff. And, like I said, this works better for me than what is in CVS. --=20 http://mah.everybody.org/weblog/ GPG Fingerprint: 7E15 362D A32C DFAB E4D2 B37A 735E F10A 2DFC BFF5 More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier --=-hzQVtsZNMC09okwsaVLG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCqcqAc17xCi38v/URAgA7AJ40/bx5LQZtf3Qypet7V4o26u2wRgCdFyLF frJhMBdxVOEWUuz3v9dCFUU= =eRL7 -----END PGP SIGNATURE----- --=-hzQVtsZNMC09okwsaVLG-- --===============0410802341== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============0410802341==--