[GitHub] httpcomponents-core issue #49: HeaderGroup uses a ReadWriteLock for access t...

[cakofony]

Github user cakofony commented on the issue:

https://github.com/apache/httpcomponents-core/pull/49
  
> Could there be fewer changes if a CopyOnWriteArrayList is used instead of 
an ArrayList in HeaderGroup?

Possibly, I was worried about the performance aspects of CoW. HeaderGroup 
tends to iterate by index internally to avoid Iterator allocation, which still 
wouldn't be safe.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-core issue #49: HeaderGroup uses a ReadWriteLock for access t...

[garydgregory]

Github user garydgregory commented on the issue:

https://github.com/apache/httpcomponents-core/pull/49
  
Could there be fewer changes if a CopyOnWriteArrayList is used instead of 
an ArrayList in HeaderGroup? 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

Re: HttpCore 5.0: moving to BETA

[Gary Gregory]

On Wed, Aug 9, 2017 at 12:41 PM, Oleg Kalnichevski  wrote:

> Folks
>
> I just committed a large chunk of code with the last big feature I had
> in mind for the HttpCore 5.0 release. The server side transports (both
> classic and async) now provide filter support that can be used to
> implement cross-cutting aspects for all incoming requests such the
> expect-continue handshake or user authentication and authorization.
>
> https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes
> ting/src/test/java/org/apache/hc/core5/testing/classic/ClassicAuthentic
> ationTest.java
> https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes
> ting/src/test/java/org/apache/hc/core5/testing/nio/Http1AuthenticationT
> est.java
>
> Now I would like to shift the focus of development efforts from adding
> new features and making disruptive API changes to code stabilization,
> API polish and test coverage improvement. I
>
> _IMPORTANT_: if you would like to make some big API changes: move code
> around, rename packages and classes, introduce new naming conventions,
> propose new features with a large API footprint _NOW_ would be a good
> time to do so.
>
> @Gary
>
> You wanted to discuss naming conventions some while ago, did not you?
>

Maybe so but I do not recall ATM. I might have to dig through the archives
when I have some free time.

>
> It is probably also the right time to discuss whether or not we should
> consider building a full featured HTTP server with statement management
> (server side cookies), authentication (server side auth schemes),
> pluggable user registries, and all those things that used to be out of
> project scope.
>

Over that last few months, my focus has been on building a custom
proprietary proxy on top of HttpCore 4.

I've been telling myself that I should port it to Core 5 but it has felt a
little too soon, as I've seen a lot of code moving around there. It sounds
like the code should be more stable.

What I am looking at now, are some missing building blocks. For example, I
want to support the HTTP headers Via and Forwarded but there is no
HttpRequestInterceptor for these. I plan on writing those and if these are
plain enough, I would like to add them to Core 4 and 5.


>
> I would like to cut another, likely last, ALPHA release soon and
> propose moving to the BETA phase.
>

Great, I'm all for more Alpha and Beta releases.

Gary


> Oleg
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>

HttpCore 5.0: moving to BETA

[Oleg Kalnichevski]

Folks

I just committed a large chunk of code with the last big feature I had
in mind for the HttpCore 5.0 release. The server side transports (both
classic and async) now provide filter support that can be used to
implement cross-cutting aspects for all incoming requests such the
expect-continue handshake or user authentication and authorization.

https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes
ting/src/test/java/org/apache/hc/core5/testing/classic/ClassicAuthentic
ationTest.java
https://github.com/apache/httpcomponents-core/blob/master/httpcore5-tes
ting/src/test/java/org/apache/hc/core5/testing/nio/Http1AuthenticationT
est.java   

Now I would like to shift the focus of development efforts from adding
new features and making disruptive API changes to code stabilization,
API polish and test coverage improvement. I 

_IMPORTANT_: if you would like to make some big API changes: move code
around, rename packages and classes, introduce new naming conventions,
propose new features with a large API footprint _NOW_ would be a good
time to do so.

@Gary

You wanted to discuss naming conventions some while ago, did not you? 

It is probably also the right time to discuss whether or not we should
consider building a full featured HTTP server with statement management
(server side cookies), authentication (server side auth schemes),
pluggable user registries, and all those things that used to be out of
project scope.

I would like to cut another, likely last, ALPHA release soon and
propose moving to the BETA phase.

Oleg 

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-client pull request #82: Fixed NPE PoolingAsyncClientConnecti...

[cakofony]

Github user cakofony closed the pull request at:

https://github.com/apache/httpcomponents-client/pull/82


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-core pull request #48: BasicRequestProducer propagates failur...

[cakofony]

Github user cakofony closed the pull request at:

https://github.com/apache/httpcomponents-core/pull/48


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[jira] [Assigned] (HTTPCORE-481) Early response suspends output even when response status is not error

