You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by koteswara Rao Gundapaneni <ko...@gmail.com> on 2023/12/26 12:00:38 UTC
I have just created a pull request for 8.5.x branch but that is invisible
HTTP Patch option should be deprecated as the option is doing partial
changes to an existing resource.
combination of the options and trace methods works very well rather than
the Http PATCH
It works very well when the jsperror page is redirected as it shown trace
option
private String getCachedAllowHeaderValue() {
if (cachedAllowHeaderValue == null) {
synchronized (cachedAllowHeaderValueLock) {
if (cachedAllowHeaderValue == null) {
Method[] methods =
getAllDeclaredMethods(this.getClass());
// RFC 7230 does not define an order for this header
// This code aims to retain, broadly, the order of
method
// tokens returned in earlier versions of this code. If
that
// constraint is dropped then the code can be simplified
// further.
boolean allowGet = false;
boolean allowHead = false;
boolean allowPatch = false;
boolean allowPost = false;
boolean allowPut = false;
boolean allowDelete = false;
for (Method method : methods) {
switch (method.getName()) {
case "doGet": {
allowGet = true;
allowHead = true;
break;
}
case "doPatch": {
allowPatch = true;
break;
}
case "doPost": {
allowPost = true;
break;
}
case "doPut": {
allowPut = true;
break;
}
case "doDelete": {
allowDelete = true;
break;
}
default:
// NO-OP
}
}
StringBuilder allow = new StringBuilder();
if (allowGet) {
allow.append(METHOD_GET);
allow.append(", ");
}
if (allowHead) {
allow.append(METHOD_HEAD);
allow.append(", ");
}
if (allowPatch) {
allow.append(METHOD_PATCH);
allow.append(", ");
}
if (allowPost) {
allow.append(METHOD_POST);
allow.append(", ");
}
if (allowPut) {
allow.append(METHOD_PUT);
allow.append(", ");
}
if (allowDelete) {
allow.append(METHOD_DELETE);
allow.append(", ");
}
// Options is always allowed
allow.append(METHOD_OPTIONS);
cachedAllowHeaderValue = allow.toString();
}
}
}
return cachedAllowHeaderValue;
}
Re: I have just created a pull request for 8.5.x branch but that is invisible
Posted by koteswara Rao Gundapaneni <ko...@gmail.com>.
Yes I agree
Koti
On Tue, 26 Dec 2023, 23:36 Mark Thomas, <ma...@apache.org> wrote:
> On 26/12/2023 12:00, koteswara Rao Gundapaneni wrote:
> > HTTP Patch option should be deprecated as the option is doing partial
> > changes to an existing resource.
>
> PATCH is a method, not an option. Using the correct terminology is
> important to avoid confusion. Especially when OPTIONS is also a method.
>
> Support for PATCH is an Jakarta Servlet project decision, not a Tomcat
> project decision. Wearing my Tomcat committer hat, I agree that PATCH
> should be supported.
>
> Note that PATCH is only supported if a Servlet explicitly implements
> support for PATCH.
>
> > combination of the options and trace methods works very well rather than
> > the Http PATCH
>
> Wrong. PATCH enables modification. Neither TRACE nor OPTIONS nor a
> combination of TRACE and OPTIONS enable modification.
>
> > It works very well when the jsperror page is redirected as it shown trace
> > option
>
> The above sentence makes no sense.
>
> > private String getCachedAllowHeaderValue() {
>
> <snip/>
>
> Please do not quote extensive blocks of existing code. It is pointless.
>
> If you want to propose a patch, do so via Bugzilla or submit a PR via
> GitHub.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: I have just created a pull request for 8.5.x branch but that is invisible
Posted by Mark Thomas <ma...@apache.org>.
On 26/12/2023 12:00, koteswara Rao Gundapaneni wrote:
> HTTP Patch option should be deprecated as the option is doing partial
> changes to an existing resource.
PATCH is a method, not an option. Using the correct terminology is
important to avoid confusion. Especially when OPTIONS is also a method.
Support for PATCH is an Jakarta Servlet project decision, not a Tomcat
project decision. Wearing my Tomcat committer hat, I agree that PATCH
should be supported.
Note that PATCH is only supported if a Servlet explicitly implements
support for PATCH.
> combination of the options and trace methods works very well rather than
> the Http PATCH
Wrong. PATCH enables modification. Neither TRACE nor OPTIONS nor a
combination of TRACE and OPTIONS enable modification.
> It works very well when the jsperror page is redirected as it shown trace
> option
The above sentence makes no sense.
> private String getCachedAllowHeaderValue() {
<snip/>
Please do not quote extensive blocks of existing code. It is pointless.
If you want to propose a patch, do so via Bugzilla or submit a PR via
GitHub.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org