Article delegate-en/1005 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:<_A1000@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: Delegate 6.1.20/21 on RHL6 NPH
06 Feb 2001 04:55:11 GMT ysato@etl.go.jp (Yutaka Sato)


On 01/31/01(02:57) you Mike Kovacs <p5abqbdyi-bfkmicg76c3r.ml@ml.delegate.org> wrote
in <_A1000@delegate-en.ML_>
 |     We are attempting to build an app located behind a v6.1.20 Delegate 
 |server. The application uses some file xfers, etc which take time to do. 
 |Although not explicitly setup this way, what is occuring is that with the 
 |proxy locked down ( SERVER=http://niven, PERMIT=http:*:*) the page has to 
 |fully cache to the proxy before the user sees anything, which is 

How did you recognize such behavior of DeleGate from what ? 
Could you show me what is recorded in LOGFILE ?
As long as I remember, I did not make DeleGate to block relaying
until cache is done.

 |approximately 10-15 seconds. We'd like to use NPH as the method of 

Possibly the reason of the delay is not caching, but the buffering
to know the exact length of response data.  To know response length
is necessary when a client request is in HTTP/1.0 (implying "chnuked"
transfer coding disabled) with Connection:Keep-Alive.
If this is the case, you will find a string "flush slow response" in
your LOGFILE, and the problem will be solved by one of followings:

 - use HTTP/1.1 in your client (which imply "chunked" coding enabled), or
 - disalbe Keep-Alive in your DeleGate with a parameter MAXIMA=http-cka:0

The following is the relevant code. Some constants should be shorter
or be customizable. Keep-Alive with HTTP/1.0 clients might have to be
disabled by default.

http.c:relay_response()
...
         if( WillKeepAlive )
         if( RX_tcp == RX_respBuff && !RX_inHeader && !ClientEOF )
         if( 1024*1024 < RX_rdContLen
         || 1024*1024 < RX_rdTotal
         || 15 < Time()-CONN_DONE
         || !fromcache
         && RX_fsx.t_nready == 0 && (RX_fsx.t_nready = fPollIn(RX_fsp,100)) == 0
         && 10 < Time()-CONN_DONE )
                 RX_tcp = detach_respbuff(Conn,RX_tcp,RX_tc_sav,
                         RX_qWithHeader,"flush slow response.");

 |informing the user, but the caching behavior exists with NPH as well, so we 
 |know its the proxy. Now we can get immediate response and proper NPH 
 |operation by opening up and using tcprelay, but there are obvious security 
 |concerns. Is the product capable of doing a non-cached proxying easily??

Cheers,
Yutaka
--
Yutaka Sato <ysato@delegate.org> http://www.delegate.org/~ysato/   @ @ 
Computer Science Division, Electrotechnical Laboratory            ( - )
1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan                  _<   >_

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