Article delegate-en/4755 of [1-5169] on the server localhost:119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A4748@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: HTTP proxy issue with 'landesk' client software
08 Mar 2010 10:02:44 GMT feedback@delegate.org (Yutaka Sato)
The DeleGate Project


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-xg5asega4ulr.ml@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

  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V