Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-02 Thread Michael Osipov 

Am 2018-01-31 um 14:06 schrieb Oleg Kalnichevski:

Folks

We have a dubious honor of having absolutely the most hideous project
web site in existence. It makes my eyes bleed every time I have to
update it. It is simply horrible.

I would like to migrate project website sources from Maven apt and xdoc
  to markdown format and switch to using either jekyll or hugo site
generator to render markdown to html.

1. Does anyone have conceptual objections to using markdown?


No, but is there any huge benefit over apt?
xdoc is horrible.


2. Does anyone have any preference with regards to static site
generators?


Maven Doxia includes now Markdown support based on flexmark-java.

Have you considered that instead of build another chain?

Michael


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

Re: Roadmap httpclient library

2018-02-02 Thread Gary Gregory 
On Feb 2, 2018 06:21, "Oleg Kalnichevski"  wrote:

On Fri, 2018-02-02 at 13:04 +0100, Alberto Requena wrote:
> Hi all,
>
> We are intended to use the httpclient library in one of our projects,
> which
> needs to send HTTP/2 requests to Apple's APNs.
>
> Is there a roadmap of the httpclient library somewhere, so that we
> can
> foresee and plan realistic estimations?
>

Well, there is one but it has not been updated for months and is now
completely useless.
https://wiki.apache.org/HttpComponents/HttpComponentsRoadmap

I'll remove it shortly.

HttpClient 5.0 is feature complete as far as I am concerned. I do not
intent to add any more features to it unless some people need something
really bad and are willing to contribute code or help testing.

I have no intention of repeating the same mistake as with HC 4.0 GA
release. I would like to keep HC 5.0 BETA for a considerable period of
time.

5.0 Roadmap: long, long BETA testing phase.

+1 to a long beta.

Gary


Oleg


> Apologise in advance if this information's been already provided or
> if this
> is not the correct channel for such question.
>
> Thank you in advance.

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

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-02 Thread Oleg Kalnichevski 
On Fri, 2018-02-02 at 17:05 +, sebb wrote:
> On 2 February 2018 at 13:33, Oleg Kalnichevski 
> wrote:
> > On Wed, 2018-01-31 at 20:18 +, sebb wrote:
> > > It may not be pretty, but I find it legible and generally easy to
> > > navigate so I hope those attributes won't be lost.
> > > 
> > > Also, it's important not to break any links.
> > > 
> > 
> > It is also important to eat healthy, be polite and stay away from
> > those
> > girls.
> > 
> > I am sorry, Sebastian, but links are likely to get broken and some
> 
> It's not necessary to change the site design.
> Nor is it necessary to drop Maven.
> 

Of course not, as long as some other poor sucker has to maintain that
site.

> I think links are a lot more more important than looks.
> 

This is not so much about the look of the site being terrible (which is
a consequence, not a cause) but about the way the site gets generated
is terrible. 

Have you ever wondered why there has been literally not a single
contribution to our web site from an external contributor? 

Have you ever wondered why there have been only two substantial
contributions to our documentation in the past 10 years? I suspect the
reason is the same.

Oleg




