Please vote on releasing these packages as HttpCore 5.3.4.
The vote is open for the at least 72 hours, and only votes from
HttpComponents PMC members are binding. The vote passes if at least
three binding +1 votes are cast and there are more +1 than -1 votes.
Release notes:
https://dist.apache.o
Sebb created HTTPCORE-779:
-
Summary: Could not find links to SCM on website
Key: HTTPCORE-779
URL: https://issues.apache.org/jira/browse/HTTPCORE-779
Project: HttpComponents HttpCore
Issue Type: Bug
Sebb created HTTPCORE-780:
-
Summary: Travis links broken
Key: HTTPCORE-780
URL: https://issues.apache.org/jira/browse/HTTPCORE-780
Project: HttpComponents HttpCore
Issue Type: Bug
Component
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727284794
@outlandishlizard Thank you for sharing your opinion. Please do note
HttpClient does not support nested MIME bodies and never will. For anything
other than trivial cases it is r
michael-o commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727303778
> @outlandishlizard Thank you for sharing your opinion. Please do note
HttpClient does not support nested MIME bodies and never will. For anything
other than trivial cases
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727309189
Exactly compliant with that? The section in question is referring to "a body
part within another"multipart" entity". We do not have such cases.
--
This is an automated message
Folks
I propose we deprecate the existing MIME functionality in favor of
Apache Mime4j.
That was the initial plan all along. We should have stuck to it.
Oleg
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additio
michael-o commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727313858
> Exactly compliant with that? The section in question is referring to "a
body part within another"multipart" entity". We do not have such cases.
You mean that the cl
+1
- ASC file: OK
- SHA512 file: OK
- Building with: mvn clean verify -P'!use-toolchains'
Java versions tested:
openjdk version "1.8.0_442"
IBM Semeru Runtime Open Edition (build 1.8.0_442-b06)
Eclipse OpenJ9 VM (build openj9-0.49.0, JRE 1.8.0 Mac OS X
amd64-64-Bit Compressed References 20250205
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727482415
So, you contend that your users, consumers of an HTTP client library, are
responsible for piercing the abstraction layer, seeing that your code handles
multipart enc
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727477431
> who may be several wrappers downstream, will have any idea that they need
to escape these values-- it's not a normal application security consideration
at all.
This is
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727472365
> Circling back, what is the benefit of using a fixed boundary value?
@outlandishlizard They are not many: it is less computationally expensive
and is simple, the folks wo
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727473921
The RFC names quite a few reasons for using a pseudorandom or random value,
which I have quoted.
Additionally, I don't think that it is "providing a false sens
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727475216
Even if we accept your premise that this is a user responsibility to ensure
input never contains a boundary separator (something that they literally cannot
do in man
Hi Oleg,
I agree that moving to Apache Mime4j is the right direction and we should
deprecate our current MIME support.
Best,
Arturo
On Sun, Mar 16, 2025 at 11:06 AM Oleg Kalnichevski wrote:
> Folks
>
> I propose we deprecate the existing MIME functionality in favor of
> Apache Mime4j.
>
> Th
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727426304
Circling back, what is the benefit of using a fixed boundary value? It
appears to be a change that is less RFC compliant and less secure, and places
an unrealistic b
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727699464
> The above quote seems to me to say that you believe it is the
responsibility of your users to escape the boundary values
@outlandishlizard It is a responsibility of the
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727704480
No, the chance of a boundary value collision is NOT zero, as boundary value
collisions can also occur due to the message body containing the boundary
value, which is
On Sun, 2025-03-16 at 08:51 -0400, Gary Gregory wrote:
> Taking a peek at their web site, they mention having a parser.
Mime4j is a proper MIME library with a highly optimized pull parser and
a fully featured DOM builder.
I used to contribute to Mime4j quite a lot in 201x.
> Would
> this help
arturobernalg merged PR #517:
URL: https://github.com/apache/httpcomponents-core/pull/517
--
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..
ok2c commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727659742
> So, you contend that your users, consumers of an HTTP client library, are
responsible for piercing the abstraction layer
@outlandishlizard Please re-read what I have sa
Taking a peek at their web site, they mention having a parser. Would
this help remedy the ongoing discussion around clients and message
boundaries?
Gary
On Sun, Mar 16, 2025 at 6:06 AM Oleg Kalnichevski wrote:
>
> Folks
>
> I propose we deprecate the existing MIME functionality in favor of
> Ap
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727484276
I will also note that you have yet to address my comment that this
constitutes a breaking change that users had no way to defend themselves from--
surely you don't c
outlandishlizard commented on PR #619:
URL:
https://github.com/apache/httpcomponents-client/pull/619#issuecomment-2727681863
> > who may be several wrappers downstream, will have any idea that they
need to escape these values-- it's not a normal application security
consideration at all.
ok2c opened a new pull request, #624:
URL: https://github.com/apache/httpcomponents-client/pull/624
@arturobernalg Please review and double-check.
--
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
25 matches
Mail list logo