GNU bug report logs - #40241
26.1; browse-url, needs to % hex hex encode the hash char

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40241 in the body.
You can then email your comments to 40241 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: larice <larice <at> vidisys.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; browse-url, needs to % hex hex encode the hash char
Date: Thu, 26 Mar 2020 11:16:05 +0100

Dear Maintainers,

  I couldn't open a link in org mode, which happened
    to contain a hash char #.
  A search for the culprit revealed usage of this
    (setq url (browse-url-encode-url url))
  in several functions,
  for example in browse-url-firefox in file browse-url.el

  This function looks like:

  (defun browse-url-encode-url (url)
  "Escape annoying characters in URL.
The annoying characters are those that can mislead a web browser
regarding its parameter treatment."
  ;; FIXME: Is there an actual example of a web browser getting
  ;; confused?  (This used to encode commas, but at least Firefox
  ;; handles commas correctly and doesn't accept encoded commas.)
  (browse-url-url-encode-chars url "[\")$] "))

  I suggest to add the char '#' to the second argument of the
    browse-url-url-encode-chars invocation to fix the nuisance.

Best Regards,
  Robert Larice
  

Message #8 received at 40241 <at> debbugs.gnu.org (full text, mbox):

From: larice <larice <at> vidisys.de>
To: help-debbugs <at> gnu.org (GNU bug Tracking System)
Cc: 40241 <at> debbugs.gnu.org
Subject: Re: bug#40241: Acknowledgement (26.1;
 browse-url, needs to % hex hex encode the hash char)
Date: Thu, 26 Mar 2020 17:49:50 +0100

> Dear Maintainers,
> 
>   I couldn't open a link in org mode, which happened
>     to contain a hash char #.
>   A search for the culprit revealed usage of this
>     (setq url (browse-url-encode-url url))
>   in several functions,
>   for example in browse-url-firefox in file browse-url.el
> 
>   This function looks like:
> 
>   (defun browse-url-encode-url (url)
>   "Escape annoying characters in URL.
> The annoying characters are those that can mislead a web browser
> regarding its parameter treatment."
>   ;; FIXME: Is there an actual example of a web browser getting
>   ;; confused?  (This used to encode commas, but at least Firefox
>   ;; handles commas correctly and doesn't accept encoded commas.)
>   (browse-url-url-encode-chars url "[\")$] "))
> 
>   I suggest to add the char '#' to the second argument of the
>     browse-url-url-encode-chars invocation to fix the nuisance.

I've to correct myself, and to withdraw my suggestion.
The '#' char has special significance in rfc3986 and can't be
  that easily % hex'ified.

My issue is more precisely the following.
I've URLs for the search engine of "murata" which look like:
  http://www.murata.com/en-global/products/productdetail?partno=GRM21BR61E226ME44#
At first sight this looks well, but note the trailing '#'.
When I enter this interactively into firefox, then it works.
If I use %23 instead, it works too.
If I pass the URL on the firefox command line, then only the %23 variant works.
If I use such an URL in a org mode file, either with # or with %23,
  then this URL gets un-hexlified to the '#' variant somewhere in
  org-mode, is then passed to `browse-url-firefox', which passes it
  unmodified to the command line of a firefox invocation.
But that's the variant which doesn't work for firefox.

Now this is too exotic, and I simply withdraw my `bug' report.
I don't think it is worth the time,
neither is it easy to exactly state whats wrong here at all.
Perhaps it is the part of org mode which
 un-hexlifies the URL. I suppose it shouldn't.
Then I could have put a %23'fied URL into the org file.

As this case is exotic and very specific,
I simply add an exception rule to `browse-url-browser-function'
 like this

(defun my-browse-url-generic (url &optional new-window)
  (browse-url-generic (browse-url-url-encode-chars url "#") new-window))

(setq browse-url-browser-function
      '(("murata.*#$" . my-browse-url-generic)
        ("." . browse-url-generic)))

and be done with it.
Sorry for having wasted your time.

Best Regards
 Robert Larice

 
 
  

Message #11 received at 40241 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: larice <larice <at> vidisys.de>
Cc: 40241 <at> debbugs.gnu.org
Subject: Re: bug#40241: Acknowledgement (26.1; browse-url, needs to % hex
 hex encode the hash char)
Date: Thu, 26 Mar 2020 19:52:00 -0400

[Message part 1 (text/plain, inline)]

larice <larice <at> vidisys.de> writes:

> My issue is more precisely the following.
> I've URLs for the search engine of "murata" which look like:
>   http://www.murata.com/en-global/products/productdetail?partno=GRM21BR61E226ME44#
> At first sight this looks well, but note the trailing '#'.
> When I enter this interactively into firefox, then it works.

In what way do you find this works?  When I enter this into firefox
(either interactively or from the command line) I get a kind of 404 page
"The page you requested could not be found" (see attached).

[murata-404.png (image/png, attachment)]

Message #14 received at 40241 <at> debbugs.gnu.org (full text, mbox):

From: larice <larice <at> vidisys.de>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 40241 <at> debbugs.gnu.org
Subject: Re: bug#40241: Acknowledgement (26.1;
 browse-url, needs to % hex hex encode the hash char)
Date: Fri, 27 Mar 2020 08:47:28 +0100

Noam Postavsky <npostavs <at> gmail.com> writes:

> larice <larice <at> vidisys.de> writes:
>
>> My issue is more precisely the following.
>> I've URLs for the search engine of "murata" which look like:
>>   http://www.murata.com/en-global/products/productdetail?partno=GRM21BR61E226ME44#
>> At first sight this looks well, but note the trailing '#'.
>> When I enter this interactively into firefox, then it works.
>
> In what way do you find this works?  When I enter this into firefox
> (either interactively or from the command line) I get a kind of 404 page
> "The page you requested could not be found" (see attached).

You are right, I'm meanwhile completely confused.
I retried, and I have to use the %23 notation to open the page
  successfully, that is
    http://www.murata.com/en-global/products/productdetail?partno=GRM21BR61E226ME44%23

I've mislead myself completely,
  and fooled myself when searching for the problem.

At the end, I've not used the blessed org command C-l C-o `org-insert-link'
  to copy the %23 annotated link into the org file.
I've incorrectly used C-y `yank' to simply paste it into the org file.
C-l C-o would have caused a second round of %-hex encoding to transform
  GRM21BR61A226ME51%23 --> GRM21BR61A226ME51%2523
The second round will decode to %23 when `browse-url' is invoked
  and firefox will open the page successfully.

Sorry, please put this bug report deeply into the Trash Can.

Best Regards
  Robert Larice

Message #17 received at 40241 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: larice <larice <at> vidisys.de>
Cc: 40241 <at> debbugs.gnu.org
Subject: Re: bug#40241: Acknowledgement (26.1; browse-url, needs to % hex
 hex encode the hash char)
Date: Fri, 27 Mar 2020 08:30:29 -0400

tags 40241 notabug
close 40241
quit

larice <larice <at> vidisys.de> writes:

> At the end, I've not used the blessed org command C-l C-o `org-insert-link'
>   to copy the %23 annotated link into the org file.
> I've incorrectly used C-y `yank' to simply paste it into the org file.
> C-l C-o would have caused a second round of %-hex encoding to transform
>   GRM21BR61A226ME51%23 --> GRM21BR61A226ME51%2523
> The second round will decode to %23 when `browse-url' is invoked
>   and firefox will open the page successfully.
>
> Sorry, please put this bug report deeply into the Trash Can.

Didn't quite follow all that, but sounds like there is no bug here, so
I'll close.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.