You should attempt to write a small Java program that just has [new
Socket(server.name.com, 80);] and run it on the same
machine/environment as you are running HttpClient. That socket
connect should fail based on the exception you reported here. When
you can debug that problem and solve it, HttpC
ser.
> It is possible to instruct http client to connect directly to the public
> url? Or there is an workaround this issue?
>
> Thank you,
> Razvan
> -Original Message-
> From: Sam Berlin [mailto:sber...@gmail.com]
>
> The issue appears more related to opening a TCP
The issue appears more related to opening a TCP socket to the host,
long before the GET request for a specific URL is sent. The
java.net.ConnectException is telling you that you can't even open a
socket. Are you running curl, wget or the browser from the same
machine that your application is runn
Although I can't explain the truncation, there is a clear bug in the code.
When doing a read from an InputStream, it's not guaranteed to fill in the
entire buffer. You're appending a String built from the entire buffer, not
the amount of bytes that were read into the buffer. Also, the code is
ign
Your best bet to figure out what your browser is sending/receiving is using
a tool like Wireshark.
Sam
On Wed, Sep 9, 2009 at 8:35 AM, caymanag wrote:
>
> Ok, I agree that there is apparently no content to read. When a web
> browser
> sees the Content-disposition: attachment; filename="myfile
>
>
>
>
>
>
>
> From: Oleg Kalnichevski [mailto:ol...@apache.org]
> Sent: Wed 4/22/2009 6:01 AM
> To: HttpClient User Discussion
> Subject: Re: Weird problems with httpclient 4.0beta2 and httpcore 4.0
>
>
>
> On Tue, Apr
>
>
> Is using a ResponseHandler the reason why the HttpEntity response is
> consumed eagerly in DefaultHttpClient?
Yes. I haven't used ResponseHandler's myself, but what I remember from
their introduction is that the concept is that a ResponseHandler takes an
HttpResponse and converts it to an
with my
> application code? In that case, with the Location header be present in the
> HttpResponse?
>
> Thanks,
> Brijesh
>
>
> -Original Message-
> From: Sam Berlin [mailto:sber...@gmail.com]
> Sent: Wednesday, March 25, 2009 7:06 PM
> To: HttpClient Us
I don't believe anything is wrong here, Brijesh. HttpClient 4 is
automatically doing the redirects for you. A 200 status code and a
successful login is the ultimate goal, right? Is there something else
you need from the intermediary redirect request/response? If so, you
can use setRedirectHandle
It might help with debugging arbitrary NonRepeatableRequestExceptions
if it somehow captured the original exception that triggered the retry
and added it to the cause. Think this has any merit (or is it even
possible with the current code structure)?
Sam
On Tue, Mar 24, 2009 at 9:37 AM, Oleg Kal
Excellent point, Oleg. You do such an excellent job with HttpClient
that we're all spoiled and expect more. :)
Sam
On Mon, Oct 20, 2008 at 1:02 PM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-10-19 at 18:34 -0400, Sam Berlin wrote:
>> It might be interes
It might be interesting to have a small httpcomponents side project,
"HttpClient Extensions" that enable these small-but-useful features by
default. That way HttpClient can remain small, tidy and content
agnostic, while folks wanting a out-of-the-box solution can
additionally get the extensions.
The difference, Uday, is that HttpClient supports it internally. You
don't have to do anything to make it work. Just do a normal PUT
request with a body (and specify to use EXPECT_CONTINUE, as David
shows), and HttpClient will automagically make it work. I think
you're trying to do it yourself,
> So how else to do a retrieval?
If you are asking how to do this in code -- I mentioned earlier on in
the thread, it's a very trivial thing to add. Simply make a new class
that extends HttpGet and implements HttpEntityEnclosingRequest (with a
name such as HttpEntityEnclosingGet), or extend
HttpE
Hi David,
The fortunate thing about HttpClient 4.0's design is that it's very
easy to do this kind of thing yourself. For this, it's as easy as
making a new class called HttpEntityEnclosingGet that implements
HttpEntityEnclosingRequest.
Sam
On Wed, Jun 18, 2008 at 8:19 PM, David Gallardo <[EMAI
The internal connection manager, in a nutshell, is there to reduce the
amount of times new connections have to be created & prevent a server
from being overloaded with too many connections. It exposes a lot of
bells & whistles (and HttpClient makes use of them) so that a single
connection can be '
s/patch/path
On Wed, Jun 4, 2008 at 10:02 AM, Sam Berlin <[EMAIL PROTECTED]> wrote:
> Not sure if anyone has pointed out that:
>
> logj4.logger.org.apache.commons.httpclient=DEBUG, httc
>
> ...is not the correct patch for httpclient 4.0.
>
> Sam
>
> On Wed, Jun
Not sure if anyone has pointed out that:
logj4.logger.org.apache.commons.httpclient=DEBUG, httc
...is not the correct patch for httpclient 4.0.
Sam
On Wed, Jun 4, 2008 at 8:42 AM, Steven Adams <[EMAIL PROTECTED]> wrote:
> It's picking up the log4j properties files. As I make changes to the
> p
---
[X] keep Commons logging
[ ] migrate to SLF4J
[ ] migrate to java.util.logging
---
Depending on the timeframe, I think this means httpcore has to have a
beta2 sooner, too. (Can a release of httpclient rely on a snapshot of
httpcore?)
Sam
On Sat, May 24, 2008 at 7:03 AM, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> Folks
>
> The redesign of HttpClient is now complete. All kno
Hi jeffty,
HttpCore is like the nuts and bolts -- it's the individual pieces you
need to build something. HttpClient is the additional stuff that
brings the nuts & bolts together into an easy-to-use http client.
That is, httpcore can do all the things that httpclient does -- but it
needs some exp
I prefer wget. :-)
On 5/19/08, Oleg Kalnichevski <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > We may also need C++ version of HttpClient or equivalent. Is there C++
> > of HTTPClient available? Or Does anyone know other opensource?
> >
> >
>
> http://curl.haxx.se/libcurl/
HttpClient 4.0 is redesigned such that there is no longer a global
static Protocol registry (among many other nice redesigns). If
possible, I suggest migrating to 4.0.
Alternately, if you must stick with 3.0, you can try to manually
modify the calls to executeMethod so that the URIs have the prot
oad.http.HttpDownload$HttpDownloader.initializeDownloader(HttpDownload.java:428)
>at
> org.downman.download.http.HttpDownload$HttpDownloader.run(HttpDownload.java:543)
> at java.lang.Thread.run(Thread.java:619)
>
> It seems the exception still occures...
>
> 2008/4/18, Sam B
lding maven projects...
>
> I forget to say that i'm working with 4.0, not that we missunderstand :)
>
> 2008/4/18, Sam Berlin <[EMAIL PROTECTED]>:
> > This is likely due to a problem with the last alpha release of
> > HttpClient. Aborted connections weren't
This is likely due to a problem with the last alpha release of
HttpClient. Aborted connections weren't properly released back to
connection managers. It's been fixed, but I'm not sure a new release
was issued.
Is it possible to try building httpclient from source and see if the
problem still occ
> > I think i read somewhere that the connection is returned back to the pool
> > when the input stream is closed. Now if the server is down, i dont get a
> > response input stream, so does the httpget.abort release the connection
> > back to the pool?
>
> Yes, it does.
I think this was a bug i
Could you create a custom InputStream that took the header & response
inputstream in its constructor, and returned one and then the other
when reading?
Sam
On 2/29/08, ripok <[EMAIL PROTECTED]> wrote:
>
> I have a little problemo: I'm making HTTP request to a server that gives me
> back a kind of
28 matches
Mail list logo
