Re: svn commit: r1088435 - in /jakarta/jmeter/trunk: bin/ src/core/org/apache/jmeter/util/ src/protocol/http/org/apache/jmeter/protocol/http/sampler/ xdocs/ xdocs/usermanual/

On 4 April 2011 20:35, Milamber <[email protected]> wrote:
>
> [snip]
>>> +#http.getbytes.type=default
>>> +#http.getbytes.type=calculate_headers_size+default
>>> +#http.getbytes.type=calculate_headers_size+content-length_value
>>>
>> These values are a bit complicated; I'd prefer to see true/false
>> values if possible.
>>
> Ok I change this to 2 properties true/false.

+1

>>
>>> +    /**
>>> +     * Get Content-Length value from headers
>>> +     * @param headers
>>> +     * @return Content-Length value
>>> +     */
>>> +    public static int getHeaderContentLength(String headers) {
>>> +        LinkedHashMap<String, String> lhm = JMeterUtils.parseHeaders(headers);
>>> +        Set<Entry<String, String>> keySet = lhm.entrySet();
>>> +        for (Entry<String, String> entry : keySet) {
>>> +            if (entry.getKey().equals(HEADER_CONTENT_LENGTH)) {
>>> +                return Integer.parseInt(entry.getValue());
>>> +            }
>>> +        }
>>> +        return 0; // Content-Length not found
>>>
>> This does not work for chunked input. It might be better to store the
>> actual response size when receiving the response, rather than trying
>> to calculate it later.
>>
>
> Ok, store in sampleresult when receiving the response. If 0 (no value),
> the response data size is used.
>
>
> With my last submission (r1088748), I try to respond to your feedback.
> Please say me if another thing to improve.

The problem of chunked responses still exists - such responses don't
have a Content-Length header.

One way round this would be to wrap the input Stream with a
org.apache.commons.io.input.CountingInputStream.
I don't think this will affect performance adversely.

Does that make sense?