https://bugs.documentfoundation.org/show_bug.cgi?id=146496
Jan-Marek Glogowski <glo...@fbihome.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
See Also| |https://bugs.documentfounda
| |tion.org/show_bug.cgi?id=14
| |3216
--- Comment #1 from Jan-Marek Glogowski <glo...@fbihome.de> ---
AFAIK this is currently explicitly not supported. The low-level INetURLObject
schemes disable it in tools/source/fsys/urlobj.cxx. This results in other bugs,
like bug 143216.
Quoting from the comment in https://gerrit.libreoffice.org/c/core/+/124987
"The original <https://datatracker.ietf.org/doc/html/rfc1738> "Uniform Resource
Locators (URL)" (on which our INetURLObject was traditionally based) did not
allow for any user:password@ part in http URLs (see section 3.3 "HTTP"). And
while harmonization and generalization of URL schemes would allow that now, the
reference (as per
<https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1>)
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-semantics/19/> "HTTP
Semantics" section 4.2.4 "Deprecation of userinfo in http(s) URIs" states that
such a part is (a) deprecated, (b) must not be generated by senders, and (c)
should be treated as an error by receivers. In light of that, I would argue
against extending INetURLObject to support such a part in http and/or https
URLs. (For example, it could mean that we would accidentally start to generate
such URLs in certain request scenarios, which we must not do.)"
So I guess this is currently a WONTFIX.
--
You are receiving this mail because:
You are the assignee for the bug.
