Re: [PR] CXF-9082: Allow to modify sensitive header list [cxf]
reta commented on code in PR #2150:
URL: https://github.com/apache/cxf/pull/2150#discussion_r1845242065
##
rt/transports/http/src/main/java/org/apache/cxf/transport/http/Headers.java:
##
@@ -580,4 +580,8 @@ public static String toHttpDate(Date date) {
public static String toHttpLanguage(Locale locale) {
return locale.toString().replace('_', '-');
}
+
+public static List getSensitiveHeaderList() {
Review Comment:
Please convert `SENSITIVE_HEADERS` to the contextual property:
```
private static final String SENSITIVE_HEADERS =
"org.apache.http.sensitive.headers";
List getSensitiveHeaders() {
return MessageUtils.getContextualStrings(message, SENSITIVE_HEADERS,
Set.of("Authorization", "Proxy-Authorization");
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
> The option to use a List or a MultipartBody does work, I've
> testcases to confirm this.
Correct, what I meant is if could keep the API contract as:
Response api(Attachment a1, Attachment a2, Attachment a3)
But (internally only) fold it to:
Response api(List atts)
So you would preserve all the API contract metadata, as you have it now,
however CXF
would go one step further to support it behind the scene. I think that is what
you
are looking for, no need to tinker with @Multipart otherwise, is that the case?
> Strangely I don't even find a reference to the header Content-ID in
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers.
Content-ID is not a HTTP header but "cid:" from
https://www.rfc-editor.org/rfc/rfc2392.txt,
as you also referred to.
Thanks!
Best Regards,
Andriy Redko
> Hi Andriy,
> The option to use a List or a MultipartBody does work, I've
> testcases to confirm this.
> But it somehow breaks the original spec since trying to do a round trip
code->>>spec),
> the spec generated from the code (based on annotations) no longer
> reflects the input spec.
> What I find unexpected is that for multipart bodies all input parameters
> are attempted to be wrapped into Attachment objects,
> (cf. method
> org.apache.cxf.jaxrs.client.ClientProxyImpl#handleMultipart(MultivaluedMap
> map,OperationResourceInfo ori,Object[]
> params)).
> So why doesn't the stack allow to mix request body parameters that are
> either @Multipart annotated or are Attachment itself.
> Now you can't mix them since
> org.apache.cxf.jaxrs.client.ClientProxyImpl#getParametersInfo(Method
> m,Object[] params, OperationResourceInfo ori) will fail
> with error "SINGLE_BODY_ONLY". It wouldn't be hard to support the mixture
> of both, or even an @Multipart annotated Attachment parameter (you could
> just combine what is specified in the annotation with what is already
> present in the Attachment, giving priority to one of both in case of
> overlapping parameters).
> Further, if 'Content-Disposition' is obligatory (at least by openAPI spec,
> however don't know whether this is the industry reference) why doesn't the
> @Multipart
> annotation allow to specify it? Why i.o. setting header Content-ID=
> isn't the header Content-Disposition=form-date:name="value" set when
> wrapping
> a @Multipart annotated object into an Attachment object?
> Strangely I don't even find a reference to the header Content-ID in
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers. It is described
> in
> https://www.rfc-editor.org/rfc/rfc2045#section-7,
> https://www.rfc-editor.org/rfc/rfc2392.txt and should have the form
> 'url-addr-spec according to RFC822'
> enclosed within '<>' and it is used to reference a multipartbody part in
> another part of the message. This doesn't seem to be the context in which
> it is used in
> JAX-RS messages, further the url-addr-spec actually tells me there should
> a ' @' sign in the value of the content-id header which is surely not the
> case in all examples
> I've seen sofar. So why is CXF even using Content-ID?
> Regards,
> J.P.
> -Oorspronkelijk bericht-
> Van: Andriy Redko
> Verzonden: vrijdag 15 november 2024 21:02
> Aan: Jean Pierre URKENS ;
> dev@cxf.apache.org
> Onderwerp: Re: CXF JAX-RS: working with multipart form-data
> Hi Jean,
> Sorry for the delay, just went over through the message thread. So option
> 1-2 should
> indeed work just fine. And for 1st option, you could indeed set the
> headers manually.
> And in this case, you will need to craft the OpenAPI spec manually, it
> won't be properly
> deducted.
> I don't think adding more attributes to @Multipart would help since it is
> going to
> in conflict with File / Attachment that by itself source these attributes.
> But gimme
> some time to experiment over the weekend, I think, intuitively, that this
> could work
> (doesn't right now):
> Response testMessage1(
> @HeaderParam("x-correlation-id") @NotNull
> @Size(min = 10, max = 36)
> @Parameter(description="ID of the transaction. Use this ID for log tracing
> and incident handling.") String xCorrelationId,
> @HeaderParam("Idempotency-Key") @NotNull @Size(min
> = 10, max = 36)
> @Parameter(description="When retrying a failed call, the retry call should
> have the same Idempotency Key.") String idempotencyKey,
> @FormDataParam(value="messageToSend")
> @Parameter(required=true,schema =
> @Schema(implementation=MessageToSend.class)) @Multipart(value =
> "messageToSend", type="application/json", required= true) MessageToSend
> messageToSend,
> @FormDataParam(value="upfile1") @Parameter(schema
> = @Schema(type =
> "string", format = "binary")) Attachment upfile1Detail,
> @FormDataParam(value="upfile2") @Parameter(schema
> = @Schema(type =
> "string", format = "binary")) Attachment upfile2Detail,
>
Re: [PR] Fix possible IllegalStateException when bundle is stopped [cxf]
reta merged PR #2144: URL: https://github.com/apache/cxf/pull/2144 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@cxf.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
RE: CXF JAX-RS: working with multipart form-data
Hi Andriy,
The option to use a List or a MultipartBody does work, I've
testcases to confirm this.
But it somehow breaks the original spec since trying to do a round trip
engineering (spec->code->spec),
the spec generated from the code (based on annotations) no longer
reflects the input spec.
What I find unexpected is that for multipart bodies all input parameters
are attempted to be wrapped into Attachment objects,
(cf. method
org.apache.cxf.jaxrs.client.ClientProxyImpl#handleMultipart(MultivaluedMap
map,OperationResourceInfo ori,Object[]
params)).
So why doesn't the stack allow to mix request body parameters that are
either @Multipart annotated or are Attachment itself.
Now you can't mix them since
org.apache.cxf.jaxrs.client.ClientProxyImpl#getParametersInfo(Method
m,Object[] params, OperationResourceInfo ori) will fail
with error "SINGLE_BODY_ONLY". It wouldn't be hard to support the mixture
of both, or even an @Multipart annotated Attachment parameter (you could
just combine what is specified in the annotation with what is already
present in the Attachment, giving priority to one of both in case of
overlapping parameters).
Further, if 'Content-Disposition' is obligatory (at least by openAPI spec,
however don't know whether this is the industry reference) why doesn't the
@Multipart
annotation allow to specify it? Why i.o. setting header Content-ID=
isn't the header Content-Disposition=form-date:name="value" set when
wrapping
a @Multipart annotated object into an Attachment object?
Strangely I don't even find a reference to the header Content-ID in
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers. It is described
in
https://www.rfc-editor.org/rfc/rfc2045#section-7,
https://www.rfc-editor.org/rfc/rfc2392.txt and should have the form
'url-addr-spec according to RFC822'
enclosed within '<>' and it is used to reference a multipartbody part in
another part of the message. This doesn't seem to be the context in which
it is used in
JAX-RS messages, further the url-addr-spec actually tells me there should
a ' @' sign in the value of the content-id header which is surely not the
case in all examples
I've seen sofar. So why is CXF even using Content-ID?
Regards,
J.P.
-Oorspronkelijk bericht-
Van: Andriy Redko
Verzonden: vrijdag 15 november 2024 21:02
Aan: Jean Pierre URKENS ;
dev@cxf.apache.org
Onderwerp: Re: CXF JAX-RS: working with multipart form-data
Hi Jean,
Sorry for the delay, just went over through the message thread. So option
1-2 should
indeed work just fine. And for 1st option, you could indeed set the
headers manually.
And in this case, you will need to craft the OpenAPI spec manually, it
won't be properly
deducted.
I don't think adding more attributes to @Multipart would help since it is
going to
in conflict with File / Attachment that by itself source these attributes.
But gimme
some time to experiment over the weekend, I think, intuitively, that this
could work
(doesn't right now):
Response testMessage1(
@HeaderParam("x-correlation-id") @NotNull
@Size(min = 10, max = 36)
@Parameter(description="ID of the transaction. Use this ID for log tracing
and incident handling.") String xCorrelationId,
@HeaderParam("Idempotency-Key") @NotNull @Size(min
= 10, max = 36)
@Parameter(description="When retrying a failed call, the retry call should
have the same Idempotency Key.") String idempotencyKey,
@FormDataParam(value="messageToSend")
@Parameter(required=true,schema =
@Schema(implementation=MessageToSend.class)) @Multipart(value =
"messageToSend", type="application/json", required= true) MessageToSend
messageToSend,
@FormDataParam(value="upfile1") @Parameter(schema
= @Schema(type =
"string", format = "binary")) Attachment upfile1Detail,
@FormDataParam(value="upfile2") @Parameter(schema
= @Schema(type =
"string", format = "binary")) Attachment upfile2Detail,
@FormDataParam(value="upfile3") @Parameter(schema
= @Schema(type =
"string", format = "binary")) Attachment upfile3Detail)
If we could fold it into :
Response testMessage1(
@HeaderParam("x-correlation-id") @NotNull
@Size(min = 10, max = 36)
@Parameter(description="ID of the transaction. Use this ID for log tracing
and incident handling.") String xCorrelationId,
@HeaderParam("Idempotency-Key") @NotNull @Size(min
= 10, max = 36)
@Parameter(description="When retrying a failed call, the retry call should
have the same Idempotency Key.") String idempotencyKey,
@FormDataParam(value="messageToSend")
@Parameter(required=true,schema =
@Schema(implementation=MessageToSend.class)) @Multipart(value =
"messageToSend", type="application/json", required= true) MessageToSend
messageToSend,
List attachments)
This is just rough idea, but I will try look more closely into it.
Thanks.
Best Reg
