emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: encoding and content-length for url-http.el


From: Stefan Monnier
Subject: Re: encoding and content-length for url-http.el
Date: Fri, 10 Jun 2005 17:22:37 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

>> > -                              (length url-request-data))
>> > +                              (string-bytes url-request-data))
>> 
>> 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 will
>> 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"

Problem is that the byte length depends on the encoding that will be used.
I.e. it's not just a property of the string itself.

I think the code should keep `length' while making sure that
url-request-data is always a sequence of bytes rather than a sequence of
strings (i.e. its content has already been explicitly encoded in whichever
coding-system was deemed appropriate).

>> If the change from length to string-bytes solves your problem, it means that
>> 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 believe you, that your code worked on your test cases, but if it does it
seems to be by accident.

> 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.

Could you describe much more precisely what you're doing (especially how
you use the URL package: which functions of it you call, etc...).
Are you using WebDAV (i.e. url-dav.el)?

I've found url-dav.el to be pretty buggy and looking through it, I see some
places where a few more encode-coding-string wouldn't be amiss.


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]