Disabling hostname verification on websockets in Tomcat 8+

[V User]

Hello,

I'm working through upgrading an application from Tomcat 7 to Tomcat 9, and
am running into an issue with hostname verification. The application
initiates websocket connections using SSL to several other servers by IP
address, and those servers' certificates either do not have any subject
alternative names (SAN) set, or have SANs that do not include their IP
address. As a result, we're getting SSL connection errors like "No subject
alternative names present" and "No subject alternative names matching IP
address  found".

(I understand that the correct solution here would be to update all our
servers to have certificates with proper SANs and make our
application initiate websockets using hostnames that match the SANs, but
that will take some time to do and I'm trying to figure out if there's a
workaround that will let us complete the upgrade to Tomcat 9 without having
to do a complete rollout of those changes first.)

The how-to on websockets (
https://tomcat.apache.org/tomcat-9.0-doc/web-socket-howto.html) says that
you can bypass hostname verification with a custom TrustManager: "For
secure server endpoints, host name verification is enabled by default. To
bypass this verification (not recommended), it is necessary to provide a
custom SSLContext via the org.apache.tomcat.websocket.SSL_CONTEXT user
property. The custom SSLContext must be configured with a custom
TrustManager that extends javax.net.ssl.X509ExtendedTrustManager. The
desired verification (or lack of verification) can then be controlled by
appropriate implementations of the individual abstract methods."

I did a trial using an "accept everything" TrustManager, but was still
seeing the same errors. Poking around with a debugger, it seems like the
JSSE "AbstractTrustManagerWrapper" runs the configured TrustManager checks,
and then runs its own "additional" checks, which is where things are
failing (
https://github.com/JetBrains/jdk8u_jdk/blob/94318f9185757cc33d2b8d527d36be26ac6b7582/src/share/classes/sun/security/ssl/SSLContextImpl.java#L1097).
In particular, it seems like if the identity algorithm returned by
"getEndpointIdentificationAlgorithm" is non-null, it runs some identity
checks using X509TrustManagerImpl, regardless of what custom TrustManager
was set by the end user. I also found this Stackoverflow question:
https://stackoverflow.com/questions/51244136/tomcat-websocket-disable-hostname-verification,
which led me to this hardcoded parameter in WsWebSocketContainer:
https://github.com/apache/tomcat/blob/db0c10ea25cc8984f72d700ea48f32aadc2fe2f4/java/org/apache/tomcat/websocket/WsWebSocketContainer.java#L928
.

So, it seems to me that while you can disable *certificate* verification by
setting a custom TrustManager, you cannot disable *hostname* verification.
Is that correct, or am I missing some other option or parameter?

Thanks,
Zoe

OT: java.net.socket exception

[jonmcalexander]

So, to start I'm not a developer. With that said, have a development team that 
is getting the exception below in their Tomcat 9.0.74 implementation using Java 
11 (also with Java 8). After much troubleshooting with their configuration, it 
turned out to be this in the JAVA_OPTIONS:

-Djsse.enableSNIExtention=false

Once I removed that, the exception and 500 error went away and things work 
properly.

Is there an issue using this Java Option?

Thanks.


Stack-Trace below:

javax.net.ssl|DEBUG|0F|https-jsse-nio-10431-exec-1|2023-05-25 12:16:03.746 
CDT|Utilities.java:73|the previous server name in SNI (type=host_name (0), 
value=..xxx) was replaced with (type=host_name (0), value=..xxx)
javax.net.ssl|DEBUG|0F|https-jsse-nio-10431-exec-1|2023-05-25 12:16:03.751 
CDT|SSLSocketOutputRecord.java:263|WRITE: TLSv1.3 handshake, length = 378
javax.net.ssl|WARNING|0F|https-jsse-nio-10431-exec-1|2023-05-25 12:16:03.753 
CDT|SSLSocketImpl.java:1519|handling exception (
"throwable" : {
  java.net.SocketException: Connection reset
at 
java.base/java.net.SocketInputStream.read(SocketInputStream.java:186)
at 
java.base/java.net.SocketInputStream.read(SocketInputStream.java:140)
at 
java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:484)
at 
java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:478)
at 
java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:160)
at 
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:111)
at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1383)
at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1296)
at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:416)
at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:388)
at 
java.base/sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:576)
at 
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:201)
at 
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:168)
at 
org.springframework.http.client.SimpleBufferingClientHttpRequest.executeInternal(SimpleBufferingClientHttpRequest.java:76)
at 
org.springframework.http.client.AbstractBufferingClientHttpRequest.executeInternal(AbstractBufferingClientHttpRequest.java:48)
at 
org.springframework.http.client.AbstractClientHttpRequest.execute(AbstractClientHttpRequest.java:66)
at 
org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:782)
at 
org.springframework.web.client.RestTemplate.execute(RestTemplate.java:717)
at 
org.springframework.web.client.RestTemplate.getForEntity(RestTemplate.java:367)
at 
com..spring.controller.HomeController.home(HomeController.java:27)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:205)
at 
org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:150)
at 
org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:117)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:895)
at 
org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:808)
at 
org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at 
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1071)
at 
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:964)
at 
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at 
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
at javax.servlet.http.HttpServlet.service(HttpServlet.java

Re: Multiple concurrent sessions

[Christopher Schultz]

Stephane,

On 5/25/23 12:44, Stephane Passignat wrote:

Hello,

I would like to open multiple concurrent session in a web-application 
for one user. As far as I understand, the sessionid is stored in the 
cookie and the cookie is associated to the server (http://localhost:8080/).


So if I open a new browser window with the URL, I reach the same page 
than the one in the first window, no authentication, ... I can trick 
that using a private browse, but it's not convenient.


The above is accurate.

Are there any way to have this multiple session per user ? I read a bit 
session-config and tracking mode. Is it the right direction ?


You have three choices:

1. Use a different browser (e.g. Firefox plus Google Chrome)
2. Use a private browsing window within the same browser
3. Disable cookie-based session tracking on the server and use URL-rewriting

Note that #3 affects all users and not just you.

-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: WebdavServlet protected resources cannot be opened in Word

[Christopher Schultz]

All,

On 5/24/23 07:17, Mark Thomas wrote:

On 24/05/2023 08:03, Кирилл Бубович wrote:
We use webdav servlet 
 to enable editing docx documents. We also use the |ms-word:ofe|u|https://www.example.com/document.docx | scheme in our application to be able to edit documents. The Office URI Scheme documentation  contains a "Security Considerations" section for all schemes. These sections describe the need to guard against opening documents from untrusted remote systems.


We have tried enabling basic AUTH to secure documents, which is 
probably not the best approach since credentials will constantly be 
moving over the network, but this is just for testing to understand 
how it works. When we try to open a protected document in Word, we see 
a form asking for credentials.


image.png

However, the entered credentials do not affect the application 
request, and the request still does not contain an authorization header.


How to properly implement document protection and how to make it so 
that Word client can log in in the appropriate way? Thanks in advance 
for your help!


The Microsoft WebDAV implementations have a history of non-specification 
compliant behaviour.


It's awful. It's almost like Microsoft is single-handedly trying to kill 
WebDAV.


>> We have tried enabling basic AUTH to secure documents...

Microsoft does not like to use HTTP Basic authentication -- even over 
HTTPS -- for WebDAV. It depends upon exactly which client is being used 
to access the file but at $work we have to purchase licenses from a 
third-party for a network driver which properly implements WebDAV.


Microsoft /will/ allow HTTP Digest authentication which is a standard 
which should no longer exist.


Your problem may be that your MS client just refuses to work properly. 
You may have to either give-up or use third-party software like we have 
had to do.


-chris

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Multiple concurrent sessions

[Brian Wolfe]

Am I understanding your use case right?
You need a particular user to have multiple sessions in the same browser?
or are you saying you need multiple users to be able to log into your
application in the same browser?

On Thu, May 25, 2023 at 12:45 PM Stephane Passignat 
wrote:

> Hello,
>
> I would like to open multiple concurrent session in a web-application
> for one user. As far as I understand, the sessionid is stored in the
> cookie and the cookie is associated to the server (http://localhost:8080/
> ).
>
> So if I open a new browser window with the URL, I reach the same page
> than the one in the first window, no authentication, ... I can trick
> that using a private browse, but it's not convenient.
>
> Are there any way to have this multiple session per user ? I read a bit
> session-config and tracking mode. Is it the right direction ?
>
>
> thanks for your help
>
> stephane
>


-- 
Thanks,
Brian Wolfe
https://www.linkedin.com/in/brian-wolfe-3136425a/

Multiple concurrent sessions

[Stephane Passignat]

Hello,

I would like to open multiple concurrent session in a web-application 
for one user. As far as I understand, the sessionid is stored in the 
cookie and the cookie is associated to the server (http://localhost:8080/).


So if I open a new browser window with the URL, I reach the same page 
than the one in the first window, no authentication, ... I can trick 
that using a private browse, but it's not convenient.


Are there any way to have this multiple session per user ? I read a bit 
session-config and tracking mode. Is it the right direction ?



thanks for your help

stephane

Re: HTTP 400 from tcp half-open health checks

[Van Hoa Phan]

Correct me if I am wrong, but isn't such logging necessary to detect syn
flood attacks(expected behavior)?

On Thu, May 25, 2023 at 7:29 PM Mark Thomas  wrote:

> On 25/05/2023 09:14, Paul Baines wrote:
> > Hello! We upgraded a Windows Tomcat instance from 8.5.41 to 8.5.84. This
> Tomcat instance is behind a load balancer. Since the upgrade the Tomcat
> access log (AccessLogValve) has an "empty" entry with response 400 for
> every TCP half-open health check from the load balancer. Because the health
> check is every 5 seconds from redundant load-balancers we are getting quite
> alot of junk in the access log. The TCP half-open check is:LB --> SYN
>  --> Tomcat 443LB <-- SYN/ACK <-- Tomcat 443LB --> FIN --> Tomcat 443LB
> <-- FIN/ACK <-- Tomcat 443Access log excerpt:[03/May/2023:00:13:58 +0200]
> 10.20.10.2 - "-" - "-" "-" 400 0 - -[03/May/2023:00:13:59 +0200] 10.20.10.3
> - "-" - "-" "-" 400 0 - -[03/May/2023:00:14:03 +0200] 10.20.10.2 - "-" -
> "-" "-" 400 0 - -[03/May/2023:00:14:04 +0200] 10.20.10.3 - "-" - "-" "-"
> 400 0 - -[03/May/2023:00:14:08 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 -
> -[03/May/2023:00:14:09 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 -
> -[03/May/2023:00:14:13 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - -
> > We can reproduce this effect from Windows Powershell
> with:Test-NetConnection -ComputerName tomcat.server.name -RemotePort 443
> > My question is, is this expected behaviour?
>
> Yes.
>
> > Is TCP half-open health check supported by Tomcat?
>
> Yes. But you are going to see 400 responses in the logs for each empty
> request.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

Re: HTTP 400 from tcp half-open health checks

[Mark Thomas]

On 25/05/2023 09:14, Paul Baines wrote:

Hello! We upgraded a Windows Tomcat instance from 8.5.41 to 8.5.84. This Tomcat instance is behind a load balancer. Since the upgrade the Tomcat access log (AccessLogValve) has an "empty" entry with response 400 for every TCP half-open health check from the load balancer. Because the health check is every 5 
seconds from redundant load-balancers we are getting quite alot of junk in the access log. The TCP half-open check is:LB --> SYN     --> Tomcat 443LB <-- SYN/ACK <-- Tomcat 443LB --> FIN     --> Tomcat 443LB <-- FIN/ACK <-- Tomcat 443Access log excerpt:[03/May/2023:00:13:58 +0200] 10.20.10.2 - 
"-" - "-" "-" 400 0 - -[03/May/2023:00:13:59 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 - -[03/May/2023:00:14:03 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - -[03/May/2023:00:14:04 +0200] 10.20.10.3 - "-" - "-" 
"-" 400 0 - -[03/May/2023:00:14:08 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - -[03/May/2023:00:14:09 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 - -[03/May/2023:00:14:13 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - -
We can reproduce this effect from Windows Powershell with:Test-NetConnection 
-ComputerName tomcat.server.name -RemotePort 443
My question is, is this expected behaviour?


Yes.


Is TCP half-open health check supported by Tomcat?


Yes. But you are going to see 400 responses in the logs for each empty 
request.


Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

HTTP 400 from tcp half-open health checks

[Paul Baines]

Hello! We upgraded a Windows Tomcat instance from 8.5.41 to 8.5.84. This Tomcat 
instance is behind a load balancer. Since the upgrade the Tomcat access log 
(AccessLogValve) has an "empty" entry with response 400 for every TCP half-open 
health check from the load balancer. Because the health check is every 5 
seconds from redundant load-balancers we are getting quite alot of junk in the 
access log. The TCP half-open check is:LB --> SYN     --> Tomcat 443LB <-- 
SYN/ACK <-- Tomcat 443LB --> FIN     --> Tomcat 443LB <-- FIN/ACK <-- Tomcat 
443Access log excerpt:[03/May/2023:00:13:58 +0200] 10.20.10.2 - "-" - "-" "-" 
400 0 - -[03/May/2023:00:13:59 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 - 
-[03/May/2023:00:14:03 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - 
-[03/May/2023:00:14:04 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 - 
-[03/May/2023:00:14:08 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - 
-[03/May/2023:00:14:09 +0200] 10.20.10.3 - "-" - "-" "-" 400 0 - 
-[03/May/2023:00:14:13 +0200] 10.20.10.2 - "-" - "-" "-" 400 0 - -
We can reproduce this effect from Windows Powershell with:Test-NetConnection 
-ComputerName tomcat.server.name -RemotePort 443
My question is, is this expected behaviour? Is TCP half-open health check 
supported by Tomcat?
Thanks for any help.Paul

Re: WebdavServlet protected resources cannot be opened in Word

[Кирилл Бубович]

I will also try to apply WebdavFixFilter

чт, 25 мая 2023 г. в 10:27, Кирилл Бубович :

> Hi Mark and Thomas,
>
> Thank you for your help! Our configuration is the following:
>
> - Tomcat 9.0.74
> - We run the application in a Docker container based on
> adoptopenjdk/openjdk11:jdk-11.0.18_10-alpine
> 
> - AdoptOpenJDK 11.0.18+10
>
> - Version 2108 (Build 14332.20503)
> - Windows 11 Pro 22H2
>
> - 80
> - used URL: ms-word:ofe|u|https://domain/exposed/attachment/test.docx
>
> I tried adding a header WWW-Authenticate: Kerberos and Word suddenly
> started sending a filled Authorization header. For Basic and Digest
> authorization, it sent an empty Authorization header, regardless of the
> entered credentials. I will try to set up Kurberois authorization. Perhaps
> Word has stopped supporting Basic and Digest since some time.
>
> Thanks again for your answers!
>
>
> ср, 24 мая 2023 г. в 14:59, Thomas Hoffmann (Speed4Trade GmbH)
> :
>
>> Hello,
>>
>> > -Ursprüngliche Nachricht-
>> > Von: Mark Thomas 
>> > Gesendet: Mittwoch, 24. Mai 2023 13:18
>> > An: users@tomcat.apache.org
>> > Betreff: Re: WebdavServlet protected resources cannot be opened in Word
>> >
>> > On 24/05/2023 08:03, Кирилл Бубович wrote:
>> > > We use webdav servlet
>> > >
>> > > > ervlets/WebdavServlet.java> to enable editing docx documents. We also
>> use
>> > the |ms-word:ofe|u|https://www.example.com/document.docx
>> > | scheme in our application to
>> > be able to edit documents. The Office URI Scheme documentation
>> > > > schemes> contains a "Security Considerations" section for all schemes.
>> These
>> > sections describe the need to guard against opening documents from
>> > untrusted remote systems.
>> > >
>> > > We have tried enabling basic AUTH to secure documents, which is
>> > > probably not the best approach since credentials will constantly be
>> > > moving over the network, but this is just for testing to understand
>> how it
>> > works.
>> > > When we try to open a protected document in Word, we see a form asking
>> > > for credentials.
>> > >
>> > > image.png
>> > >
>> > > However, the entered credentials do not affect the application
>> > > request, and the request still does not contain an authorization
>> header.
>> > >
>> > > How to properly implement document protection and how to make it so
>> > > that Word client can log in in the appropriate way? Thanks in advance
>> > > for your help!
>> >
>> > The Microsoft WebDAV implementations have a history of non-specification
>> > compliant behaviour. So much so that Tomcat has this:
>> >
>> >
>> https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/filt
>> > ers/WebdavFixFilter.java
>> >
>> > It has been a long time (many years) since I last looked at that code
>> so my
>> > hope was that things had improved.
>> >
>> > It is possible that you are seeing a Tomcat bug but, given past
>> experience, we
>> > are only going to be able investigate this and produce useful answers
>> for you
>> > if we can test with *exactly* the same versions that you are using.
>> >
>> > With that in mind, please provide exact version numbers for the
>> following:
>> >
>> > - Tomcat version used
>> > - OS Tomcat is running on
>> > - Java version Tomcat is running on
>> >
>> > - Word version client is using
>> > - OS client is running on
>> >
>> > - port client is using to connect to WebDAV
>> > - is TLS being used?
>> > - context path WebDAV is deployed to
>> >
>> > Ideally, it would be helpful if you could provide a full URI for a
>> resource you
>> > are trying to access via WebDAV.
>> >
>> > Thanks,
>> >
>> > Mark
>> >
>>
>> We are using MS Office with Tomcat WebDav-Servlet without problems.
>>
>> Configuration:
>> - Port 80 / 443 (80 redirects to 443)
>> - Kerberos Auth / SSO
>> - Tomcat 10.1 running on Ubuntu 22.04 LTS (Tomcat 9 and 10 also worked in
>> the past)
>> - Browser: Chrome + Firefox latest version
>> - used URL: ms-word:ofe|u|https://domain/webdav/attachment/test.docx
>>
>> The readonly parameter doesn’t work as described by MS, therefore we
>> prevented writing via web.xml
>> 
>>   readonly
>>   true
>> 
>>
>> Good luck!
>> Thomas
>>
>

Re: WebdavServlet protected resources cannot be opened in Word

[Кирилл Бубович]

Hi Mark and Thomas,

Thank you for your help! Our configuration is the following:

- Tomcat 9.0.74
- We run the application in a Docker container based on
adoptopenjdk/openjdk11:jdk-11.0.18_10-alpine

- AdoptOpenJDK 11.0.18+10

- Version 2108 (Build 14332.20503)
- Windows 11 Pro 22H2

- 80
- used URL: ms-word:ofe|u|https://domain/exposed/attachment/test.docx

I tried adding a header WWW-Authenticate: Kerberos and Word suddenly
started sending a filled Authorization header. For Basic and Digest
authorization, it sent an empty Authorization header, regardless of the
entered credentials. I will try to set up Kurberois authorization. Perhaps
Word has stopped supporting Basic and Digest since some time.

Thanks again for your answers!


ср, 24 мая 2023 г. в 14:59, Thomas Hoffmann (Speed4Trade GmbH)
:

> Hello,
>
> > -Ursprüngliche Nachricht-
> > Von: Mark Thomas 
> > Gesendet: Mittwoch, 24. Mai 2023 13:18
> > An: users@tomcat.apache.org
> > Betreff: Re: WebdavServlet protected resources cannot be opened in Word
> >
> > On 24/05/2023 08:03, Кирилл Бубович wrote:
> > > We use webdav servlet
> > >
> >  > ervlets/WebdavServlet.java> to enable editing docx documents. We also use
> > the |ms-word:ofe|u|https://www.example.com/document.docx
> > | scheme in our application to
> > be able to edit documents. The Office URI Scheme documentation
> >  > schemes> contains a "Security Considerations" section for all schemes.
> These
> > sections describe the need to guard against opening documents from
> > untrusted remote systems.
> > >
> > > We have tried enabling basic AUTH to secure documents, which is
> > > probably not the best approach since credentials will constantly be
> > > moving over the network, but this is just for testing to understand
> how it
> > works.
> > > When we try to open a protected document in Word, we see a form asking
> > > for credentials.
> > >
> > > image.png
> > >
> > > However, the entered credentials do not affect the application
> > > request, and the request still does not contain an authorization
> header.
> > >
> > > How to properly implement document protection and how to make it so
> > > that Word client can log in in the appropriate way? Thanks in advance
> > > for your help!
> >
> > The Microsoft WebDAV implementations have a history of non-specification
> > compliant behaviour. So much so that Tomcat has this:
> >
> > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/filt
> > ers/WebdavFixFilter.java
> >
> > It has been a long time (many years) since I last looked at that code so
> my
> > hope was that things had improved.
> >
> > It is possible that you are seeing a Tomcat bug but, given past
> experience, we
> > are only going to be able investigate this and produce useful answers
> for you
> > if we can test with *exactly* the same versions that you are using.
> >
> > With that in mind, please provide exact version numbers for the
> following:
> >
> > - Tomcat version used
> > - OS Tomcat is running on
> > - Java version Tomcat is running on
> >
> > - Word version client is using
> > - OS client is running on
> >
> > - port client is using to connect to WebDAV
> > - is TLS being used?
> > - context path WebDAV is deployed to
> >
> > Ideally, it would be helpful if you could provide a full URI for a
> resource you
> > are trying to access via WebDAV.
> >
> > Thanks,
> >
> > Mark
> >
>
> We are using MS Office with Tomcat WebDav-Servlet without problems.
>
> Configuration:
> - Port 80 / 443 (80 redirects to 443)
> - Kerberos Auth / SSO
> - Tomcat 10.1 running on Ubuntu 22.04 LTS (Tomcat 9 and 10 also worked in
> the past)
> - Browser: Chrome + Firefox latest version
> - used URL: ms-word:ofe|u|https://domain/webdav/attachment/test.docx
>
> The readonly parameter doesn’t work as described by MS, therefore we
> prevented writing via web.xml
> 
>   readonly
>   true
> 
>
> Good luck!
> Thomas
>