> > Maven generated reports are not going to be there anymore. If some
> > people feel strongly about it, they are welcome to help fixing them
> > and
> > provide missing content.
> > 
> > Oleg
> > 
> > 
> > > If the site is no longer built using Maven, then it may be
> > > difficult
> > > to preserve all the links (e.g. project info page links).
> > > 
> > > It appears to be possible to use Markdown with Maven:
> > > https://stackoverflow.com/questions/14829190/how-to-use-markdown-
> > > for-
> > > maven-project-site
> > > 
> > > Ideally anchors (internal page links) will also be maintained as
> > > far
> > > as possible.
> > > 
> > > S.
> > > 
> > > On 31 January 2018 at 19:15, Gary Gregory  > > >
> > > wrote:
> > > > On Wed, Jan 31, 2018 at 7:57 AM, Oleg Kalnichevski  > > > e.or
> > > > g> wrote:
> > > > 
> > > > > On Wed, 2018-01-31 at 07:43 -0700, Gary Gregory wrote:
> > > > > > > 
> > > > > 
> > > > > ...
> > > > > 
> > > > > 
> > > > > > On Wed, Jan 31, 2018 at 6:06 AM, Oleg Kalnichevski  > > > > > pach
> > > > > > e.org>
> > > > > > wrote:
> > > > > > 
> > > > > > Granted the site is not the most attractive, the only time
> > > > > > I
> > > > > > want to
> > > > > > dedicate to this topic is to discuss it here. I do not care
> > > > > > about
> > > > > > which
> > > > > > tools we use to get us to a new site. For my money, I'd
> > > > > > simply
> > > > > > try to
> > > > > > improved what we have now we a different stylesheet
> > > > > > (Fluido?).
> > > > > > For
> > > > > > example,
> > > > > > this is fine with me:
> > > > > > https://logging.apache.org/log4j/2.x/manual/architecture.ht
> > > > > > ml
> > > > > > and
> > > > > > it's all
> > > > > > Maven.
> > > > > > 
> > > > > 
> > > > > I understand that but you opinion might rapidly change once
> > > > > you
> > > > > actually need to author a substantial amount of content with
> > > > > xdoc
> > > > > or
> > > > > apt.
> > > > > 
> > > > 
> > > > Bah, it's just one format vs. another, it just depends on how
> > > > much
> > > > control
> > > > you want.
> > > > 
> > > > For
> > > > https://www.manning.com/books/java-persistence-with-hibernate-s
> > > > econ
> > > > d-edition,
> > > > we wrote it all in XHTML.
> > > > 
> > > > Gary
> > > > 
> > > > 
> > > > > 
> > > > > Oleg
> > > > > 
> > > > > ---
> > > > > 
> > > > > --
> > > > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > > > > For additional commands, e-mail: dev-h...@hc.apache.org
> > > > > 
> > > > > 
> > > 
> > > ---
> > > --
> > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > > For additional commands, e-mail: dev-h...@hc.apache.org
> > > 
> > 
> > -
> > 
> > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > For additional commands, e-mail: dev-h...@hc.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 

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

[jira] [Commented] (HTTPCLIENT-1901) Digest Auth Example Not Working with 4.5.4

2018-02-02 Thread David Schreibman (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350710#comment-16350710
 ] 

David Schreibman commented on HTTPCLIENT-1901:
--

[~olegk] Happy Friday. See attached.

