[jira] [Commented] (CXF-8972) Server exception raised when no Content-Type param provided
[
https://issues.apache.org/jira/browse/CXF-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814594#comment-17814594
]
Yoshani Ranaweera commented on CXF-8972:
[~reta] the end-user experience I see here is that when the client misses the
optional Content-Type header param, regardless of the actual body content, a
server exception is raised and logged. Is this expected?
> Server exception raised when no Content-Type param provided
> ---
>
> Key: CXF-8972
> URL: https://issues.apache.org/jira/browse/CXF-8972
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Reporter: Yoshani Ranaweera
>Priority: Major
>
> If a request is sent without the Content-Type header parameter, a server
> exception _javax.ws.rs.WebApplicationException: HTTP 415 Unsupported Media
> Type_ is raised [1] and the below server error log is printed.
> _{org.apache.cxf.jaxrs.utils.JAXRSUtils} - No message body reader has been
> found for class java.lang.String, ContentType: application/octet-stream_
> Since this is a client error, it should not be handled as a server exception.
> [1]
> [https://github.com/apache/cxf/blob/main/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/utils/JAXRSUtils.java#L1581]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814532#comment-17814532
]
Andriy Redko commented on CXF-8975:
---
Cross posting from the pull request, as per rfc1341 (see please
https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html):
{noformat}
Overall, the body of a multipart entity may be specified as follows:
multipart-body := preamble 1*encapsulation
close-delimiter epilogue
encapsulation := delimiter CRLF body-part
delimiter := CRLF "--" boundary ; taken from Content-Type
field.
; when content-type is
multipart
; There must be no space
; between "--" and boundary.
close-delimiter := delimiter "--" ; Again, no space before
"--"
preamble := *text ; to be ignored upon
receipt.
epilogue := *text ; to be ignored upon
receipt.
body-part = <"message" as defined in RFC 822,
with all header fields optional, and with the
specified delimiter not occurring anywhere in
the message body, either on a line by itself
or as a substring anywhere. Note that the
semantics of a part differ from the semantics
of a message, as described in the text.>{noformat}
The element in question is
{noformat}
close-delimiter := delimiter "--" ; Again, no space before {noformat}
There should be a problem somewhere else I believe.
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Critical
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
>
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8975:
--
Priority: Minor (was: Critical)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Minor
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andriy Redko updated CXF-8975:
--
Priority: Major (was: Minor)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Major
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
---
Priority: Critical (was: Major)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Critical
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing ending CRLF in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
---
Summary: Missing ending CRLF in multipart request (was: Missing \r\n in
multipart request)
> Missing ending CRLF in multipart request
>
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Major
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CXF-8975) Missing \r\n in multipart request
[
https://issues.apache.org/jira/browse/CXF-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Chauvet updated CXF-8975:
---
External issue URL: https://github.com/apache/cxf/pull/1674
Flags: Patch
> Missing \r\n in multipart request
> -
>
> Key: CXF-8975
> URL: https://issues.apache.org/jira/browse/CXF-8975
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.4, 3.5.7
>Reporter: Guillaume Chauvet
>Priority: Major
>
> Hello,
> I'm contacting you because I'm experiencing a problem that seems to be a bug
> when calling a REST service in multipart mode via jarxr-client in proxy mode.
> I'm working with version 3.1.4 but I've also tested with version 3.5.7
> (Unable to use a more recent version for technical reasons).
> h2. Description of the problem:
> h3. Current code:
> I have an interace containing the following signature:
> {code:java}
> @Consumes({ "multipart/form-data" })
> @Produces({ "application/json" })
> FileId create(MultipartBody body);
> {code}
> Then code to call the service (code from an integration test):
> {code:java}
> @Resource(name = "myApi") // defined in a spring context with jaxrs:client
> private MyApi api;
> @Test
> public void addContent() {
> final Attachment file = new Attachment("file",
> MimeTypeUtils.TEXT_PLAIN_VALUE, IOUtils.toInputStream("TEST"));
> final MultipartBody body = new MultipartBody(file);
> final FileId result = api.create(body);
> assertNotNull(result);
> }
> {code}
> h3. Result obtained:
> I obtain the following trace:
> {noformat}
> INFOS: Outbound Message
> ---
> ID: 1
> Address: https://XX/file
> Http-Method: POST
> Content-Type: multipart/form-data;
> boundary="uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f"
> Headers: {Accept=[application/json], Authorization=[Bearer
> ]}
> Payload: --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f
> Content-Type: text/plain
> Content-Transfer-Encoding: binary
> Content-ID:
> TEST
> --uuid:e8db85d9-f27e-4220-97c6-3f5ec4c3e08f--
> {noformat}
> ... and the webservice response:
> {noformat}
> --
> févr. 02, 2024 10:02:50 AM org.apache.cxf.interceptor.LoggingInInterceptor
> INFOS: Inbound Message
>
> ID: 1
> Response-Code: 500
> Encoding: ISO-8859-1
> Content-Type: application/json
> Headers: {cache-control=[no-cache, no-store, max-age=0, must-revalidate],
> Content-Length=[7930], content-type=[application/json], date=[Fri, 2 Feb 2024
> 09:02:50 GMT], expires=[0], pragma=[no-cache],
> x-content-type-options=[nosniff], x-frame-options=[DENY],
> x-xss-protection=[1; mode=block]}
> Payload: {"type":"X","title":"Unhandled
> Error","status":500,"detail":"Maybe more than one part sent, epilogue is not
> empty, or CRLF is missing before end delimiter ? 4 bytes read for file part
> but 2 expected according to content-length header."}
> {noformat}
> After a bit of digging, I realized that the problem lies in the
> writeAttachments method of the AttachmentSerializer class:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--"); // <--- HERE
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> I was able to correct my problem locally by making this correction:
> {code:java}
> StringWriter writer = new StringWriter();
> writer.write("\r\n--");
> writer.write(bodyBoundary);
> writer.write("--\r\n"); // <-- fixing her
> out.write(writer.getBuffer().toString().getBytes(encoding));
> out.flush();
> {code}
> And the call succeeds with a 201 code and a JSON response as expected
> However, I'm dubious about stumbling across such an error, so I wonder if
> I've missed something?
> Sincerely
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CXF-8971) Introduce a customerizedAlgorithmSuite and make all parameters of it configurable
[
https://issues.apache.org/jira/browse/CXF-8971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17814374#comment-17814374
]
Peter Palaga commented on CXF-8971:
---
[~ffang] thanks for bringing up the option to implement this via properties. It
would be a good start if others are fine with it.
On the other hand, I'd still see configuring this in the policy as superior,
mainly because it makes sharing the configuration between servers and clients
much easier.
I had the impression so far that the properties were meant to store the
information that must not be public, such as keys and passwords. Now that you
show that there already some algorithms config in the properties, I am not so
sure anymore :).
Anyway, it would be interesting to hear what others think.
> Introduce a customerizedAlgorithmSuite and make all parameters of it
> configurable
> -
>
> Key: CXF-8971
> URL: https://issues.apache.org/jira/browse/CXF-8971
> Project: CXF
> Issue Type: Improvement
>Reporter: Freeman Yue Fang
>Priority: Major
>
> In ws-securitypolicy, currently we have a list of AlgorithmSuite by name,
> some are defined in ws-securitypolicy, they are
> {code}
> Basic256
> Basic192
> Basic128
> TripleDes
> Basic256Rsa15
> Basic192Rsa15
> Basic128Rsa15
> TripleDesRsa15
> Basic256Sha256
> Basic192Sha256
> Basic128Sha256
> TripleDesSha256
> Basic256Sha256Rsa15
> Basic192Sha256Rsa15
> Basic128Sha256Rsa15
> TripleDesSha256Rsa15
> {code}
> And some are from CXF itself to address CVEs, they are
> {code}
> Basic128GCM
> Basic192GCM
> Basic256GCM
> {code}
> so if users specify a AlgorithmSuite name like
> {code}
>
>
>
>
>
> {code}
> they will get a AlgorithmSuiteType instance of all parameters hardcoded with
> this AlgorithmSuite name.
> {code}
> new AlgorithmSuiteType(
> "Basic256Sha256Rsa15",
> SPConstants.SHA256,
> SPConstants.AES256,
> SPConstants.KW_AES256,
> SPConstants.KW_RSA15,
> SPConstants.P_SHA1_L256,
> SPConstants.P_SHA1_L192,
> 256, 192, 256,
> MAX_SKL, MIN_AKL, MAX_AKL)
> {code}
> However, security algorithms are evolving and some old-time algos may get
> cracked, or sometimes only some limited modern/strong security algorithms can
> be used in some scenarios, so current available AlgorithmSuiteType from both
> ws-securitypolicy or CXF may not meet the specific requirements.
> It would be great that we can introduce a fully configurable
> AlgorithmSuiteType which could be named as ,say, customerizedAlgorithmSuite
> which could have default values, but the parameters of AlgorithmSuiteType can
> be configured via endpoint(client or server) properties. This flexibility can
> offer us more convenience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
