Bug 146496 - WEBSERVICE function doesn't forward urls in form: http://[user]:[port]@[server]:[port]/[endpoint]
Summary: WEBSERVICE function doesn't forward urls in form: http://[user]:[port]@[serve...
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.2.3.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-31 10:37 UTC by Zhivko
Modified: 2021-12-31 20:05 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zhivko 2021-12-31 10:37:37 UTC
WEBSERVICE function doesn't forward urls in form: http://[user]:[port]@[server]:[port]/[endpoint] to destination server.

If I ommit [user]:[port]@ libreoffice WEBSERVICE function opens url.

Allowing calling urls in  form:
http://[user]:[port]@[server]:[port]/[endpoint]

would allow us to add authorization to urls, since there is no way to specify http headers in WEBSERVICE call.
Comment 1 Jan-Marek Glogowski 2021-12-31 20:05:28 UTC
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.