> Digest Auth Example Not Working with 4.5.4
> --
>
> Key: HTTPCLIENT-1901
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1901
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: David Schreibman
>Priority: Major
> Attachments: log453.log, log455.log
>
>
> This example is not working as of 4.5.4
> [https://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java]
> I suspect it's due to
>  * [HTTPCLIENT-1855] Disabled caching of DIGEST auth scheme instances due to 
> unreliability of nonce counter
>  when the auth cache is shared by multiple sessions.
>  Contributed by Oleg Kalnichevski 
> Are you saying the example is no longer supported? If so, take it down.
> Can we have an example of non-preemptive digest auth?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (HTTPCLIENT-1901) Digest Auth Example Not Working with 4.5.4

2018-02-02 Thread David Schreibman (JIRA) 

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

David Schreibman updated HTTPCLIENT-1901:
-
Attachment: log455.log

> Digest Auth Example Not Working with 4.5.4
> --
>
> Key: HTTPCLIENT-1901
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1901
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: David Schreibman
>Priority: Major
> Attachments: log453.log, log455.log
>
>
> This example is not working as of 4.5.4
> [https://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java]
> I suspect it's due to
>  * [HTTPCLIENT-1855] Disabled caching of DIGEST auth scheme instances due to 
> unreliability of nonce counter
>  when the auth cache is shared by multiple sessions.
>  Contributed by Oleg Kalnichevski 
> Are you saying the example is no longer supported? If so, take it down.
> Can we have an example of non-preemptive digest auth?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (HTTPCLIENT-1901) Digest Auth Example Not Working with 4.5.4

2018-02-02 Thread David Schreibman (JIRA) 

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

David Schreibman updated HTTPCLIENT-1901:
-
Attachment: log453.log

> Digest Auth Example Not Working with 4.5.4
> --
>
> Key: HTTPCLIENT-1901
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1901
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: David Schreibman
>Priority: Major
> Attachments: log453.log, log455.log
>
>
> This example is not working as of 4.5.4
> [https://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java]
> I suspect it's due to
>  * [HTTPCLIENT-1855] Disabled caching of DIGEST auth scheme instances due to 
> unreliability of nonce counter
>  when the auth cache is shared by multiple sessions.
>  Contributed by Oleg Kalnichevski 
> Are you saying the example is no longer supported? If so, take it down.
> Can we have an example of non-preemptive digest auth?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-02 Thread sebb 
On 2 February 2018 at 13:33, Oleg Kalnichevski  wrote:
> On Wed, 2018-01-31 at 20:18 +, sebb wrote:
>> It may not be pretty, but I find it legible and generally easy to
>> navigate so I hope those attributes won't be lost.
>>
>> Also, it's important not to break any links.
>>
>
> It is also important to eat healthy, be polite and stay away from those
> girls.
>
> I am sorry, Sebastian, but links are likely to get broken and some

It's not necessary to change the site design.
Nor is it necessary to drop Maven.

I think links are a lot more more important than looks.

> Maven generated reports are not going to be there anymore. If some
> people feel strongly about it, they are welcome to help fixing them and
> provide missing content.
>
> Oleg
>
>
>> If the site is no longer built using Maven, then it may be difficult
>> to preserve all the links (e.g. project info page links).
>>
>> It appears to be possible to use Markdown with Maven:
>> https://stackoverflow.com/questions/14829190/how-to-use-markdown-for-
>> maven-project-site
>>
>> Ideally anchors (internal page links) will also be maintained as far
>> as possible.
>>
>> S.
>>
>> On 31 January 2018 at 19:15, Gary Gregory 
>> wrote:
>> > On Wed, Jan 31, 2018 at 7:57 AM, Oleg Kalnichevski > > g> wrote:
>> >
>> > > On Wed, 2018-01-31 at 07:43 -0700, Gary Gregory wrote:
>> > > > >
>> > >
>> > > ...
>> > >
>> > >
>> > > > On Wed, Jan 31, 2018 at 6:06 AM, Oleg Kalnichevski > > > > e.org>
>> > > > wrote:
>> > > >
>> > > > Granted the site is not the most attractive, the only time I
>> > > > want to
>> > > > dedicate to this topic is to discuss it here. I do not care
>> > > > about
>> > > > which
>> > > > tools we use to get us to a new site. For my money, I'd simply
>> > > > try to
>> > > > improved what we have now we a different stylesheet (Fluido?).
>> > > > For
>> > > > example,
>> > > > this is fine with me:
>> > > > https://logging.apache.org/log4j/2.x/manual/architecture.html
>> > > > and
>> > > > it's all
>> > > > Maven.
>> > > >
>> > >
>> > > I understand that but you opinion might rapidly change once you
>> > > actually need to author a substantial amount of content with xdoc
>> > > or
>> > > apt.
>> > >
>> >
>> > Bah, it's just one format vs. another, it just depends on how much
>> > control
>> > you want.
>> >
>> > For
>> > https://www.manning.com/books/java-persistence-with-hibernate-secon
>> > d-edition,
>> > we wrote it all in XHTML.
>> >
>> > Gary
>> >
>> >
>> > >
>> > > Oleg
>> > >
>> > > ---
>> > > --
>> > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> > > For additional commands, e-mail: dev-h...@hc.apache.org
>> > >
>> > >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
>> For additional commands, e-mail: dev-h...@hc.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>

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

[jira] [Commented] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350462#comment-16350462
 ] 

ASF subversion and git services commented on HTTPCORE-508:
--

Commit 7d47ad0d77439259a236e8d570b04b75eec00e00 in httpcomponents-core's branch 
refs/heads/4.4.x from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=7d47ad0 ]

HTTPCORE-508: Reject response messages with status code lesser than 100 as 
invalid


> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 4.4.9, 5.0-beta2
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

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

Oleg Kalnichevski resolved HTTPCORE-508.

Resolution: Fixed

Fixed in 4.4.x and master. Please review.

Oleg

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 4.4.9, 5.0-beta2
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread ASF subversion and git services (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350459#comment-16350459
 ] 

ASF subversion and git services commented on HTTPCORE-508:
--

Commit 5739fb646dd5634eb36b736683c9118c40a49b0f in httpcomponents-core's branch 
refs/heads/master from [~olegk]
[ https://git-wip-us.apache.org/repos/asf?p=httpcomponents-core.git;h=5739fb6 ]

HTTPCORE-508: Reject response messages with status code lesser than 100 as 
invalid


> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 4.4.9, 5.0-beta2
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [DISCUSS] Migrating project website content to markdown (2nd attempt)

2018-02-02 Thread Oleg Kalnichevski 
On Wed, 2018-01-31 at 20:18 +, sebb wrote:
> It may not be pretty, but I find it legible and generally easy to
> navigate so I hope those attributes won't be lost.
> 
> Also, it's important not to break any links.
> 

It is also important to eat healthy, be polite and stay away from those
girls.

I am sorry, Sebastian, but links are likely to get broken and some
Maven generated reports are not going to be there anymore. If some
people feel strongly about it, they are welcome to help fixing them and
provide missing content.

Oleg 


> If the site is no longer built using Maven, then it may be difficult
> to preserve all the links (e.g. project info page links).
> 
> It appears to be possible to use Markdown with Maven:
> https://stackoverflow.com/questions/14829190/how-to-use-markdown-for-
> maven-project-site
> 
> Ideally anchors (internal page links) will also be maintained as far
> as possible.
> 
> S.
> 
> On 31 January 2018 at 19:15, Gary Gregory 
> wrote:
> > On Wed, Jan 31, 2018 at 7:57 AM, Oleg Kalnichevski  > g> wrote:
> > 
> > > On Wed, 2018-01-31 at 07:43 -0700, Gary Gregory wrote:
> > > > > 
> > > 
> > > ...
> > > 
> > > 
> > > > On Wed, Jan 31, 2018 at 6:06 AM, Oleg Kalnichevski  > > > e.org>
> > > > wrote:
> > > > 
> > > > Granted the site is not the most attractive, the only time I
> > > > want to
> > > > dedicate to this topic is to discuss it here. I do not care
> > > > about
> > > > which
> > > > tools we use to get us to a new site. For my money, I'd simply
> > > > try to
> > > > improved what we have now we a different stylesheet (Fluido?).
> > > > For
> > > > example,
> > > > this is fine with me:
> > > > https://logging.apache.org/log4j/2.x/manual/architecture.html
> > > > and
> > > > it's all
> > > > Maven.
> > > > 
> > > 
> > > I understand that but you opinion might rapidly change once you
> > > actually need to author a substantial amount of content with xdoc
> > > or
> > > apt.
> > > 
> > 
> > Bah, it's just one format vs. another, it just depends on how much
> > control
> > you want.
> > 
> > For
> > https://www.manning.com/books/java-persistence-with-hibernate-secon
> > d-edition,
> > we wrote it all in XHTML.
> > 
> > Gary
> > 
> > 
> > > 
> > > Oleg
> > > 
> > > ---
> > > --
> > > To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> > > For additional commands, e-mail: dev-h...@hc.apache.org
> > > 
> > > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
> 

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

Re: Roadmap httpclient library

2018-02-02 Thread Oleg Kalnichevski 
On Fri, 2018-02-02 at 13:04 +0100, Alberto Requena wrote:
> Hi all,
> 
> We are intended to use the httpclient library in one of our projects,
> which
> needs to send HTTP/2 requests to Apple's APNs.
> 
> Is there a roadmap of the httpclient library somewhere, so that we
> can
> foresee and plan realistic estimations?
> 

Well, there is one but it has not been updated for months and is now
completely useless. 
https://wiki.apache.org/HttpComponents/HttpComponentsRoadmap

I'll remove it shortly.

HttpClient 5.0 is feature complete as far as I am concerned. I do not
intent to add any more features to it unless some people need something
really bad and are willing to contribute code or help testing. 

I have no intention of repeating the same mistake as with HC 4.0 GA
release. I would like to keep HC 5.0 BETA for a considerable period of
time.

5.0 Roadmap: long, long BETA testing phase.

Oleg


> Apologise in advance if this information's been already provided or
> if this
> is not the correct channel for such question.
> 
> Thank you in advance.

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

[jira] [Comment Edited] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350257#comment-16350257
 ] 

Oleg Kalnichevski edited comment on HTTPCORE-508 at 2/2/18 1:00 PM:


In 4.x one can plug-in a custom {{HttpMessageParser}} and rewrite the response 
message returned by the parser. It is not particularly elegant but will get the 
job done. For 5.x I am open to more elegant solutions (as long as they work 
with classic HTTP/1.1, async HTTP/1.1 and async HTTP/2.

Oleg

 


was (Author: olegk):
In 4.x one can plug-in a custom {{HttpMessageParser}} and rewrite the response 
message returned by the parser. It is not particularly elegant and will get the 
job done. For 5.x I am open to more elegant solutions (as long as they work 
with classic HTTP/1.1, async HTTP/1.1 and async HTTP/2.

Oleg  

 

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 4.4.9, 5.0-beta2
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCORE-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350257#comment-16350257
 ] 

Oleg Kalnichevski commented on HTTPCORE-508:


In 4.x one can plug-in a custom {{HttpMessageParser}} and rewrite the response 
message returned by the parser. It is not particularly elegant and will get the 
job done. For 5.x I am open to more elegant solutions (as long as they work 
with classic HTTP/1.1, async HTTP/1.1 and async HTTP/2.

Oleg  

 

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 4.4.9, 5.0-beta2
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Moved] (HTTPCORE-508) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

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

Oleg Kalnichevski moved HTTPCLIENT-1902 to HTTPCORE-508:


Fix Version/s: (was: 4.5.6)
   (was: 5.0 Beta2)
   (was: 4.6 Alpha1)
   5.0-beta3
   4.4.10
Affects Version/s: (was: 4.5.5)
   (was: 4.5.2)
   4.4.9
   5.0-beta2
  Component/s: (was: HttpClient (classic))
   HttpCore NIO
   HttpCore
 Workflow: classic default workflow  (was: Default workflow, 
editable Closed status)
  Key: HTTPCORE-508  (was: HTTPCLIENT-1902)
  Project: HttpComponents HttpCore  (was: HttpComponents HttpClient)

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCORE-508
> URL: https://issues.apache.org/jira/browse/HTTPCORE-508
> Project: HttpComponents HttpCore
>  Issue Type: Bug
>  Components: HttpCore, HttpCore NIO
>Affects Versions: 5.0-beta2, 4.4.9
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.4.10, 5.0-beta3
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (HTTPCLIENT-1902) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Petar Petrov (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350236#comment-16350236
 ] 

Petar Petrov commented on HTTPCLIENT-1902:
--

That sounds more than reasonable. Is there a way I can plug in my own 
implementation to handle this faulty behavior in a custom manner, so I can 
still process the request?

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCLIENT-1902
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1902
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 4.5.5
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.5.6, 4.6 Alpha1, 5.0 Beta2
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Roadmap httpclient library

2018-02-02 Thread Alberto Requena 
Hi all,

We are intended to use the httpclient library in one of our projects, which
needs to send HTTP/2 requests to Apple's APNs.

Is there a roadmap of the httpclient library somewhere, so that we can
foresee and plan realistic estimations?

Apologise in advance if this information's been already provided or if this
is not the correct channel for such question.

Thank you in advance.

[jira] [Commented] (HTTPCLIENT-1902) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350205#comment-16350205
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1902:
---

The easiest and possibly the most appropriate solution to this issue is 
rejecting any response with status code below 100 as invalid.

Oleg

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCLIENT-1902
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1902
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 4.5.5
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.5.6, 4.6 Alpha1, 5.0 Beta2
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (HTTPCLIENT-1902) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Petar Petrov (JIRA) 
Petar Petrov created HTTPCLIENT-1902:


 Summary: Handle "HTTP/1.1 000 status code 000" responses
 Key: HTTPCLIENT-1902
 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1902
 Project: HttpComponents HttpClient
  Issue Type: Bug
  Components: HttpClient (classic)
Affects Versions: 4.5.5, 4.5.2
Reporter: Petar Petrov
 Attachments: canResponseHaveABody.png, doReceiveResponse.png

Hi!

I have a very _funny_ behaviour where the HttpClient seems to wrongly interpret 
the body of an HTTP response as headers, the parsing of which eventually leads 
to a java.net.SocketTimeoutException. 

The underlying cause of this seems to be a a faulty server response, i.e.,
{noformat}
HTTP/1.1 000 status code 000{noformat}
Thank you Apple! /s

 

I have managed to trace the origin of the problem to the *method 
HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
considered as a valid status code.

!canResponseHaveABody.png!

!doReceiveResponse.png!

So what happens seems to be that the status line and headers get parsed. The 
000 is not considered valid and that ends the processing of the response. Then 
the rest of the response (the body) seems to go through the parsing procedure 
again in *DefaultHttpResponseParser#parseHead*. The body is of content type 
application/json. Eventually the following exceptions gets thrown after a while:
{code:java}
java.net.SocketTimeoutException: Read timed out

at java.net.SocketInputStream.socketRead0(Native Method)

at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)

at java.net.SocketInputStream.read(SocketInputStream.java:182)

at java.net.SocketInputStream.read(SocketInputStream.java:152)

at 
org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)

