Mike Moran wrote:
Ah, yes, that is a point. I suspect JNDI will be rather too much
overhead for a simple host lookup, but it's worth a look. Async lookups
may also still be impossible.
I don't see much overhead. The only expensive call is the service
lookup. After that the performance fully
[EMAIL PROTECTED] wrote:
RFC 2616 does not seem to say much. So, I assume that the default
scheme applies: whatever charset is specified in Content-Type
header. If charset is not explicitly set, ISO-8859-1 is used per
default.
I guess this is the way to go for POST. But what about GET? There is
Alan Marcinkowski wrote:
I found HttpMethodBase:checkValidRedirect was not honoring
cross server redirects. Isn't this a common type of redirect? Is there
a reason its not supported? [...] unless its an architectural issue [...]
Alan,
unfortunately that is an architectural issue currently.
Sung-Gu wrote:
I don't think it's not mature... :(
They have couple of issues still, as I know.. just not revealed yet.
At least they have reached Alpha status! This is more than enough for a
real commons sub-project outside the sandbox.
Sung-Gu wrote:
There isn't any uni-one to support the various charsets.(Let you regard it!)
Then, once it was tranformed, it should be tranformed back to the original.
That makes the transformed one to the original one.
Sung-Gu,
I have problems understanding your English and I can only guess
Sung-Gu wrote:
- Original Message -
From: Ortwin Glück [EMAIL PROTECTED]
Arrrg... again... :(
Not surprising though... :(((
Sung-Gu, I don't want to upset you. I just want to understand the
problem that you are trying to solve with toUsingCharset. Your
explanations did not help so
Thanks Laura for this excellent explanation. This really helps to clear
things up! I am glad to have you and your indepth Unicode knowledge on
the list.
I always thought you could roundtrip any charset to Unicode and get the
same thing back. This is obviously wrong. It should be easy to write
Jim Crossley wrote:
I'm on Linux, but I'm not at all familiar with packet sniffing tools,
and I don't really have the time to learn before tomorrow, after which
access to the IIS server will be gone. If someone would kindly post
some commands/options for getting Oleg's data, I'll be happy to try
If a Transfer-Encoding: chunked header is present, the body must at
least contain the last chunk, which is:
0CRLF
CRLF
Without the last chunk beeing present we can not detect if there is a
body at all! The last chunk not beeing present violates the RFC:
last-chunk has no asterix in front of
Jeffrey Dever wrote:
I'd like to propose an alpha3 build.
+1
This is excellent. There have been many bug fixes gone into CVS since
the alpha2. People helping in testing will like the new release.
Odi
-
To unsubscribe,
Daniel Walsh wrote:
I was under the impression, though, that the implementation that you spoke
of would require an HTML form, or some other type of UI - which my
application does not use. Is that not true?
No of course not. HttpClient provides all you need to tailor an
appropriate POST
Max Voelkel wrote:
- a Cache (mentioned a while ago on the list)
- Proxy-Detection
okay
- Some kind of User-Agent on top of HttpClient which:
- handles Framesets (return urls of subframes)
- possibly parses FORM-Tags
- eventually handles JavaScript-Code and
return
+1
I do fully support Jeff's words!
Ortwin Glück
Jeffrey Dever wrote:
Mike Becke has been an active contributor for many months. He has
worked on a diverse range of problems with high quality results. He has
been consistant, reliable, helpful and open to ideas and criticism
+1
Very much appreciated.
Oleg Kalnichevski wrote:
Something like root/src/contrib, which
would contain a package named org.apache.commons.httpclient.contrib or
something similar. This package would not be officially maintained. It
would not be included into neither BIN nor SRC distribution,
Eric E Johnson wrote:
As for why these functions exist, I keep thinking along these lines -
imagine you want to encode foreign language characters in a URL. The
way to do it is to convert your string into bytes, and then URL encode
the bytes as if it were ASCII. Reversing the process, take
[EMAIL PROTECTED] wrote:
Actually, any sane cgi script or servlet *should* ignore
Content-Length when parsing multipart/form-data request body.
I don't agree. You are mixing protocol and data.
Content-Length is a HTTP protocol element whereas multipart MIME is a
content format.
Oleg Kalnichevski wrote:
Mike, certain things in this life cannot be delayed. That includes
patches for rapidly evolving software artifacts in my opinion ;-)
Oleg
I can understand that opinion. On the other hand I think that we should
not loose application developers by changing
Jandalf wrote:
Odi's suggestion of starting a 2.1 branch now is a reasonable one.
Just to make one thing clear. It is a 2.0 branch and not a 2.1 branch I
am talking about:
+-- 2.0 Final
| ¦
CVS
Okay, if I include non-office hours:
9-17h and 20h-23h (which is 10-18h, 21h-24h MET=GMT+1)
Ortwin Glück wrote:
9-16h GMT (which is 10-17h MET=GMT+1)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
[EMAIL PROTECTED] wrote:
waitForResponse should not block infinitely. It should be able to timeout after
given number of ms if no response is forthcoming. If you see a more elegant Java
1.2.2 compatible solution, please advise us
Oleg
There is Object.wait(long) and Object.notify and
Oleg Kalnichevski wrote:
Odi, are you sure you want to have an extra thread per HttpMethod? I do
not think so
Oleg
Better than a busy wait, isn't it?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Agreed
(for once)
:-)
Oleg Kalnichevski wrote:
Laura
CPU-bound polling is needed only under fairly unusual circumstances. I
do think that any sort of thread based solution would be an overkill. I
did my best to explain the rationale for not using threads in the bug
report
Cheers
Oleg
wow! I'm deeply impressed.
Odi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Drake Henderson wrote:
I turned on logging. Looks like I am going to port 80. The url I am using
is for a different port: www.XXX.com: I assumed that the system would
pick the port out of the url.
I don't think so.
-
To
Jeffrey Dever wrote:
I'd say that a post redirect converted to a get is good behaviour to add
as part of the redirect overhaul as discussed for httpclient 3.0
The problem of this scenario is:
- you tell HttpClient to execute a POST
- it is redirected and executes a GET automatically
- but the
FAQ is good. Improving the API Doc in the spots Om pointed out is even
better.
Odi
Oleg Kalnichevski wrote:
Mike,
Why do not we indeed make a FAQ document out of this Q A session with?
Oleg
-
To unsubscribe, e-mail:
Manuel Castro Paliza wrote:
So finally the cuestion is :
is a Pool of Methods also a High-Level pool of Connections when not using
MultiThreadedHttpConnectionManager ?
No. A method requests a connection from the connection manager on
demand. There is no fix association between a method and a
Sunil,
a wirelog would be a lot more interesting.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Adrian Sutton wrote:
I'd also point you to the HTTPS guide but Oleg hasn't written it yet
grin.
There still is the (short) one httpclient/docs/USING_HTTPS.txt
Browse it online here:
Sunil Kumar K wrote:
Should I
need to get the response back and display it OR sending POST message
is enough and browser will get new page from site B.
Sunil,
The user's browser only gets what you write to the ServletOutputStream
of your servlet. This is not an issue with HttpClient. Please
Has anybody ever seen a 300 in the wild?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41-1-277 57 12
Adrian Sutton wrote:
And if anyone ever works out how a company with just 15 employees winds
up having this much trouble approving one signature I'd love to hear the
explanation... :)
Adrian,
Welcome, man! It's good to have you on board.
Just a few thoughts about the legal noise:
The agreement
I think it's easier to create a custom FilePartSource implementation
which creates the events or can be polled by your application.
Odi
Kalnichevski, Oleg wrote:
Jay, The only solution that I can think of is to get hold of
HttpClient source code and extend it with a feedback mechanism of
your
Manuel Castro Paliza wrote:
From NameValuePair to NameValuePair?¿?.
Sorry by my lack of java knowledge but I don't understand this conversion,
is something about memory?.
no. we generally call it bad design, or spaghetti code.
Michael,
Could you please post a wirelog of the session in question? Please refer
to the logging guide on the HttpClient website to learn how to get a log.
Odi
Michael Mattox wrote:
I get a HttpConnection.ConnectionTimeoutException with a certain site
(http://www.fnac.com) but I don't get it
Michael Mattox wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16729
Michael,
We are aware of the problem. The problem is caused by a design flaw
which can not be overcome in the current version. We can not do anything
until we have branched 2.0 out and start working on 2.1. There is a
Adrian Sutton wrote:
Sounds quite reasonable. The other thing to consider is exactly how
much the URI classes are likely to change anyway. They pretty much do
what's required now and I find it hard to imagine there'd be too many
changes that need to be made.
Code can always be nicer and more
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
Eric Johnson wrote:
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
Adrian Sutton wrote:
Odi,
HttpClient doesn't depend on the GC, it depends on the user telling us
when the connection is no longer in use (which Eric discovered he hadn't
done). There is however a fallback whereby when a HttpConnection is
garbage collected (ie: when we discover that it is no
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-06-19 14:54 ---
Are there any objections, comments to this patch?
Oleg
Okay with me. Maybe UPPERCASE the BitSet identifier?
-
To unsubscribe,
I think we should change the logging guide to set the log level to DEBUG
for org.apache.commons.httpclient. Currently it is set to TRACE and
users seem to leave it like this. Oleg, do you find this TRACE level
bloated logs useful? I think in the majority of cases a DEBUG level
output is
Oleg Kalnichevski wrote:
I fully agree. In 99% cases TRACE log produces no useful information. I
even usually grep through the logs excluding TRACE entries in order to
make them comprehensible.
Oleg
Patch to xdocs applied. The web will reflect the changes when it is next
generated.
Odi
Zulfi Umrani wrote:
I will appreciate if anyone answers my questions below.
-Does anyone has perfromance comparison between HTTPClient and JDK
HttpURLConnection?
I remember there was a comment about that on the list some months ago.
The guy said that HttpClient was slightly faster than
Good to here that you are fine! Welcome back to the Fellowship of The
Protocol. I have been missing your insightful comments on the list recently.
Odi
Jandalf wrote:
My house has sold, I've moved to Calgary and I have a new job. All is
well. I've been monitoring the list and have been taking
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
switzerland [fax] +41
[EMAIL PROTECTED] wrote:
I am looking for a way to specify a particular
client SSL certificate for Client Authenticated SSL.
This is usually done by writing a SSLSocketFactory that creates Sockets
with the Client Cert attached.
Kalnichevski, Oleg wrote:
I have only one outstanding issue on my hands: deprecation of
URIUtil.toXXXCharset methods.
As far as I remember these methods are not currently used. So they do
not harm. We can address this later if necessary. The whole issue seems
still a bit unclear to me, but
+1
Adrian Sutton wrote:
I move the motion that the following methods from
org.apache.commons.httpclient.util.URIUtil be depreciated for the 2.0
release and removed in a future release:
toDocumentCharset(String)
toDocumentCharset(String, String)
toProtocolCharset(String)
It sure would be useful however I am not sure if it is possible. I never
used a standard JSSE implementation. We used SSLava in our projects
(because it's supposed to be faster) and SSLava is does not have a JSSE
interface. So I wrote a SSLSocketFactory that configured SSLava to use a
specific
Sung-Gu wrote:
But, not a duty... it's voluteering... no pay...
even the code constribution here...
I pay you $5 for test cases from my Paypal account. Promise.
:-)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
[EMAIL PROTECTED] wrote:
It is possible to create a standard JSSE impl, but only for 1.4 JDK. In
previous JDK's the required classes were of the com.sun.net.ssl variety,
which of course is ugly. There is no cross-vm solution for JDKs prior to
1.4 that I am aware of.
- Matt Secoske
+1
Michael Becke wrote:
I propose that we start using commons-codec (nightly builds) for our
Base64 and URL encoding needs. This change would go into effect for
the 2.1 release (HEAD).
--
Vote: commons-codec
Adrian Sutton wrote:
+1.
Also +1 for keeping a specific list of files that's required from codec
so that applet developers like me can just pull them out instead of
having the whole kit and kaboodle. I volunteer for such a role.
Adrian Sutton.
Currently Codec consists of 2 (two) classes,
oops, true. No idea why I remembered only two classes...
Kalnichevski, Oleg wrote:
Odi,
I do not think it is quite correct. There's now at least two dozens of files, and some
of them are really of marginal use (language and phonetic encoders, for instance)
Oleg
Christopher Lenz wrote:
just a we'll try to preserve backwards compatibility as much as possible.
May I remind everybody that we made the 2.0 branch so that we can
finally overhaul the architecture. This normally implies large scale API
changes. Maintaining backwards compatibility and doing
[EMAIL PROTECTED] wrote:
I just decompiled the version 1.6 of the library and indeed, it seems that
this version does not handle status 100 responses, whereas version 2.0
does. I'll upgrade the library and let you know if this helps!!! :-)
Thanks a lot again!
Patrick
Mind the API and behaviour
David Sean Taylor wrote:
This implies that I can't contribute the InputStreamPartSource to your
codebase as is, since it will be coupled to my particular InputStream
factory.
Right, because the InputStreamPartSource can (by design) not fulfill the
contract of the createInputStream method
Wow, all that without getting 5$ :-)
[EMAIL PROTECTED] wrote:
--- Additional Comments From [EMAIL PROTECTED] 2003-07-18 13:11 ---
Fair enough. I will provide a test case shortly
Oleg
-
To unsubscribe, e-mail: [EMAIL
Querent,
let me put numbers in front of your actions (just for easier reference):
1. I have already succeed uploading file using MultipartPostMethod.
2. I have to download the file back for future reference.
3. I have already tried downloading the file both using GetMethod and
PostMethod, but
most experience here. Is there anything we must mention?
Odi
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück
Index: charencodings.xml
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/xdocs/charencodings.xml,v
retrieving revision 1.2
diff -u -r1.2 charencodings.xml
--- charencodings.xml 11 Mar 2003 08:03:12 - 1.2
+++
Kalnichevski, Oleg wrote:
Odi, My theory is that there may be (or Jeff thought there might be)
a requirement in the HTTP spec somewhere that underscore character
may be used instead of dash wherever dash is considered a valid
character, but I can't find that requirement in RFC2616. I guess we
Mike Moran wrote:
- Redirects. I need to follow redirects, but only up to a limit. This
limit is actually not just based on the number of redirects in a chain
but also on other factors, which are not derivable based on anything
HttpClient knows about.
So: requirement 3 is that I need to
committed to branch as well, of course...
Kalnichevski, Oleg wrote:
Odi,
Looks good to me. I think the patch is good to be checked in
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
attachments 100 KB get stripped by the list.
many thanks in advance.
Cheers,
quent
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück [email] [EMAIL
Adrian Sutton wrote:
On Tuesday, July 22, 2003, at 09:28 AM, Andre Augusto de Oliveira
Aragao wrote:
2003-07-21 18:41:44,472 [main] DEBUG
org.apache.commons.httpclient.HttpClient - SunJCE 1.42: SunJCE Provider
(implements DES, Triple DES, AES, Blowfish, PBE, Diffie-Hellman,
HMAC-MD5,
HMAC-SHA1)
Adrian Sutton wrote:
Odi,
We do need to improve tests, mostly in the area of keeping the
connection alive correctly, however we actually do have a test for this
particular case (and it passes). There's just something screwy going on
and we need to get the original exception out so we can try
ok with me
[EMAIL PROTECTED] wrote:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17947
Need setURI() methods in HttpMethod interface
--- Additional Comments From [EMAIL PROTECTED] 2003-07-22 13:15 ---
Any objections to committing this one?
Oleg
Could it be a classloader issue? Are you experiencing this error when
running your app in an application server context, through Webstart etc.
but not when running it standalone?
Odi
Andre Augusto de Oliveira Aragao wrote:
Adrian,
The actual stack trace is the following:
Andre Augusto de Oliveira Aragao wrote:
Just for the records, when Eclipse detects the JRE, it includes
sunjce_provider.jar. Running the app with the default Eclipse JRE renders
JCE unusable. But, if you take sunjce_provider.jar out of the list, no
problem.
Andre
Seems weird.
Which JDK Version are
Daniel,
I guess the Slide people will happily check in a patch that migrates to
a current HttpClient build. Maybe ask on their list, if you can work on it.
Odi
Daniel Joshua wrote:
Can somebody make a release soon in that case... I really need a
WebDAVClient which can be use with either a
+1
As our list of bugs for 2.0 target is currently empty and most things
seem documentation and integration issues.
Odi
Kalnichevski, Oleg wrote:
We have had just one (what I see as a real) bug since 2.0 beta2. I
think it is time we moved past 'beta' into 'final release' phase with
2.0 branch
.
--
_
NOSE applied intelligence ag
[www] http://www.nose.ch
ortwin glück [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich [office] +41-1-277 57 35
Eric Johnson wrote:
Some possible alternatives:
* Only do the isStale check if the connection has been sitting in
the pool for a configurable amount of time. I'm guessing we could
choose a value here between 5 and 30 seconds without any
significant change in behavior, that is
Oleg Kalnichevski wrote:
A clear drawback to this approach is that the connection would need to
'know' what kind of request is being executed. Of course, this is just
design purism. Feel free to ignore me.
Oleg
Uhm... the connection does not need to know the method by name. It's
sufficient that
Querent wrote:
Dear Odi,
I am using jsse for the ssl implementation. I still want to use
HttpClient in my program.
As mentioned before, HttpClient uses Sockets as created by JSSE. There
is nothing you can configure in HttpClient except of a custom
SocketFactory (which you can use to change
Eric Johnson wrote:
since isStale() calls setSoTimeout(1), since it cannot set it to zero.
Is this platform safe actually? Windows has only very corse timers, will
it still be around 1ms or will it be 20-30ms?
Maybe it is just me, but I can live with a 1ms penalty that dramatically
increases
Eric Johnson wrote:
Ortwin,
So far as I know, since Windows 95 it has been possible to measure and
wait for time intervals of 1ms. With Windows NT4.0/2000 and later, it
is even possible to do microseconds. I think the _really_ coarse timers
are a hang-over from Windows 3.1 days, and perhaps
They have individual packages of Jakarta subprojects:
http://www.gentoo.org/dyn/pkgs/dev-java/commons-httpclient.xml
Very nice!
Odi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I assume the patch is going into branch and head. Okay with me.
Odi
Oleg Kalnichevski wrote:
The patch addresses the problem with the proxy authentication realm
reported by David Rowe. HttpAuthenticator should now be picking up the
correct credentials when authenticating with an NTLM proxy (NTLM
George Gastaldi wrote:
I don't think it would be a good idea to scramble HTTPClient's code with
checks for 1.2 versions.
IMHO, the main requirement for HTTPClient MUST be Java 1.2 and above.
George
Yep. Totally agreed. If your application needs to do complex HTTP stuff,
then it is too complex
This is a work around to get the branches listed in Eclipses CVS
Perspective when the Refresh Branches function does not work due to a
missing .project file in CVS.
Alternatively you can use the standard method described in the Eclipse
Workbench User Guide Tasks Working in the team
sendig this message to the people I think are probably
most responsible for this topic as listed on [3].
Kind regards
Ortwin Glück
[1] http://jakarta.apache.org/commons/httpclient/
[2] http://www.gentoo.org/dyn/pkgs/dev-java/commons-httpclient.xml
[3] http://www.gentoo.org/main/en/devlist.xml
Oleg,
just an idea: maybe you can open a sourceforge.net project with the
1.1.8 version of HttpClient and share it with David. Should be
compatible with the Apache License but still distinguish it from the
'official' build.
Odi
Kalnichevski, Oleg wrote:
If you are able to sleep comfortably
]
--
_
NOSE applied intelligence ag
ortwin glück [www] http://www.nose.ch
software engineer [email] [EMAIL PROTECTED]
hardturmstrasse 171 [pgp key] 0x81CF3416
8005 zurich
Following Code works for me with 1.4.1 in Eclipse with nothing added to
the Classpath. I guess you are not running under 1.4.1 but 1.3. Check
the system libraries in the Eclipse Build path. Use add Library to add
the 1.4.1 System libraries.
package test;
/**
*
* @author Ortwin Glück
Adrian Sutton wrote:
My only concern with removing the code now is that we are so close to a
release and this is a change that clearly does have some fallout even if
we anticipate it to be very small.
We will need to make this *very* clear in the documentation
I am +1 to remove the code from
I find it bad pratice to set the JCE inside a totally lowlevel class.
The JCE should only be set by the application and not by HttpClient at all.
Odi
Adrian Sutton wrote:
String secProviderName =
System.getProperty(httpclient.security.provider,
com.sun.crypto.provider.SunJCE);
Wolfgang Hoschek - DSD Staff wrote:
- disabling stale connections with
connectionMgr.setConnectionStaleCheckingEnabled(false)
improves performance by a factor of 50 (note: factor, not percent).
This is because stale connection checking adds a constant penalty time,
which for very quick
Anu,
you should use authpost.addParameters(new NameValuePair[] {action, url})
and not setRequestBody.
HTH
Odi
NameValuePair action = new NameValuePair(url, Books);
NameValuePair url = new NameValuePair(field-keywords, java);
authpost.setRequestBody(new NameValuePair[] {action,
Adrian Sutton wrote:
The archive links do appear to be broken (though subscribe and unsubscribe
seem to be right). I'm not sure what the URL for the official archives are
- anyone know? Should we just point to one of the other external archives
that are available?
Yue,
thanks for the report. It's fixed in the xdocs now. The website just
needs redeploying.
Odi
Yue Luo wrote:
Hi,
It seems that today the link to Sample Code is broken although it
worked yesterday. The correct link may be:
Cheers.
Are you using Maven for this? I tried that yesterday (first time
actually) but found that with a fresh maven installation, the maven
tasks are broken. This is mainly caused by a new version of Checkstyle.
They moved their configuration from flat properties format to XML. So we
need to
Vincent,
As you know we have a RC1 currently. There is basically only
documentation and integration work going on. Oleg Kalnichevski, one of
the leading developers, is on vacation at the moment. So we will
probably not make a release until he returns (in two weeks time AFAIK).
I am sorry that
Mike Ma wrote:
UsernamePasswordCredentials userpass=
new UsernamePasswordCredentials(myname,mypass);
state.setProxyCredentials(null, null, userpass);
[WARN] HttpMethodBase - -Credentials cannot be used for NTLM
authentication: myname:mypass
It seems that your proxy
Adrian Sutton wrote:
My semi-educated guess would be that the server never stops sending data so
HttpClient continues to try to read it.
Don't use HttpClient to get the MP3 stream from a web radio station :-)
-
To unsubscribe,
Dan Tran wrote:
- The servlet picks up the GET request in doGet(), simulate a buffer
of TestSize, and send buffer back to the client using chunked
Transfer-Encoding
by calling response.setHeader( Transfer-Encoding, chunked);
I don't think that you can force the server to use chunked
1 - 100 of 595 matches
Mail list logo
