Eli Zaretskii <
address@hidden> schrieb am Mi., 30. Nov. 2016 um 19:45 Uhr:
> 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.
Yes, but url-http-create-request only cares about unibyte strings because the request it creates is passed to process-send-string, which special-cases unibyte strings.
> 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.
We need it because we have to send the byte length in a header. We can't just use (length s) because it would silently give a wrong result.
> (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.
We can't give a multibyte string to process-send-string, because we have to pass the length in bytes in a header first. Therefore we have to encode any string before passing it to process-send-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?
Yes, but HTTP request/response bodies should just be byte arrays and no conversion whatsoever should happen. After all, the body could be a binary data format.