Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
I've fixed this in trunk. Given the behaviour changes (you can bet someone
depends on a 403 rather than a 405 response) I'm not going to back-port it.
The way I ended up tackling this (WebDAV fir
Github user ChristopherSchultz commented on the issue:
https://github.com/apache/tomcat/pull/96
WRT WebDav, [RFC2618](https://tools.ietf.org/html/rfc2518) says that WebDav
is an extension to HTTP/1.1 so I think we are always okay using 405 from
`WebDavServlet`. We should, however, tak
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
No argument with Konstantin's points here. I started to look at
implementing this and I realised that the WebDAV is inconsistent with how the
allow header is generated. A method may not be included
Github user kkolinko commented on the issue:
https://github.com/apache/tomcat/pull/96
1) POST fallsback to GET, I think since RFC1945 (HTTP/1.0). Both HEAD and
POST were improvements over single GET method supported by original HTTP
protocol (0.9).
2) DefaultServlet can be used as
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
Lack of response == lazy consensus. I plan to look at applying these
patches (or possibly a variation of them) before tagging 9.0.x.
---
---
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
@markt-asf I haven't received any responses to the
[thread](http://tomcat.10.x6.nabble.com/Change-HTTP-status-code-for-DefaultServlet-with-readOnly-set-to-true-td5070373.html)
I started on dev@. I kn
Github user ChristopherSchultz commented on the issue:
https://github.com/apache/tomcat/pull/96
I think 405 is more appropriate when the method is in fact not allowed
(readOnly). As for POST, there is nothing "writey" about POST, whereas PUT and
DELETE have definite "write" semantics.
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
Getting back to whether readOnly should affect POST, my own view is that it
should not. readOnly refers to whether the default Servlet can change static
content. For static content request parameter
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
I wanted to clear something up. It is not a case of me being willing to
change something or not. I don't get to decide these things on my own. It is a
community decision. Normally, we discuss things
Github user michael-o commented on the issue:
https://github.com/apache/tomcat/pull/96
Alright, did not notice that. Mark has to tell wether he is willing to
change this in 9.0. The other version likely won't change.
---
--
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
@michael-o I had the exact same question in my original post. The only
thing I saw was that the POST delegates to the GET, so they both have the same
effect.
---
--
Github user michael-o commented on the issue:
https://github.com/apache/tomcat/pull/96
@kdombeck Correct.
---
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomc
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
@michael-o I don't understand your question. Are you asking why ```PUT```
and ```DELETE``` are not allowed when the **readOnly** flag is true but
```POST``` is allowed?
---
---
Github user michael-o commented on the issue:
https://github.com/apache/tomcat/pull/96
Why is `POST` not part of the writable commands?
---
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional c
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
I haven't had any responses in
[thread](http://tomcat.10.x6.nabble.com/Change-HTTP-status-code-for-DefaultServlet-with-readOnly-set-to-true-td5070373.html)
I started for this issue.
I have u
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
I started this
[thread](http://tomcat.10.x6.nabble.com/Change-HTTP-status-code-for-DefaultServlet-with-readOnly-set-to-true-td5070373.html)
on the mailing list to look for consensus.
If cons
Github user michael-o commented on the issue:
https://github.com/apache/tomcat/pull/96
@markt-asf I'd second the 405 instead of 403.
---
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional comm
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
The inconsistency stems from the different status codes used. If TRACE is
disabled at the connector, level then a 405 is returned for TRACE requests. If
readOnly is set in the DefaultServlet, a 403
Github user kdombeck commented on the issue:
https://github.com/apache/tomcat/pull/96
Thanks for the quick responses.
I modeled this change after the changes for TRACE in the next if statement
below. Also looking at
[issue](https://bz.apache.org/bugzilla/show_bug.cgi?id=60697
Github user markt-asf commented on the issue:
https://github.com/apache/tomcat/pull/96
The current OPTIONS behaviour is intentional.
OPTIONS lists the valid methods, not the permitted methods, for a resource.
The GET/POST issue is before my time with the project. There migh
Github user ChristopherSchultz commented on the issue:
https://github.com/apache/tomcat/pull/96
Patch looks good to me.
Regarding your questions:
> Why is a POST allowed when readOnly is true?
Probably because the DefaultServlet just delegates POST -> GET, but
21 matches
Mail list logo
