Apache OpenOffice (AOO) Bugzilla – Issue 21599
Http header HTTP_USER_AGENT
Last modified: 2017-05-20 09:23:57 UTC
While trying to open an Excel Document throught an URL with OpenOffice 1.1.0. The HTTP server replies that field HTTP_USER_AGENT must be included in the request. After looking at the network traces, OpenOffice effectively donnot include that field in the http header. Is there a way to ask OpenOffice to includes that field ?
CJ->MBA: Could you please have a look at this. Thanks.
Kai, I think that this is something you should have a look on.
accepted
Sending the user-agaent header field is not generally required. If some servers insist on it's presence, this is not correct. However, we could be nice and send the field. Changing issue type from DEFECT ti ENHANCEMENT
Andreas, this is a feature request. It is no problem to send a user agent field along with every request. The real question is which user agent string to send. Possibly this even should be done configurable via a config item (and a OOo user interface on top of it).
ABI->KSO: As discussed ...
.
KSO->TKR: Please take care of this issue.
*** Issue 105462 has been marked as a duplicate of this issue. ***
This bug also prevents OpenOffice from being able to access many webdav servers who filter on the user agent string to determine allowable webdav clients or so they can workaround known issues with certain webdav clients. I tested this against a webdav server using OOo Writer v3.1.1 and the user agent string delivered by OOo was blank and the server refused to allow access due to the blank user agent string.
>This bug also prevents OpenOffice from being able to access many webdav servers >who filter on the user agent string to determine allowable webdav clients or so >they can workaround known issues with certain webdav clients. greno: Do you have an example for such a webdav server? >I tested this against a webdav server using OOo Writer v3.1.1 and the user agent >string delivered by OOo was blank and the server refused to allow access due to >the blank user agent string. The user agent string sent by OOo is not blank, the whole useragent request header is simply not present. Not much of a difference here, but for the records.
> greno: Do you have an example for such a webdav server? Yes, KnowledgeTree. And you can see why doc mgmt and CMS systems using WebDAV have had to query the HTTP_USER_AGENT string because the WebDAV standard can be interpreted differently in a few instances and as a result client implementations have varied. In order to guarantee correct results it has been necessary for servers to query the HTTP_USER_AGENT string in order to determine which type of client is sending the request. This way they can workaround certain client-specific WebDAV implementations. And when a client does not send a HTTP_USER_AGENT string then that client is refused access. This is why OOo has been prevented from working with the WebDAV servers in some of the doc mgmt and CMS systems.
greno: Do you have a suggestion for the user agent string OOo should send to achieve best interop results? OOo uses neon as webdav client library.
> greno: Do you have a suggestion for the user agent string OOo should send to > achieve best interop results? OOo uses neon as webdav client library. I think you can probably make up any OOo HTTP_USER_AGENT string you like but it should include some form of "neon" in it to indicate the neon client library. In some webdav servers you see things like this: $user_agent = strtolower($user_agent); if (strstr($user_agent, 'neon') !== false) { ... do "neon" specific stuff ... $allow = True; }
... taking over.
Fixed in CWS kso50. OOo now sends a User-Agent request header with every request. The header value format is <ooo-product-name/ooo-product-version neon/<neon-version>. Examples: "OpenOffice.org/3.4 neon/0.29.5", "Oracle Open Office/3.4 neon/0.29.5".
Excellent. Now doc mgmt and CMS systems can retrieve an HTTP_USER_AGENT string from OOo and act accordingly. Any chance on getting this backported to previous OOo versions?