Eli Zaretskii schrieb am Mi., 30. Nov. 2016 um 19:45 Uhr: > > From: Philipp Stephani > > Date: Wed, 30 Nov 2016 18:23:14 +0000 > > Cc: dgutov@yandex.ru, kentaro.nakazawa@nifty.com, emacs-devel@gnu.org > > > > > 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.