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

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

[larice]

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
  

bug#40241: Acknowledgement (26.1; browse-url, needs to % hex hex encode the hash char)

[larice]

> 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

 
 
  

bug#40241: Acknowledgement (26.1; browse-url, needs to % hex hex encode the hash char)

[Noam Postavsky]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

larice <larice@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).


[-- Attachment #2: screenshot of 404 page --]
[-- Type: image/png, Size: 59651 bytes --]

bug#40241: Acknowledgement (26.1; browse-url, needs to % hex hex encode the hash char)

[larice]

Noam Postavsky <npostavs@gmail.com> writes:

> larice <larice@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

bug#40241: Acknowledgement (26.1; browse-url, needs to % hex hex encode the hash char)

[Noam Postavsky]

tags 40241 notabug
close 40241
quit

larice <larice@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.