https://bugs.documentfoundation.org/show_bug.cgi?id=173215
Bug ID: 173215
Summary: LibreOffice’s Universal Content Broker (UCB) currently
performs mandatory preflight requests (HEAD, OPTIONS,
PROPFIND) before issuing a GET request. Many modern
HTTP/REST/WFS/XML/JSON endpoints do not accept these
preflight methods and respond with 400 Ba
Product: LibreOffice
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Documentation
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Feature Request: Add a Pure HTTP GET Command to UCB (No HEAD/PROPFIND
Preflight) + User‑Defined Headers
Summary
LibreOffice’s Universal Content Broker (UCB) currently performs mandatory
preflight requests (HEAD, OPTIONS, PROPFIND) before issuing a GET request. Many
modern HTTP/REST/WFS/XML/JSON endpoints do not accept these preflight methods
and respond with 400 Bad Request or 501 Not Implemented, causing UCB‑based
operations (WEBSERVICE, SimpleFileAccess, DocumentBuilder.parseURI, UCB.open)
to fail before a GET request is ever sent.
This makes LibreOffice unable to access a wide range of modern web APIs,
including FMI’s WFS service, which only accepts pure HTTP GET with specific
headers.
I propose adding a PureHTTP GET command to UCB, with optional user‑defined
headers, and without any preflight requests.
This is a small, isolated enhancement that would dramatically improve
LibreOffice’s ability to interact with modern web services.
Problem Description
Current UCB behavior
When UCB is asked to open a URL (via WEBSERVICE, SimpleFileAccess, UCB.open,
DocumentBuilder.parseURI), it performs:
1. HEAD
2. OPTIONS
3. PROPFIND (if URL resembles a resource)
4. Only if these succeed → GET
These preflight requests are hardcoded in the C++ provider logic and cannot be
disabled.
Why this fails
Many modern HTTP endpoints:
- do not support HEAD
- do not support OPTIONS
- do not support PROPFIND
- do not support WebDAV metadata
- reject Accept: */*
- reject LibreOffice’s default User-Agent
Example: FMI WFS responds:
HEAD /wfs?... → 400 Bad Request
Because HEAD fails, UCB never sends GET, and the operation fails even though
the endpoint would respond correctly to a pure GET request.
This breaks:
- WEBSERVICE()
- SimpleFileAccess.openFileRead(URL)
- UCB.open()
- DocumentBuilder.parseURI()
All of these fail before GET is attempted.
Expected Behavior
LibreOffice should provide a way to perform:
A pure HTTP GET request
- No HEAD
- No OPTIONS
- No PROPFIND
- No WebDAV preflight
- No Accept: */*
- No LibreOffice/… User-Agent
With user‑defined headers, e.g.:
User-Agent: Mozilla/5.0
Accept: application/xml
Authorization: Bearer <token>
Cache-Control: no-cache
This would allow LibreOffice to interact with modern REST/WFS/XML/JSON APIs.
1. Proposed Enhancement
cmd.Name = "get"
cmd.Argument = GetCommandArgument
2. Add a new struct: GetCommandArgument
struct GetCommandArgument {
Sequence<StringPair> RequestHeaders;
sal_Int32 Priority;
Reference<XActiveDataSink> Sink;
};
Behavior:
- Perform only a pure HTTP GET
- Attach user‑defined headers
- Deliver response via XActiveDataSink
- No HEAD
- No OPTIONS
- No PROPFIND
- No WebDAV logic
- No Accept: */*
- No LibreOffice/… User-Agent
3. Add a new provider: PureHttpContentProvider
A minimal provider that:
- bypasses WebDAV logic entirely
- performs only GET
- uses headers from GetCommandArgument
- returns raw response stream
This is a small, isolated addition and does not affect existing providers.
Technical Rationale
Why this is needed
Modern web APIs (REST, WFS, WMS, JSON, XML) expect:
- pure GET
- specific headers
- no preflight requests
LibreOffice’s current UCB design is optimized for WebDAV servers, not modern
HTTP services.
Why this is easy to implement
- UCB providers are modular
- GET logic already exists
- Preflight logic can be bypassed
- Header injection is already supported in XWebDAVEnv
- No breaking changes
- No architectural refactoring
- No impact on existing WebDAV functionality
Why this benefits LibreOffice
- WEBSERVICE() becomes actually useful
- SimpleFileAccess can read URLs reliably
- DocumentBuilder.parseURI() works with modern APIs
- UCB becomes compatible with REST/WFS/XML/JSON
- Removes need for external curl/MSXML2 workarounds
- Enables automation and scripting workflows
- Makes LibreOffice competitive with Excel’s PowerQuery and Python’s requests
library
Reproducible Test Case
URL:
https://opendata.fmi.fi/wfs?service=WFS&request=GetFeature&storedquery_id=fmi::observations::weather::multipointcoverage&place=Helsinki
LibreOffice behavior:
HEAD → 400 Bad Request
GET is never sent
Operation fails
curl / MSXML2 behavior:
GET → 200 OK
XML returned successfully
This demonstrates that the failure is caused by UCB’s preflight logic, not by
the endpoint.
Conclusion
LibreOffice needs a PureHTTP GET command with user‑defined headers and no
preflight requests.
This is a small, safe, backward‑compatible enhancement that would dramatically
improve LibreOffice’s ability to interact with modern web services.
I respectfully request that the LibreOffice development team consider
implementing:
- GETCommandArgument
- PureHttpContentProvider
- cmd.Name = "get"
This would resolve long‑standing issues with WEBSERVICE, SimpleFileAccess,
UCB.open, and DocumentBuilder.parseURI, and unlock modern HTTP/REST/WFS
functionality for all LibreOffice users.
--
You are receiving this mail because:
You are the assignee for the bug.
