Re: bug#23750: 25.0.95; bug in url-retrieve or json.el

[Eli Zaretskii]

> From: Philipp Stephani <address@hidden>
> Date: Wed, 30 Nov 2016 18:23:14 +0000
> Cc: address@hidden, address@hidden, address@hidden
> 
>  > Yes, this is not a json.el problem at all. It does the correct thing,
>  > and shouldn't be changed.
> 
>  ??? Why should any code care whether a pure-ASCII string is marked as
>  unibyte or as multibyte? Both are "correct".
> 
> I guess the problem is that process-send-string cares. If it didn't, we 
> wouldn't have the problem.

I don't think I follow.  The error we are talking about is signaled
from url-http-create-request, not from process-send-string.

> For URL, we'd need functions like
> (byte-array-length s) = (length (string-to-unibyte s))

Why do you need this?  string-to-unibyte is well-defined only for
unibyte or ASCII strings (if we forget the raw bytes for a moment), so
length will do.

> (process-send-bytes s) = (process-send-string (string-to-unibyte s))

Why is this needed?  process-send-string already encodes its argument,
which produces a unibyte string.

> (conceptually; process-send-string also does EOL conversion, which should 
> never be done for HTTP
> bodies.) 

I don't understand why.  There are protocols that require CR-LF, no?