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

[Dmitry Gutov]

On 01.12.2016 19:17, Eli Zaretskii wrote:

> Nothing wrong with that.  If some issue isn't a bug, but gets in the
> way of a broad class of applications,

I don't think it's useful to extract applications that use JSON+HTTP 
with ASCII-only payloads into a separate class.

Most of the time (or at least very often) it depends on the user, what 
kind of payload gets sent (with multibyte characters or not).

> it is okay to silently DTRT for
> that class only, in some central place that serves the class.

Those central places are coding.c and url/url-*.el. Not sure what can be 
done there, though.

> I don't think we will win any hearts by nagging application
> programmers when we could silently DTRT ourselves.

We can win the hearts of some users, long term, by making the API such 
that it's harder to do the wrong thing.

You yourself suggested multibyte-string-p originally, and I suggested 
the current more permissive approach more or less because that the new 
release was very close:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23750#83

> Can you show me a patch to that effect, or point me to where it was
> posted in the past?  I'm afraid I no longer remember those details.

Something like this:

diff --git a/lisp/url/url-http.el b/lisp/url/url-http.el
index e0e080e..affd5c2 100644
--- a/lisp/url/url-http.el
+++ b/lisp/url/url-http.el
@@ -358,9 +358,8 @@ url-http-create-request
              ;; Any data
              url-http-data))
     ;; Bug#23750
-    (unless (= (string-bytes request)
-               (length request))
-      (error "Multibyte text in HTTP request: %s" request))
+    (when (mutibyte-string-p request)
+      (error "Multibyte text in HTTP request: %s, please translate any 
multibyte components to unibyte using `encode-coding-string'" request))
     (url-http-debug "Request is: \n%s" request)
     request))