Re: Non-transitive dependency in version 4.5.8
Hi Azriel, I cannot reproduce your issue. I think this may be caused by some invalid files in your local maven repository or in a repository/mirror/proxy you are using. Could you try with maven central (remove any additional repository from your pom.xml and any mirror/proxy from your maven user settings, also remove the folder org/apache/httpcomponents from your local repository). If the issue persists let me know. On Tue, 14 May 2019 at 22:35, Azriel Berger -X (azberger - TRITON UK BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) wrote: > > We’ve used the Apache HttpClient using the maven-dependency: > > org.apache.httpcomponents > httpmime > 4.5.5 > > When I updated the version from 4.5.5 to 4.5.8 – I see failures in > compile-time: missing classes etc. > I corrected it to: > > org.apache.httpcomponents > httpmime > 4.5.8 > > > org.apache.httpcomponents > httpclient > 4.5.8 > > > org.apache.httpcomponents > httpcore > 4.4.11 > > Now it compiles successfully, but with these messages: > [WARNING] The POM for org.apache.httpcomponents:httpmime:jar:4.5.8 is > invalid, transitive dependencies (if any) will not be available, enable > debug logging for more details > [WARNING] The POM for org.apache.httpcomponents:httpclient:jar:4.5.8 is > invalid, transitive dependencies (if any) will not be available, enable > debug logging for more details > Can you fix it? > >
Re: What's the difference between commons-httpclient and org.apache.httpcomponents
Hi, commons-httpclient is an old version that is not maintained anymore. It is the ancestor of httpcomponents. More explanations here: http://hc.apache.org/httpclient-3.x/ 2015-07-07 12:24 GMT+02:00 bit1...@163.com : > Hi, httpclient users, > I have following maven dependencies, I would ask a question about the > difference between commons-httpclient and org.apache.httpcomponents. > Although they are both related with HttpClient, but it eems that they are > totally difference http client modules. > > Thanks. > > > > > commons-httpclient > commons-httpclient > 3.1 > > > org.apache.httpcomponents > httpclient > 4.3.6 > > > > > bit1...@163.com >
Re: Cookie rejected - Log noise
Yes, it is about cookies that you receive from the server you are calling using HttpClient. HttpClient is trying to handle the cookies sent by the server you are calling just like a regular browser would do. Logging configuration is described extensively here: https://hc.apache.org/httpcomponents-client-ga/logging.html It depends which logging library you are using on your project (commons-logging, log4j...). 2015-06-17 14:17 GMT+02:00 : > Hi Francois, > > It is receiving the cookies I think? I am not actively send any cookies > but the HttpClient might be doing it for me (in the background). > > How do I set the log configuration for ResponseProcessCookies? > > Regards > Johan > > > On 2015-06-17 11:59, Francois-Xavier Bonnet wrote: > > Hi Johan, > > This warning is logged by class > org.apache.http.client.protocol.ResponseProcessCookies. You just have to > set this category to ERROR level in the log configuration and you will not > get anymore warnings about invalid cookies. > But in the first place is it normal that your application is sending > invalid cookies? > > > 2015-06-17 11:30 GMT+02:00 Johan Hertz : > >> Hi, >> >> I get a lot of log noise in the form of cookie rejected messages (see >> below), can I disable this from being written to the log? >> >> Cookie rejected: "[version: 0][name: SessionStatId][value: **][domain: . >> priv.atos.fr][path: /][expiry: Thu Jun 15 11:23:17 CEST 2023]". Illegal >> domain attribute "someotheraddress.fr". Domain of origin: " >> someaddress.com" >> >> Regards >> Johan >> >> >> - >> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org >> For additional commands, e-mail: httpclient-users-h...@hc.apache.org >> >> > >
Re: Cookie rejected - Log noise
Hi Johan, This warning is logged by class org.apache.http.client.protocol.ResponseProcessCookies. You just have to set this category to ERROR level in the log configuration and you will not get anymore warnings about invalid cookies. But in the first place is it normal that your application is sending invalid cookies? 2015-06-17 11:30 GMT+02:00 Johan Hertz : > Hi, > > I get a lot of log noise in the form of cookie rejected messages (see > below), can I disable this from being written to the log? > > Cookie rejected: "[version: 0][name: SessionStatId][value: **][domain: . > priv.atos.fr][path: /][expiry: Thu Jun 15 11:23:17 CEST 2023]". Illegal > domain attribute "someotheraddress.fr". Domain of origin: "someaddress.com > " > > Regards > Johan > > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: How can I login into my wordpress site ?
Hi, It looks like WordPress is sending cookies that do not follow the specifications. We had an issue with EsiGate project (that also uses HttpClient): https://github.com/esigate/esigate/issues/22 I didn't have time to investigate yet. Could it be the same issue you have? Le 24 nov. 2014 18:55, "Avi Hayun" a écrit : > Hi, > > How can I login into my wordpress site using httpcomponents ? > > Here is my wordpress login page: > http://chaiware.org/wp-login.php > > > I tried using the "form based logon" example from here: > > https://hc.apache.org/httpcomponents-client-ga/httpclient/examples/org/apache/http/examples/client/ClientFormLogin.java > > > But it keeps returning with a 406 http error message. > > > > Any help will be appreciated, > Avi. >
Re: HttpClient and virtual hosts
Hi Oleg,
Thanks very much for your help. It works except the bug with the cache but
I found a workaround. I will try to fix it.
2013/12/23 Oleg Kalnichevski
> On Mon, 2013-12-23 at 10:21 +0100, Francois-Xavier Bonnet wrote:
> > Hi,
> >
> > I am trying to migrate to HttpClient 4.3 and I cannot find a way to do
> what
> > I used to do before with virtual hosts without using any deprecated api.
> > My goal is to be able to send a request to a server but using a "Host"
> > header with a different server name.
> >
> > I am using a HttpClient with cache and calling
> > method org.apache.http.client.HttpClient.execute(HttpHost, HttpRequest,
> > HttpContext)
> > I found 4 different places I can set a host:
> >
> >- as the first parameter of execute method
> >- in the URI of the request
>
> Hi Francois-Xavier
>
> The first parameter represents a physical connection point, that is, the
> opposite endpoint of the outgoing connection. The host of the request
> URI represents a 'virtual' address and can be just about anything the
> target server is willing to accept as a valid host. The latter will end
> up in the execution context as the target host attribute
>
> ---
> CloseableHttpClient client = HttpClients.createSystem();
> HttpHost target = new HttpHost("www.google.com");
> HttpGet get = new HttpGet("http://www.google.ru/";);
> client.execute(target, get);
> ---
>
> >- by calling
> >method
> org.apache.http.protocol.HttpCoreContext.setTargetHost(HttpHost)
>
> This should produce the same result as above
> ---
> CloseableHttpClient client = HttpClients.createSystem();
> HttpHost target = new HttpHost("www.google.com");
> HttpGet get = new HttpGet("/");
> HttpClientContext context = HttpClientContext.create();
> context.setTargetHost(new HttpHost("www.google.ru"));
> client.execute(target, get, context);
> ---
>
> >- by setting a Host header in the request
> >
>
> This is also valid but may produce side effects as HttpClient may be
> unable to match host specific details to the correct host.
>
> > I have tried to debug and it looks like when send a request, the
> > destination server is identified by using 1) the one ine the URI 2) the
> > first parameter of execute method if no host is set in the uri 3) the
> > targetHost in HttpContext. This host is then used to set targetHost is
> > HttpContext and to determine the HttpRoute to the destination.
> >
> > My problems:
> >
> >- the cookies domains are matched against the targetHost (not the Host
> >header) so the cookies are rejected
>
> As I said if one manually overrides the 'Host' header in the outgoing
> request this indeed can happen. In the normal course of request
> execution the 'Host' header is generated based on the target host
> attribute and cookie domain of origin should be correctly matched.
>
> >- the cache key uses the host name in the HttpRoute which is also the
> >targetHost so the cache entries for different virtual hosts on the
> same
> >server are going to be mixed
> >
>
> This sounds like a bug and should be fixed.
>
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
HttpClient and virtual hosts
Hi, I am trying to migrate to HttpClient 4.3 and I cannot find a way to do what I used to do before with virtual hosts without using any deprecated api. My goal is to be able to send a request to a server but using a "Host" header with a different server name. I am using a HttpClient with cache and calling method org.apache.http.client.HttpClient.execute(HttpHost, HttpRequest, HttpContext) I found 4 different places I can set a host: - as the first parameter of execute method - in the URI of the request - by calling method org.apache.http.protocol.HttpCoreContext.setTargetHost(HttpHost) - by setting a Host header in the request I have tried to debug and it looks like when send a request, the destination server is identified by using 1) the one ine the URI 2) the first parameter of execute method if no host is set in the uri 3) the targetHost in HttpContext. This host is then used to set targetHost is HttpContext and to determine the HttpRoute to the destination. My problems: - the cookies domains are matched against the targetHost (not the Host header) so the cookies are rejected - the cache key uses the host name in the HttpRoute which is also the targetHost so the cache entries for different virtual hosts on the same server are going to be mixed Did I miss something?
Re: [POLL] Minimal JRE level as of HttpClient 4.4
--- [ ] keep Java 1.5 compatibility: no good reason to upgrade. [ ] upgrade to Java 1.6: one step at a time. [X ] upgrade to Java 1.7: new features are more important. --- 2013/9/16 Kimpton, C (Chris) > --- > [ ] keep Java 1.5 compatibility: no good reason to upgrade. > [ ] upgrade to Java 1.6: one step at a time. > [X] upgrade to Java 1.7: new features are more important. > --- > > > Thanks. > > _ > > This email (including any attachments to it) is confidential, legally > privileged, subject to copyright and is sent for the personal attention of > the intended recipient only. If you have received this email in error, > please advise us immediately and delete it. You are notified that > disclosing, copying, distributing or taking any action in reliance on the > contents of this information is strictly prohibited. Although we have taken > reasonable precautions to ensure no viruses are present in this email, we > cannot accept responsibility for any loss or damage arising from the > viruses in this email or attachments. We exclude any liability for the > content of this email, or for the consequences of any actions taken on the > basis of the information provided in this email or its attachments, unless > that information is subsequently confirmed in writing. > _ > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: Http Client - multiple instances question
Hi Brian, There is no underlying statically defined pool. If you are using the same http client instance for 2 separate servers, you can define independently the number or connections to keep in the pool for each server as explained here: http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html#d5e627 So there is no need to use 2 seperate http client instances. 2013/6/19 Brian > Hi All, > > I have a question about Apache Http Client use in J2EE application. > > I am working on a legacy app which connects to two different http servers > and it currently uses Multi Threaded Connection Manager backed, singleton > instance of Http Client declared statically to manage http requests to both > http servers. The transactional load between the two varies significantly, > so we are noticing that multithreaded http connection manager gets into a > waiting state under load, as all connections are in use. > > My question - is it a good design decision to create separate Http Client > object instance for each underlying http server, so that connection pool > sizes can be tuned independently of one another and transactions impacts > isolated, so that if the load towards one server increases the transactions > towards the other are not negatively impacted from http connection point of > view? I have read the docs on multi threading, and in the docs there is a > recommendation on using a single Http Client per application, thus my > question. > > I also just want to ensure that the API does not have statically defined > common underlying connection pool management code, which might cause > performance bottlenecks if multiple instances of Http Client are used. > > > > Thanks > > > > Brian > > > - > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org > For additional commands, e-mail: httpclient-users-h...@hc.apache.org > >
Re: default to cached response on error?
Yes, CachingHttpClient supports this. You can add the header in the request and CachingHttpClient will send the cached version instead of the error page even if the cache entry is stale. For example: Cache-Control: stale-if-error=1200 But the resource must be cacheable in the first place. In addition the resource must also be revalidatable (Last-modified or Etag response header in the response) in current version. 2013/6/7 > No, thanks for the pointer. Does CachingHttpClient support that? > > > On Fri, Jun 7, 2013 at 8:38 AM, Francois-Xavier Bonnet < > francois-xavier.bon...@centraliens.net> wrote: > >> Hello, >> >> Did you try stale-if-error request header ? >> >> >> 2013/6/7 Sam Perman >> >>> Hello >>> >>> I'm using the CachingHttpClient and have configured a retry handler for >>> certain types of errors... but what I really want to do is use a >>> previously >>> cached response (for certain types of errors) and only retry if there is >>> no >>> previously cached response. >>> >>> Is this possible? >>> >>> thanks >>> sam >>> >> >> >
Re: default to cached response on error?
Hello, Did you try stale-if-error request header ? 2013/6/7 Sam Perman > Hello > > I'm using the CachingHttpClient and have configured a retry handler for > certain types of errors... but what I really want to do is use a previously > cached response (for certain types of errors) and only retry if there is no > previously cached response. > > Is this possible? > > thanks > sam >
Re: valid HTTP request
Hi, You should fix the client that sends this request. An incorrect content-length header value makes it impossible to reuse http connections and can lead to locked connections and timeouts for example. In your case, I think disabling connection keep-alive could be a quick fix but this is not very good for performance. 2013/4/23 Nir Dweck > Hi, > I have a question which involves both the code and the validity of an HTTP > message. > I am using httpcore-4.2.3. > I receive from a client an HTTP (HTTP/1.1) request with the following > headers: > Content-type: text/xml > Host: some host > User-agent: UA > Connection: keep-alive > Accept: text/xml > Content-Length: 109 > > The entity is a an xml of of length of 109 bytes. > At the end of the xml there are two extra bytes with the value of 0x0d and > 0xoa (/r/n), these bytes are the 110'th and 111'th bytes. > In my code I call: *EntityUtils.toString(entity, "UTF-8");* > at the end of the handling of the request my server returns 200-OK to the > client. > the problem is that after I finish handling the request, the connection is > still open and I call *httpService.handleRequest(conn, context);* > This call sees the two extra bytes and returns 400-Bad request to the > sender. > Now my question are: > >1. As far as I know when the Content-Length header is present >it determines the length of the entity body, so actually the message I > get >is a bad message. >2. Is there something I can do in my code to make it accept this >message? Will calling *EntityUtils.consume(entity)* help? > > Thanks, > Nir >
Re: reconfiguring a running HttpClient instance
No, you cannot reconfigure an existing instance. An HttpClient is now an immutable object. If you need to change some settings, you have to create a new HtpClient. 2013/4/5 Simone Tripodi > Hi all again mates, > > sorry for the beginner's question, but I am now in the middle of the need > of reconfiguring a running instance of the HttpClient - is there any way, > without using the deprecated methods, to reconfigure some parameters, such > us the proxy and so on? > > Many thanks in advance, all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ >
Re: Correct way to retrieve the associated ClientConnectionManager from a HttpClient instance
Hi Simone, I guess you are using a CloseableHttpClient. Then to shutdown properly the ConnectionManager, you just have to call .close() method. FX 2013/4/5 Simone Tripodi > Hi all mates! > > I am working in a scenario where I have HttpClient instances in a registry; > when the application shuts down, I would like to shutdown the associated > ClientConnectionManager, but I see that since 4.3 version, HttpClient# > getConnectionManager() is a deprecated method. > > Can you suggest me please what is the correct way to retrieve the > associated ClientConnectionManager from a HttpClient instance? > > Many thanks in advance, all the best! > -Simo > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ >
Re: Usage of HTTP client and core
Hi, HttpComponents-client has been developed and tested using HttpComponents-core 4.2.2 This explains why this version is included in the bundle. HttpComponents-core 4.2.3 is binary compatible with all HttpComponents-core 4.2.x versions so you should be able to use it in your project as well. HttpComponents-core 4.2.3 is maintenance release version that fixes a few bugs from previous version. You will find more details in the release notes: http://www.apache.org/dist/httpcomponents/httpcore/RELEASE_NOTES.txt 2013/3/15 nagarjuna surabhatina > Hi, > > We have downloaded the http component client 4.2.3 bin version. This > version contains http core 4.2.2 in lib directory. Is client bundle with > older version of http core? > > Can I use http component client 4.2.3 and http component core 4.2.3 in my > application? > -- > Thanks and Regards > Nagarjuna.S >
RE: POST redirection question
Hello Francois,
Browsers do not respect much this part of the specifications. I remember I
made some comprehensive tests (but this was a few years ago) and most
browsers were changing POST to GET.
Le 6 févr. 2013 09:15, "COURTAULT Francois"
a écrit :
> Hello Oleg,
>
> First, thanks a lot for you answer.
> Is it written in the rfc 2626 spec because I have not seen it :-(
>
> I have only seen at 10.3.2:
> If the 301 status code is received in response to a request other
> than GET or HEAD, the user agent MUST NOT automatically redirect
> the
> request unless it can be confirmed by the user, since this might
> change the conditions under which the request was issued.
>
> Note: When automatically redirecting a POST request after
> receiving a 301 status code, some existing HTTP/1.0 user agents
> will erroneously change it into a GET request.
>
> So my understanding is that the default behavior for HTTP/1.1 user agent
> is to not change the HTTP request (eg keep the POST request).
> Am I wrong ?
>
> But maybe the first paragraph prevails meaning that for 301 user agent
> automatic redirection is not allowed: right ?
>
> Best Regards.
>
> -Original Message-
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: mardi 5 février 2013 23:31
> To: HttpClient User Discussion
> Subject: Re: POST redirection question
>
> On Tue, 2013-02-05 at 18:53 +0100, COURTAULT Francois wrote:
> > Hello everyone,
> >
> > At the beginning, I had something like that :
> > HttpClient httpClient = new DefaultHttpClient(); HttpPost httpPost =
> > new HttpPost(SOME_URL); HttpResponse postResponse =
> > httpClient.execute(httpPost);
> >
> > It turns out that I got a 301 Moved permanently.
> >
> > So I made the following modifications, either:
> > - httpClient.setRedirectStrategy(new LaxRedirectStrategy());
> > - or httpClient.setRedirectStrategy(new DefaultRedirectStrategy());
> > - or httpClient.setRedirectStrategy(new
> DefaultRedirectStrategy() {
> > @Override
> > public boolean isRedirected(HttpRequest request,
> HttpResponse response, HttpContext context) {
> > boolean isRedirected = false;
> > try {
> > isRedirected = super.isRedirected(request,
> response, context);
> > } catch (ProtocolException e) {
> > fail("Unable to set a redirect strategy,
> reason: " + e.getMessage());
> > }
> >
> > if (!isRedirected) {
> > int responseCode =
> response.getStatusLine().getStatusCode();
> > if (responseCode == 301 || responseCode ==
> 302) {
> > return true;
> > }
> > }
> > return false;
> > }
> > });
> > - or the same than above with new LaxRedirectStrategy
> >
> > Each time, after receiving a 301, the client sent a GET request instead
> of my initial HTTP request, which is a POST one as you can see, to the new
> location.
> > Any advice ? sample ?
> > Or is it an issue ?
> >
> > Best Regards.
>
> Only in case of a TEMPORARY_REDIRECT it is valid to redirect the request
> without changing its method. In all other cases methods other than HEAD and
> GET get converted to GET. To change this behavior you need to override
> #getRedirect method
>
>
> http://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/impl/client/DefaultRedirectStrategy.html#213
>
> Oleg
>
>
> > -
> > To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> > For additional commands, e-mail: httpclient-users-h...@hc.apache.org
> >
>
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
> -
> To unsubscribe, e-mail: httpclient-users-unsubscr...@hc.apache.org
> For additional commands, e-mail: httpclient-users-h...@hc.apache.org
>
>
