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

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Could I get input on the following patch before I apply it?  The first
> part (using string-bytes instead of length) seems like a no-brainer.
> The second part, I'm less sure about.

> --- url-http.el	4 Jun 2005 18:37:16 -0000	1.14
> +++ url-http.el	10 Jun 2005 18:36:06 -0000
> @@ -259,7 +259,7 @@
>  	   (if url-request-data
>  	       (concat
>  		"Content-length: " (number-to-string
> -				    (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.
Actually the two will be the same in 2 cases:
1 - url-request-data is a unibyte string (in which case `length' also
    returns the same value and the match makes no difference).
2 - the process's coding system is `emacs-mule'.

The first case is probably what we want.  The second is unlikely to ever
be right.

> + (defvar url-request-coding-system 'binary "The coding system to use for the request.")
[...]
> +	(set-process-coding-system connection
> +				   (detect-coding-string url-request-data t)
> +				   url-request-coding-system)

This says "the data we send is binary (i.e. unibyte, thus case 1 above) and
the data we receive uses the coding system that we infer from
url-request-data".  Does that sound right to you?

Assuming the data we send is url-request-data, it doesn't sound right to me.

Using binary when sending sounds right (assuming url-request-data is
unibyte, which is desirable).  But when receiving we then probably would
want to use binary as well.
Also I'm not sure what is the purpose of url-request-coding-system.
Would it make sense to set it to something else?

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.


        Stefan