at 
org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)

at 
org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)

at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)

at 
org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)

at 
org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)

at 
org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)

at 
org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)

at 
org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)

at 
org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)

at 
org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)

at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)

at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)

at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)

at 
org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)

at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)

at 
org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
{code}
 

I'm not really familiar if 000 is even a valid return code. When querying the 
server with some other HTTP tools like Postman, I do get the json response with 
a status code 000.

Do you guys think this is something that can be fixed in HttpClient or at least 
handled by some sort of an error?

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (HTTPCLIENT-1902) Handle "HTTP/1.1 000 status code 000" responses

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

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

Oleg Kalnichevski reassigned HTTPCLIENT-1902:
-

 Assignee: Oleg Kalnichevski
Fix Version/s: 5.0 Beta2
   4.6 Alpha1
   4.5.6

> Handle "HTTP/1.1 000 status code 000" responses
> ---
>
> Key: HTTPCLIENT-1902
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1902
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>  Components: HttpClient (classic)
>Affects Versions: 4.5.2, 4.5.5
>Reporter: Petar Petrov
>Assignee: Oleg Kalnichevski
>Priority: Major
> Fix For: 4.5.6, 4.6 Alpha1, 5.0 Beta2
>
> Attachments: canResponseHaveABody.png, doReceiveResponse.png
>
>
> Hi!
> I have a very _funny_ behaviour where the HttpClient seems to wrongly 
> interpret the body of an HTTP response as headers, the parsing of which 
> eventually leads to a java.net.SocketTimeoutException. 
> The underlying cause of this seems to be a a faulty server response, i.e.,
> {noformat}
> HTTP/1.1 000 status code 000{noformat}
> Thank you Apple! /s
>  
> I have managed to trace the origin of the problem to the *method 
> HttpRequestExecutor#canResponseHaveBody* where, as expected, 000 is not 
> considered as a valid status code.
> !canResponseHaveABody.png!
> !doReceiveResponse.png!
> So what happens seems to be that the status line and headers get parsed. The 
> 000 is not considered valid and that ends the processing of the response. 
> Then the rest of the response (the body) seems to go through the parsing 
> procedure again in *DefaultHttpResponseParser#parseHead*. The body is of 
> content type application/json. Eventually the following exceptions gets 
> thrown after a while:
> {code:java}
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:127)
> at java.net.SocketInputStream.read(SocketInputStream.java:182)
> at java.net.SocketInputStream.read(SocketInputStream.java:152)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:137)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:153)
> at 
> org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:282)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:138)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:56)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:259)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:163)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:165)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:273)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:125)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:272)
> at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:185)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89)
> at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:111)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108)
> {code}
>  
> I'm not really familiar if 000 is even a valid return code. When querying the 
> server with some other HTTP tools like Postman, I do get the json response 
> with a status code 000.
> Do you guys think this is something that can be fixed in HttpClient or at 
> least handled by some sort of an error?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (HTTPCLIENT-1901) Digest Auth Example Not Working with 4.5.4

2018-02-02 Thread Oleg Kalnichevski (JIRA) 

[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1634#comment-1634
 ] 

Oleg Kalnichevski commented on HTTPCLIENT-1901:
---

@[~davidschreibman] Please produce logs of the two sessions: successful auth 
with HC 4.5.3 and unsuccessful with HC 4.5.5. Attach those to this ticket.

Oleg

> Digest Auth Example Not Working with 4.5.4
> --
>
> Key: HTTPCLIENT-1901
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1901
> Project: HttpComponents HttpClient
>  Issue Type: Bug
>Reporter: David Schreibman
>Priority: Major
>
> This example is not working as of 4.5.4
> [https://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientPreemptiveDigestAuthentication.java]
> I suspect it's due to
>  * [HTTPCLIENT-1855] Disabled caching of DIGEST auth scheme instances due to 
> unreliability of nonce counter
>  when the auth cache is shared by multiple sessions.
>  Contributed by Oleg Kalnichevski 
> Are you saying the example is no longer supported? If so, take it down.
> Can we have an example of non-preemptive digest auth?
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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