----- Original Message -----
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Vincent Massol"
<[EMAIL PROTECTED]>
Sent: Saturday, July 14, 2001 5:27 PM
Subject: Re: HttpClient and HTTP headers/parameters
> Hi,
>
> I'd like to use the Commons HttpClient component for Cactus v2. I'm trying
> to use it but it seems it doesn't currently support adding several values
> for a given Http Parameter or a given HTTP header (see
HttpMethodBase.java).
> However I seem to remember that it is allowed by the RFC (can't remember
the
> number, sorry). This behaviour is what I already have in Cactus v1 (using
> standard HttpURLConnection) so I would hate to loose this feature in the
v2
> ...
>
> Do you agree to include the support for multi-valued parameters and
headers
> ? Also, what do you think about renaming the setHeader() and
setParameter()
> to addHeader() and addParameter() instead, as set is a bit misleading (and
> less standard) when you can call several times the same method ?
>
> >>>>>>>>>>>>
>
> We can add that, but you're not allowed to change the API ;-)
>
That's my biggest problem with HttpClient as it is ... I'd really like to
use it. However, it currently lacks a lot of support from the RFCs. We can
see that is was designed and used for a given task at hand and not as a
generic component that could be used in lots of different scenarios (this is
not a rebuke, it is completely normal seen the history of it). I just hope
that we will be able to change that and make it a fully generic and
RFC-compliant framework in the future.
hum... I understand that you want to release a 1.0 version that you could
use (with little change) in Slide. My problem is that I need it now ... Here
is what I propose :
- you release a 1.0 version. When ?
- I continue to use the standard HttpURLConnection from the JDK which in the
end is probably quite enough for my purpose (at the current time, the amount
of code to use HttpClient is about the same I have write when using
HttpURLConnection directly). My rationale for using HttpClient was the
following : as time goes on, I'll want to add support for other HTTP-related
features (like supporting the PUT HTTP operation, ....) and RFC compliance
and my code will get bigger and bigger in that area. Having a library that
implements it thoroughly is a pain-saver ...
FYI, Jigsaw has both a server side and full implementation of the HTTP API
on the client side (packages org.w3c.www.*), including DAV support and
others (The "main" class is the HttpManager, see
http://jigsaw.w3.org/Doc/Programmer/api/org/w3c/www/protocol/http/HttpManage
r.html). However, it seems it is _very_ badly documented on their web site,
all their docs only mention Jigsaw as a server (packages org.w3c.jigsaw.*)
... It is a pity they have not externalized the client side API in a
dedicated project ... However it seems all the client side live in the
org.w3c.www.* packages and does not depend on anything else so it is very
easy to extract it.
Any thought ?
> Besides, the servlet API has both add (multi-value) and set (single value)
> for headers on the response objects, so people should be used to having
> both.
>
> Before any big changes are made to the component, I'd like to make a 1.0
> release with the current code.
>
> Remy
Thanks
-Vincent
