[EMAIL PROTECTED] wrote:
Oleg,
I agree, our lack of auth/proxy tests is a continuous source of problems. One of our goals for 2.1
should be an effective method for testing all of the various combinations of proxy, authentication
and SSL. Ideally it would be best to make this setup as simple
Hi,
If i send the right accept-encoding headers, the web-server may answer
with a gzip or deflate compressed stream. Does HttpClient decompress it?
If yes, how can i turn that off?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
Sven Köhler wrote:
If i send the right accept-encoding headers, the web-server may answer
with a gzip or deflate compressed stream. Does HttpClient decompress it?
No, it doesn't.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
My take is slightly different (and I wish I had time to implement it)
Start by virtualizing the access to the connection, and then, rather
than having multiple servers, just have different implementations of a
virtualized socket interface, for example. Then see to writing test
cases that
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-11-17 14:38 ---
Odi,
agreed - whitespace is a wrong term. CRLF is better. CRLF or LF is correct ;-)
(see RFC2616, section 19.3).
Would you then prefer my first version of the patch, or do you have another idea
Eric Johnson wrote:
My take is slightly different (and I wish I had time to implement it)
Start by virtualizing the access to the connection, and then, rather
than having multiple servers, just have different implementations of a
virtualized socket interface, for example.
Eric, we can
It'd be rather easy to wrap the streams in a DeflaterOutputStream or an
InflaterInputStream. Of course, due to limitations in Java's deflate
compression, one must extend DeflaterOutputStream to allow true stream
deflation. The problem with the current implementation is that there is
no way
Hi Mike,
Using a listener seems like an interesting idea, although I don't quite
see the rationale behind it. MTCM (well, CM's in general really) seem
to be designed specifiically for this purpose: to manage http
connections. Having an observable interface to HttpConnection would
require
Odi,
That would be REALLY cool! A simple authenticating proxy (or a proxy
that could effectively 'fake' popular authentication schemes) would be a
very much appreciated contribution. By the way, have a look at the
Christian Kohlschütter's SimpleHttpServer:
Christian, see my comments in-line
In my opinion, strict mode should be very pedantic about standards compliance.
HttpClient should notify the user wherever a problematic, non-standards
situation is detected.
I do not mind being over-pedantic, but not at the expense of code
quality. My
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24671.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
Odi, Eric,
I think a combination of these techniques would be great. One level to
handle the socket management(as Odi outlined) and another to handle the
content creation/validation (Eric's idea). These two methods in tandem
should be sufficient to mimic any combination of
I have not found any mentioning of unexpected content in the RFC, so
this is another reason why I would be a bit cautious about throwing a
protocol exception. It would suffice to spit out a warning, drop the
connection and move on.
Folks, any strong options on this issue
I would prefer a warning
Hi Sam,
My thought, probably not well articulated, was to add the ability to
observe and interact with the status of HttpConnections. This would
allow for classes other that the connection managers to play a hand in
the connection management. Another possibility would be to have a
15 matches
Mail list logo