[Oleg Kalnichevski (JIRA)]

 [ 
https://issues.apache.org/jira/browse/HTTPCORE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Kalnichevski reassigned HTTPCORE-481:
--

 Assignee: Oleg Kalnichevski
Fix Version/s: 4.4.7

> Early response suspends output even when response status is not error
> -
>
> Key: HTTPCORE-481
> URL: https://issues.apache.org/jira/browse/HTTPCORE-481
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore NIO
>Affects Versions: 4.4.5
>Reporter: Tuomas Kiviaho
>Assignee: Oleg Kalnichevski
> Fix For: 4.4.7
>
>
> I have a {{text/event-stream}} response where status code 200 is sent 
> immediately back even when there is still request body streaming in process. 
> This works well with Jetty client but for some reason I could only receive 
> the first full buffer at server side when switching over to HttpAsyncClient. 
> The only visible notion that something went wrong was Jetty doing an idle 
> timeout cleanup. Luckily there is a notion of connection state which got 
> invalidated when response was received but only when request body streaming 
> was still in progress.
> I found out via this link 
> https://stackoverflow.com/questions/14250991/is-it-acceptable-for-a-server-to-send-a-http-response-before-the-entire-request
>  that probably the reason behind the behavior is to prevent flooding the 
> server in case of an error.
> {quote}
> An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the 
> network connection for an error status while it is transmitting the request. 
> If the client sees an error status, it SHOULD immediately cease transmitting 
> the body.
> {quote}
> Below is a patch that currently functions as a work-a-round for me. I'd still 
> prefer the current behavior in case of unauthorized authentication etc. 
> because the request body can be quite large.
> {code:title=org/apache/http/nio/protocol/HttpAsyncRequestExecutor.java:295}
>  } else if (state.getRequestState() == MessageState.BODY_STREAM) {
>  // Early response
> +if (statusCode >= 400) {
> conn.resetOutput();
> conn.suspendOutput();
> state.setRequestState(MessageState.COMPLETED);
> state.invalidate();
> +}
>  }
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-client issue #82: Fixed NPE PoolingAsyncClientConnectionManag...

[ok2c]

Github user ok2c commented on the issue:

https://github.com/apache/httpcomponents-client/pull/82
  
Please review and close.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-client pull request #82: Fixed NPE PoolingAsyncClientConnecti...

[ok2c]

Github user ok2c commented on a diff in the pull request:


https://github.com/apache/httpcomponents-client/pull/82#discussion_r132268912
  
--- Diff: 
httpclient5/src/main/java/org/apache/hc/client5/http/impl/nio/PoolingAsyncClientConnectionManager.java
 ---
@@ -183,6 +184,12 @@ public void execute(final Boolean result) {
 
 })));
 } else {
+if (!connection.isOpen()) {
--- End diff --

The stale connection check (as an attempt to read from the socket) is only 
applicable to blocking connections.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-client pull request #82: Fixed NPE PoolingAsyncClientConnecti...

[cakofony]

Github user cakofony commented on a diff in the pull request:


https://github.com/apache/httpcomponents-client/pull/82#discussion_r132220250
  
--- Diff: 
httpclient5/src/main/java/org/apache/hc/client5/http/impl/nio/PoolingAsyncClientConnectionManager.java
 ---
@@ -183,6 +184,12 @@ public void execute(final Boolean result) {
 
 })));
 } else {
+if (!connection.isOpen()) {
--- End diff --

This seems to be half the implementation of the blocking connection 
`isStale()` check


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org

[GitHub] httpcomponents-client pull request #82: Fixed NPE PoolingAsyncClientConnecti...

[cakofony]

GitHub user cakofony opened a pull request:

https://github.com/apache/httpcomponents-client/pull/82

Fixed NPE PoolingAsyncClientConnectionManager

PoolingAsyncClientConnectionManager.validateAfterInactivity causes
an NPE when PoolEntries are initially created with no Connection.

Added logic to avoid checking the connection on every pool
checkout similar to the blocking pool.

Added an connection.isOpen check to http1.x connections leased
from the pool, although I'm unsure if it's at all effective.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/cakofony/httpcomponents-client 
async_conpool_npe

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/httpcomponents-client/pull/82.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #82


commit e22748f171ea55aa1c6343e763f797f69e720983
Author: Carter Kozak 
Date:   2017-08-09T15:27:28Z

Fixed NPE PoolingAsyncClientConnectionManager

PoolingAsyncClientConnectionManager.validateAfterInactivity causes
an NPE when PoolEntries are initially created with no Connection.

Added logic to avoid checking the connection on every pool
checkout similar to the blocking pool.

Added an connection.isOpen check to http1.x connections leased
from the pool, although I'm unsure if it's at all effective.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org