Hi Eric,
This isn't really something that should be included directly into
HttpClient as HttpClient isn't intended to care about the actual
content it sends and receives but just takes care of the actual HTTP
protocol side of things. Adding auto-mime type detection would mean
we'd also hav
Hey,
This is a patch which will determine the content type if null based on
file extension. I used the file extension mapping from
$TOMCAT_HOME/conf/web.xml. As a side note, I'm having trouble sending gif
files. Any thoughts or a kick in the right direction would be helpful.
Thanks and Hope It
Hi
I've got a suggestion (or a question) about the setRequestBody on the Method
objects. (using HTTP Client 2.0 beta)
There are three versions:
one that takes a String, one that takes an InputStream, and one that
takes a NameValuePair[].
Why isn't there a setRequestBody that takes a byte[] ?
I nee
Ron (I apologise for misspelling your name in my previous post),
You can easily subclass any of the CookieSpec classes. The trouble is
there's no way to plug a custom cookie spec into the existing
implementation of HttpClient. At the moment you have to modify
CookiePolicy class and recompile Httpc
Rob,
This is a well known issue. According to the RFC 2109 comma is
considered a spacial character. Cookie values that contain special
characters MUST be in a quoted string. Please refer to the following bug
report for more details:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11240
The cook
Brett,
I didn't download the source, just the jar and the docs. Could I subclass
from a CookieSpec and just replace the parse of Set-Cookie? I would prefer
to not have to modify the source so I can easily replace it with upcoming
versions without having to put my change back in.
Is your fix going
I have a fix for this but it uses the org.apache.oro regular
expression parser.
E-mail me off line if you want the code to hack your own copy of
HttpClient
- Original Message -
From: "Ron Tower" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 18, 2003 9:26 AM
Subject: Co
Eric,
I think you're roughly agreeing with what I would conclude, but I wasn't
sure and I wanted to get other's feedback.
Yes, I think your analysis was correct.
Unfortunately, I am not directly responsible for the design and
implementation of the product, and we're not focusing resources
else
Karaoke at Ortwin's house tonight :)
Mike
Ortwin Glück wrote:
Michael Becke wrote:
We allow a 0 timeout indicating an infinite wait. This is in fact the
default.
Makes me think of Queen's song "who wants to live forever" :-)
--
Mike,
I think you're roughly agreeing with what I would conclude, but I wasn't
sure and I wanted to get other's feedback.
Michael Becke wrote:
Doing something time-consuming from the event thread is a little
questionable I think. It's an easy way to keep a user from using the
UI but it cause
Hello All,
Is there a problem when a comma appears in a cookie value? See 02109POS below. It has
a comma in the value and is split into two cookies. IE at least parses this cookie as
one cookie. Is there a workaround for this?
My understanding is that a cookie value can have any character othe
I think invoking HttpClient from the AWT event thread is key, as it
prevents further interaction by the user with the application, and thus
the garbage collector never gets invoked. Based on this theory, it
turns out that I can work around the bug in my code by putting in a call
to System.gc()
Michael Becke wrote:
We allow a 0 timeout indicating an infinite wait. This is in fact the
default.
Makes me think of Queen's song "who wants to live forever" :-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
Ortwin,
It is an odd problem. Not quite a dead-lock in the traditional sense.
One thread is waiting on the other, and the other is waiting for the
garbage collector. It just so happens that the garbage collector will
never kick in, because the first thread happens to be the AWT Event
thread
It's not clear to me how this can be a dead lock.
I'm not sure of the exact definition of deadlock but I think it requires
two threads to be waiting for each other. This is not what's happening
in this case. The problem is that the thread is waiting and noone is
going to wake it up.
Eric John
It's not clear to me how this can be a dead lock.
Eric Johnson wrote:
MultiThreadedHttpConnectionManager.doGetConnection() - line 302, which
reads "connectionPool.wait(timeToWait)",
This is a limited wait. Not infinite. Oleg, do we ensure that
timeToWait>0 somehow?
and the other thread at
Mult
OK, so I brought this problem upon myself.
There is one executeMethod() call in one of our applications for which
we "forgot" to call releaseConnection() or consume the entire response
(and I of all people should know better). While I fully realize this is
a bug in my code, the failure, unfort
17 matches
Mail list logo
