Hello Yutaka,
thanks for the detail answer.
I think we will have to stick to our work around for the moment and try
to get the manufacturer (landesk) to properly support standard.

Cheers,
Sebastien

On 08/03/10 10:02, Yutaka Sato wrote:
> Hi Sebastien,
>
> Thank you for your precise description and logging of the trouble shooting.
>
>  |We noticed that the chunking seams to be the source of our problem and
>  |when using "HTTPCONF=bugs:no-chunked" the problem seemed to be fixed.
> ...
>  |I would like to know what the bugs:no-chunked option is for (disable
>  |chunking)? And wether the Transfer-Encoding:chunked is added by delegate
>  |or by the client orignaly?
>
> Yes, it is DeleGate in this case that converts the transfer encoding
> of HTTP-body from no-encoding with the server, to the chunked encoding
> with the client.
> The "chunked" encoding is one of the most important extensions from
> HTTP/1.0 to HTTP/1.1 around ten years ago.  It enabled unknown o
> infinite length of contents to be transferred over HTTP (possibly
> repetitively on a single connection kept-alive.)
> When DeleGate works as a "reverse" proxy or a filtering proxy rewriting
> the body part of HTTP message, changing the length of it, the
> value of the Content-Length field in the HTTP header must be adjusted to
> it, but it can cause significant overhead for a large message (as seen
> in ancient versions of DeleGate).
> Using chunked encoding solves this problem.
>
> A client sending a request message with the version "HTTP/1.1", as in
> this case, MUST be able to handle this encoding in the HTTP response 
> essage.
> Of cause most of major browsers (HTTP clients) do handle this without a
> problem, except MSIE with some kind of plug-ins.
> As you did, "bugs:no-chunked" is a possible solutionto escape the problem,
> but it can be overkilling to disable any chunked encoding.
> Maybe disabling chunked-encoding for specific content-type will be
> appropriate, with HTTPCONFas  follows:
>
>   HTTPCONF=thru-type:+,application/microsoftpatch
>
> I'll make this be the default in the next release (9.9.7-pre32).
>
> Cheers,
> Yutaka
> --
>   9 9   Yutaka Sato <y.sato@delegate.org> http://delegate.org/y.sato/
>  ( ~ )  National Institute of Advanced Industrial Science and Technology
> _<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
> Do the more with the less -- B. Fuller
>
> On 03/04/10(20:18) you "S. Barbereau" <prqjabdyi-q45w4pluuza6.ml@delegate.org> wrote
> in <_A4748@delegate-en.ML_>
>  |Hello Yutaka,
>  |we are encountering a weird problem with our delegate http/https proxy
>  |and would appreciate some insights.
>  |We have deployed a desktop management software called landesk
>  |(http://www.landesk.com/) on our network. This tool automatically
>  |fetches a list of critical updates from a "landesk patch server" (on the
>  |internet) and then proceeds with the download before deploying it to all
>  |clients on the network.
>  |
>  |The internal landesk server used to work fine when running through our
>  |old squid proxy but since we migrated to delegate (9.9.5) we are facing
>  |some problems: some downloads initiated from this internal server fail.
>  |
>  |From the logs in delegate I see the following:
>  |03/03 13:32:14.24 [13052] 3714+0: -- Fork(SequentialServer): 2725 -> 13052
>  |03/03 13:32:14.24 [13052] 3714+1: (0) accepted [54]
>  |-@[136.156.22.87]136.156.22.87:21592 (0.002s)(1)
>  |03/03 13:32:14.24 [13052] 3714+1: Proxy: host=136.156.22.87; User-Agent:
>  |Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705;
>  |..NET CLR 1.1
>  |..4322); DIRECT
>  |03/03 13:32:14.24 [13052] 3714+1: REQUEST - GET
>  |http://ardownload.adobe.com/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp
>  |HTTP/1.1^M
>  |03/03 13:32:14.26 [13052] 3714+1: PATH>
>  |http://ardownload.adobe.com:80!proxyb-int.ecmwf.int:3333!136.156.22.87:21592!anonymous@136.156.22.87;1267623134
>  |03/03 13:32:14.26 [13052] 3714+1: REQUEST =
>  |[http://ardownload.adobe.com:80/] GET
>  |/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp HTTP/1.1
>  |^M
>  |03/03 13:32:14.30 [13052] 3714+1: ConnectToServer connected [13]
>  |{93.158.110.170:80 <- 193.61.196.142:56756} [0.042s]
>  |03/03 13:32:14.30 [13052] 3714+1: willSTLS_SV: ServerFlags=8000
>  |03/03 13:32:14.30 [13052] 3714+1: HTTP => (ardownload.adobe.com:80) GET
>  |/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp HTTP/1.1^M
>  |03/03 13:32:14.36 [13052] 3714+1: #HT11 NO-response-buffering: chunked mode
>  |03/03 13:32:14.36 [13052] 3714+1: #HT11 chunked, should skip:
>  |Content-Length: 2953728^M
>  |03/03 13:32:14.36 [13052] 3714+1: #HT11 SERVER ver[HTTP/1.1]
>  |conn[keep-alive]
>  |03/03 13:32:14.36 [13052] 3714+1: #HT11 --putChunk-Header:
>  |Transfer-Encoding: chunked^M
>  |03/03 13:32:14.36 [13052] 3714+1: HTTP/1.1 200
>  |Content-{Type:application/microsoftpatch Encoding:[/] Leng:2953728}
>  |KA:1/1 Server:Apache
>  |03/03 13:32:20.56 [13052] 3714+1: HTTP transmitted:
>  |264head+2953000/000000Fbody=>0txt+0bin->2953000/000000X,
>  |1527i/254o/0f/6.2 --c--
>  |03/03 13:32:20.56 [13052] 3714+1: #HT11 1 putServ(16/26/13)
>  |ardownload.adobe.com:80
>  |
>  |We noticed that the chunking seams to be the source of our problem and
>  |when using "HTTPCONF=bugs:no-chunked" the problem seemed to be fixed.
>  |Here the logs of the same operation with the no-chunked:
>  |03/03 13:24:52.25 [31507] 46+1: (1) accepted [39]
>  |-@[136.156.22.87]136.156.22.87:21424 (0.002s)(1)
>  |03/03 13:24:52.25 [31507] 46+1: Proxy: host=136.156.22.87; User-Agent:
>  |Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.0.3705;
>  |..NET CLR 1.1.4
>  |322); DIRECT
>  |03/03 13:24:52.25 [31507] 46+1: REQUEST - GET
>  |http://ardownload.adobe.com/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp
>  |HTTP/1.1^M
>  |03/03 13:24:52.25 [31507] 46+1: PATH>
>  |http://ardownload.adobe.com:80!proxya-int.ecmwf.int:3333!136.156.22.87:21424!anonymous@136.156.22.87;1267622692
>  |03/03 13:24:52.25 [31507] 46+1: REQUEST =
>  |[http://ardownload.adobe.com:80/] GET
>  |/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp HTTP/1.1^M
>  |03/03 13:24:52.29 [31507] 46+1: ConnectToServer connected [17]
>  |{93.158.110.170:80 <- 193.61.196.141:41938} [0.042s]
>  |03/03 13:24:52.29 [31507] 46+1: willSTLS_SV: ServerFlags=8000
>  |03/03 13:24:52.29 [31507] 46+1: HTTP => (ardownload.adobe.com:80) GET
>  |/pub/adobe/acrobat/win/8.x/8.2.1/misc/AcrobatUpd821_all_incr.msp HTTP/1.1^M
>  |03/03 13:24:52.35 [31507] 46+1: #HT11 SERVER ver[HTTP/1.1] conn[keep-alive]
>  |03/03 13:24:52.35 [31507] 46+1: HTTP/1.1 200
>  |Content-{Type:application/microsoftpatch Encoding:[/] Leng:2953728}
>  |KA:1/1 Server:Apache
>  |03/03 13:24:56.87 [31507] 46+1: HTTP transmitted:
>  |264head+2953000/000000Fbody=>0txt+0bin->2953000/000000X,
>  |2027i/240o/0f/4.5 -----
>  |03/03 13:24:56.88 [31507] 46+1: #HT11 1 putServ(25/27/17)
>  |ardownload.adobe.com:80
>  |03/03 13:24:56.88 [31507] 46+1: HCKA:[0] closed -- ?
>  |03/03 13:24:56.88 [31507] 46+1: disconnected [39]
>  |-@[136.156.22.87]136.156.22.87:21424 (4.635s)(0)
>  |
>  |I would like to know what the bugs:no-chunked option is for (disable
>  |chunking)? And wether the Transfer-Encoding:chunked is added by delegate
>  |or by the client orignaly?
>  |
>  |
>  |Thanks,
>  |Sebastien
>