Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xu.regis@gmail.com designates
 74.125.92.148 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=lmweZOfN+5uQkwwERR1juoRQFs1PYfyHIpOFcACsAodkLoIawRHIS2dtSUS+fC/84x
         tzHj7RmPwaC+bcg0o//yxrEdCFDMAkMeOAB45wXIGtZhxft9FS5nOEWim05Fqf8YoQmi
         Fd2xDrEXYMi+CTm/yo90vW+JcCVZ71kzDPmVs=
Message-ID: <499A86BE.4050000@gmail.com>
Date: Tue, 17 Feb 2009 17:43:26 +0800
From: Regis <xu.regis@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][luni]httpclient code in HttpConnection.java
References: <5948b71e0902162346s654a3a03xe457dfcc24ffb042@mail.gmail.com>
In-Reply-To: <5948b71e0902162346s654a3a03xe457dfcc24ffb042@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Charles Lee wrote:
> Hi guys,
> 
> We are using some code from the jakarta common's HttpConnection.java in our
> org.apache.harmony.luni.internal.net.www.protocol.http.HttpConnection.java.
>>>From the comment above the code, we are using a quite old revision r480424.
> 
> In the method isStale(), we have used inputStream.mark(1). But from the
> spec, we have "The general contract of mark is that, if the method
> markSupported returns true, the stream somehow remembers all the bytes read
> after the call to mark and stands ready to supply those same bytes again if
> and whenever the method reset is called. However, the stream is not required
> to remember any data at all if more than readlimit bytes are read from the
> stream before reset is called. " So I guess we should test markSupported()
> first.
> 
> 1. Should we update the code to the latest revision?
does the latest code work well with harmony?

> 2. Should we modify the code ourselves and get rid of the jakarta commons?
If it's easy to fix it by ourselves, I incline to get rid of the jakarka 
commons.

> 
> Any idea?
> 


-- 
Best Regards,
Regis.