[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alonso Gonzalez updated CXF-8962:
-
Description:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit}} called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed om omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
was:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit }}called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed om omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no co
[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alonso Gonzalez updated CXF-8962:
-
Description:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit}} called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed to omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation should handle DELETE requests with empty body correctly
or evaluate the existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
was:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit}} called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed to omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELE
[jira] [Updated] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
[
https://issues.apache.org/jira/browse/CXF-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alonso Gonzalez updated CXF-8962:
-
Description:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit}} called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed to omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
was:
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit}} called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed om omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
> HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty
> body
> --
>
> Key: CXF-8962
> URL: https://issues.apache.org/jira/browse/CXF-8962
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 4.0.3
>Reporter: Alonso Gonzalez
>Priority: Major
>
> We call a DELETE endoint of a REST API, but the server rejects the call with
> a client error, because CXF sends "Content-Type: text/xml" although the
> content is empty (as suggested by RFC 9110).
>
> The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
> calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
> computes a "Content-Type" header if the verb is not in the list
> KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although
> RFC 9110 states that DELETE requests should not have content [1]. Thus if a
> client follows the RFC and sends a DELETE request with no con
[jira] [Created] (CXF-8962) HttpClientHTTPConduit sets Content-Type Header for DELETE requests with empty body
Alonso Gonzalez created CXF-8962:
Summary: HttpClientHTTPConduit sets Content-Type Header for DELETE
requests with empty body
Key: CXF-8962
URL: https://issues.apache.org/jira/browse/CXF-8962
Project: CXF
Issue Type: Bug
Components: Transports
Affects Versions: 4.0.3
Reporter: Alonso Gonzalez
We call a DELETE endoint of a REST API, but the server rejects the call with a
client error, because CXF sends "Content-Type: text/xml" although the content
is empty (as suggested by RFC 9110).
The implementation of {{setProtocolHeaders()}} in {{HttpClientHTTPConduit}}
calls {{setProtocolHeadersInBuilder()}} to set the HTTP headers. This methods
computes a "Content-Type" header if the verb is not in the list
KNOWN_HTTP_VERBS_WITH_NO_CONTENT. DELETE is not part of this list although RFC
9110 states that DELETE requests should not have content [1]. Thus if a client
follows the RFC and sends a DELETE request with no content, CXF will
nonetheless set a Content-Type header. {{Headers#determineContentType}} uses
"text/xml" as fallback if no content type can be computed.
The old implementation {{URLConnectionHTTPConduit }}called a
{{Headers#setProtocolHeadersInConnection}} to set the headers. This method
allowed om omit the "Content-Type" header via the property
"set.content.type.for.empty.request".
The new implementation handle DELETE requests correctly or evaluate the
existing property "set.content.type.for.empty.request".
[1]
{quote}Although request message framing is independent of the method used,
content received in a DELETE request has no generally defined semantics, cannot
alter the meaning or target of the request, and might lead some implementations
to reject the request and close the connection because of its potential as a
request smuggling attack (Section 11.2 of [HTTP/1.1]). A client SHOULD NOT
generate content in a DELETE request unless it is made directly to an origin
server that has previously indicated, in or out of band, that such a request
has a purpose and will be adequately supported.
{quote}
[https://www.rfc-editor.org/rfc/rfc9110.html#name-delete]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FEDIZ-256) Tomcat authenticationSessionTimeout
[
https://issues.apache.org/jira/browse/FEDIZ-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17789439#comment-17789439
]
Tomas Milian commented on FEDIZ-256:
Hello [~coheigea],
I tested Tomcat 9.0.83 which fixes the authenticationSessionTimeout in
FromAuthenticator.
Unfortunately Fediz Tomcat plugin still does not recover the original session
timeout :(
Sorry I couldn't do any further debugging but from what I've seen
restoreRequest is never called from FedereationAuthenticator
> Tomcat authenticationSessionTimeout
> ---
>
> Key: FEDIZ-256
> URL: https://issues.apache.org/jira/browse/FEDIZ-256
> Project: CXF-Fediz
> Issue Type: Bug
> Components: Plugin
>Affects Versions: 1.6.1
>Reporter: Tomas Milian
>Assignee: Colm O hEigeartaigh
>Priority: Major
>
> Hello,
> I was configuring Fediz 1.6.1 on Tomcat 9.0.74 and found the following issue.
> Tomcat 9.0.74 introduced a new FORM authenticator Valve attribute
> (authenticationSessionTimeout) that breaks Fediz authentication process.
> {color:#172b4d}Fediz uses FormAuthenticator to save the request, the change
> introduced in Tomcat 9.0.74 replaces the original session timeout with the
> authenticationSessionTimeout default value (120 seconds).{color}
> {code:java}
> if (session instanceof HttpSession && ((HttpSession)
> session).isNew()) {
> int originalMaxInactiveInterval =
> session.getMaxInactiveInterval();
> if (originalMaxInactiveInterval >
> getAuthenticationSessionTimeout()) {
>
> saved.setOriginalMaxInactiveInterval(originalMaxInactiveInterval);
>
> session.setMaxInactiveInterval(getAuthenticationSessionTimeout());
> }
> } {code}
> {color:#172b4d}Once the Fediz authentication is resumed, the original session
> maxInactiveInterval is not restored, so authenticated session always ends up
> with a 120 second maxInactiveInterval{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
