garydgregory commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408694242
Hi @ok2c
Tl;dr: Yes.
I think we need to decide whether we want 100% binary compatibility or not.
If it were my decision alone I would strive for 100% BC. Jar hell
CelestiaTheDryad commented on PR #495:
URL:
https://github.com/apache/httpcomponents-core/pull/495#issuecomment-2408688333
That's correct. We use HttpCore to serve the files for our web app and the
REST API that controls the back-end server. We encountered this issue when
upgrading to Http
ok2c commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408680195
@garydgregory Do you want me to revert the commit and ask @osipxd to re-spin
the PR with a more conservative fix?
--
This is an automated message from the Apache Git Service.
[
https://issues.apache.org/jira/browse/HTTPCORE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888932#comment-17888932
]
Michael Osipov commented on HTTPCORE-771:
-
I comment in the code would be helpf
[
https://issues.apache.org/jira/browse/HTTPCORE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888930#comment-17888930
]
Gary D. Gregory commented on HTTPCORE-771:
--
The change looks good to me.
> Ex
garydgregory commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408654045
I'm still skeptical, this looks to me like 2 bugs in JApiCmp 😞
- The change from non-`final` to `final` breaks subclasses since the
containing class is public and no
ok2c commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408599142
@garydgregory
1. We are using version 0.21.2 of `JApiCmp` which almost the latest.
2. The change-set does not change the return type. It changes from `void`
(no return typ
garydgregory commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408590622
I tried changing the return type on a static method in a different project
(Apache Commons IO) and JApiCmp failed with:
```
[ERROR] Failed to execute goal
com.gith
[
https://issues.apache.org/jira/browse/HTTPCORE-771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888905#comment-17888905
]
Oleg Kalnichevski commented on HTTPCORE-771:
I can now reproduce the issue
ok2c opened a new pull request, #497:
URL: https://github.com/apache/httpcomponents-core/pull/497
(no comment)
--
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 unsubscrib
+1.
Being strict. No need to flood the logs
Arturo
On Sat, Oct 12, 2024 at 3:14 PM Oleg Kalnichevski wrote:
> On Sat, 2024-10-12 at 07:43 -0400, Gary Gregory wrote:
> > I think the remaining decisions are:
> >
> > - whether we should log a warning (but not throw an exception) when
> > both
>
On Sat, 2024-10-12 at 07:43 -0400, Gary Gregory wrote:
> I think the remaining decisions are:
>
> - whether we should log a warning (but not throw an exception) when
> both
> are present and equal.
> - what to do if both are present but not equal, at least log a
> warning, but
> not throw an excep
I think the remaining decisions are:
- whether we should log a warning (but not throw an exception) when both
are present and equal.
- what to do if both are present but not equal, at least log a warning, but
not throw an exception because of the SHOULD?
Gary
On Sat, Oct 12, 2024, 7:17 AM Oleg K
On Sat, 2024-10-12 at 07:04 -0400, Gary Gregory wrote:
> Hi all,
>
> Considering the text you quote and the SHOULD definition in
> https://datatracker.ietf.org/doc/html/rfc2119#section-3Â then we are
> indeed
> in the wrong (IMO) and we need to allow for the Host header to be
> processed
> in the a
Hi,
Checking RFC 7540 once again, it looks clear that while clients *SHOULD*
use :authority instead of Host, this is not a strict *MUST*. There’s no
explicit prohibition of the Host header in HTTP/2 requests.
Maybe we should reconsider our current approach of treating such requests
as malformed.
Hi all,
Considering the text you quote and the SHOULD definition in
https://datatracker.ietf.org/doc/html/rfc2119#section-3 then we are indeed
in the wrong (IMO) and we need to allow for the Host header to be processed
in the absence of the ":authority" pseudo-header.
Gary
On Sat, Oct 12, 2024,
Folks
Presently HttpCore HTTP/2 protocol handler treats HTTP/2 request
messages with a `Host` header as malformed.
However I just recently discovered that Apache HTTPD happily sends us
push promise requests with a `Host` header in them. Initially I thought
it was a bug in HTTPD and was going to r
ok2c commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408510469
Cherry-picked to `5.4.x`
--
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 spec
ok2c merged PR #588:
URL: https://github.com/apache/httpcomponents-client/pull/588
--
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...@hc.ap
ok2c commented on PR #588:
URL:
https://github.com/apache/httpcomponents-client/pull/588#issuecomment-2408509126
@osipxd I suppose I was wrong. The return type is not a part of method name
signature and changing return type from void to something else does not cause
compile incompatibility
ok2c commented on PR #495:
URL:
https://github.com/apache/httpcomponents-core/pull/495#issuecomment-2408504586
Cherry-picked to `5.3.x`. Many thanks @CelestiaTheDryad for this
contribution.
I am baffled though as to how we never came across this problem before. Do
I understand it
ok2c merged PR #495:
URL: https://github.com/apache/httpcomponents-core/pull/495
--
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...@hc.apac
ok2c commented on PR #496:
URL:
https://github.com/apache/httpcomponents-core/pull/496#issuecomment-2408472787
Cherry-picked to `5.3.x`
--
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 specif
ok2c merged PR #496:
URL: https://github.com/apache/httpcomponents-core/pull/496
--
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...@hc.apac
dependabot[bot] closed pull request #492: Bump io.fabric8:docker-maven-plugin
from 0.45.0 to 0.45.1
URL: https://github.com/apache/httpcomponents-core/pull/492
--
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
dependabot[bot] commented on PR #492:
URL:
https://github.com/apache/httpcomponents-core/pull/492#issuecomment-2408462247
Looks like io.fabric8:docker-maven-plugin is no longer a dependency, so this
is no longer needed.
--
This is an automated message from the Apache Git Service.
To resp
ok2c merged PR #494:
URL: https://github.com/apache/httpcomponents-core/pull/494
--
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...@hc.apac
ok2c commented on PR #494:
URL:
https://github.com/apache/httpcomponents-core/pull/494#issuecomment-2408456486
> Shouldn't the tests rely solely on `TestContainers` automatic clean-up?
Wouldn't adding explicit `@AfterEach` calls to stop containers be a good idea
as a fail-safe, especially
28 matches
Mail list logo
