In November last year Gustav Nuemann e-mailed me attached patch to the 
then current Pound version of 1.4.

In his own words, the patch addresses the issues listed below. Gustav 
was kind enough to work with me to address several of the problems 
identified below. As far as I know, Pound 1.4 with his patch applied is 
the only version of Pound that:

    * Handles old style streaming pages.
    * Optionally rewrites return-redirects

OpenACS Web Platform (http://openacs.org) uses
old style streaming pages 
in a number of places. And many OpenACS sites run behind routers that 
perform NAT to separate WAN from LAN. If pound is placed behind such 
router then rewrites of return-redirects are undesirable. More over 
OpenACS takes care of the rewrite quite nicely.

In short, the patched 1.4 version is the only version compatible with 
OpenACS. Would it be possible to integrate the changes in this patch to 
the current Pound version? The OpenACS community would be very greatful.

/Bart

----- Patch description --------


Time-stamp: <03/11/15 20:28:23 neumann>

These are my changes relative to Pound 1.4:

  - handling of the "old-style" responses

    The old code had problems with "streaming pages" from backend
    aolservers using ns_write. This technique is used to
    return partial answers for time consuming queries
    to keep the client watching what is happening.

    The old code used a blocking read, which tried to collect
    all data from the backend before sending it to the client.
    The new version is working such that every received
    chunk from the backend is immediately forwarded to the
    client.

  - rewriting of return-redirects:
    When a backend server replies with 302 and provides
    a location, the location has to be rewritten sometimes.

    Many web-apps (in particular OpenACS) like to redirect
    http requests to different urls on the same server.
    The new code handles two situations:

      * The target of a redirect is the backend server.
        When the backend (say host:8000) makes a redirect to itself,
        the redirect should really point to the proxy server.
        This is in particular important, when the proxy
        runs via https. The new code tries to detect such situations
        and rewrites the "Location:" reply header field.

      * The target of the redirect is the proxy-server, but with the
        wrong protocol: Many clients transmit "Host: hostname" in
        their request header fields. These host-tags are forwarded
        unmodified by the proxy to the backend-server. When the
        backend makes a redirect to the entry in the host-field, it
        does not know the protocol (e.g. https).  The new code tries
        to detect such situations and rewrites the "Location:" reply
        header field. It rewrites this tag only, when it received
        a https request, which triggers a reply with a "Location:"
        field containing http://proxy/path
(http and not https,
        the proxy contains no explicit port).

      * These rewriting stuff is enabled, when
          LocationUrlRewrite 1
        is set in the config file

  - improved logging stuff (mostly editing work):
     * log and warning are separated (with no-syslog to stdout and
       stderr)
     * warnings have time-stamps
     * LogLevel 4 writes in the common log file format (without
       "vhosts") such that common access log analyzer work

  - Server-timeouts: The config file can contain a
     "Server NNN" directive similar to
     "Client NNN", which can be used to control the
     the timeout on the connection to the backend.
     I have added the following semantics:
      * when NNN is given, it specifies the timeout
        to the backend in seconds
      * when the timeout expires it replies
        with 503 (service not available), the
        be is deactivated via kill_be() and
        might "resurrect" later (Default value
        for "Alive" 30 secs, might be changed
        through config file).
     * rationale: we had a situation, where the
       backend was accepting requests but was not
       answering it, the clients were simply hanging...
     * when NNN is 0 (default), it works as before.

  - Check URL is currently commented out, since
    the URL checking is not working correctly for all valid
    URLS.

    I would like to have the following config file flag:

    * UrlChecking 0: no url checking at all

    * UrlChecking 1: URL checking according to RFC 2396
      where the query_part is defined as

        query         = *uric
        uric            = reserved | unreserved | escaped
        reserved    = ";" | "/" | "?" | ":" | "(at)" | "&" | "=" | "+" |
                           "$" | ","
        unreserved = alphanum | mark
        alphanum   = "a" - "z" | "A" - "Z" | "0" - "9"
        mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
                           "(" | ")"

       All characters not "reserved" or "unreserved" must be escaped.
       As a consequence, do not process the query_part and split
       it into att/value pairs.

    * UrlChecking 2: tight URL checking,
      checking of att/value pairs by your rules or whatever, if you
      believe this is useful (i would permit at least escaped characters
      in the att-name part)

-gustaf neumann
[...]

On Thu, 2004-02-05 at 01:42, Bart Teeuwisse wrote:[...]

A lot (if not all) of the issues are addressed in the -current version.
Here is the list:
[...]

Pound never waited for the full reply before sending it to the client.
The -current version has much improved response times for HTTP 0.9.
[...]

In Pound since 1.5, with incremental improvements since.
[...]

Integrated since 1.5.
[...]

Supported since 1.5.
[...]

Currently the URL checking is off by default - you must enable it viy
the config file. Also underwent significant improvements since 1.4 days.

I would be grateful if you could try -current with OpenACS again - I
believe at least most of the issues are resolved.[...]

On Fri, 2004-02-06 at 00:42, Bart Teeuwisse wrote:[...]

1. Rather than blindly repeating what you are told you could have a look
at the source. Pound has NEVER collected the entire response - it would
leave it open to a DoS attack.

2. As I said in the original message use Pound-current. 1.5/1.6 have
known issues in this area.

3. Please keep this on the mailing list.[...]

[...][...]
I test myself. He tested it with the same test case which I provided him 
with. Don't jump to conclusions. I know better than going on hearsay.
[...]
[...]
mailing list so that repliss go to the list rather than the individual 
author.

/Bart

Robert,

testing Pound-current.tgz -downloaded 2004-02-07- I found several 
issues. Issues solved by Gustav's patch. Replacing Gustav's version of 
Pound I observed the following:

   1. Pound could no longer locate the backend servers which require a
      certain host header. I'm using the same config file as with
      Gustav's version. Virtual servers are defined as:

          UrlGroup ".*"
          HeadRequire Host ".*www.myserver.com"
          BackEnd 192.168.0.11,80,1
          Session COOKIE ad_session_id 1800
          EndGroup

      The exact same configuration works in Gustav's version -and Pound
      version 1.4 for that matter- but fails in Pound current.
   2. Pound current DOES wait for the entire page to be written before
      returning it to the client. I don't know if this is due to way the
      web server writes the response, the fact is that the response is
      NOT returned to the client untill the ENTIRE response has been
      written.

Please take a look at Gustav's patch as it solves a real issue that 
hasn't been addresses in the current version of Pound.

Thanks for a great reverse proxy. I hope this discussion will make it 
even better.

/Bart

On Sun, 2004-02-08 at 01:29, Bart Teeuwisse wrote:[...]

Could you please be more specific? What does it mean "can't locate
back-end"? What do you see?
[...]

Pound does NOT wait for the entire response and never did. There may be
a time-out involved in the first (and possibly last) round of data. You
may set the Server variable lower to shorten that or higher to prevent
data loss - have a look at the code (http.c lines 991 - 1008 to be
specific). If that does not solve it I would appreciate a trace of the
traffic between Pound and the server itself so we can fix it.
[...]

We have looked a while ago at Gustav's patch and incorporated most of it
(though not all as that would affect other areas).[...]

Robert,
[...]

    Feb  9 11:59:53 stanford pound: no backend "GET /test/write
    HTTP/1.1" from 66.92.28.174

'tcpdump src port 80 or dst port 80' trace:

    tcpdump: listening on eth0
    12:16:39.440328 dsl092-028-174.sfo4.dsl.speakeasy.net.63307 >
    pound.http: S 788364543:788364543(0) win 5840 <mss
    1460,sackOK,timestamp 7918691 0,nop,wscale 0> (DF)
    12:16:39.440359 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63307: S
    1323651190:1323651190(0) ack 788364544 win 5792 <mss
    1460,sackOK,timestamp 103962641 7918691,nop,wscale 0> (DF)
    12:16:39.461912 dsl092-028-174.sfo4.dsl.speakeasy.net.63307 >
    pound.http: . ack 1 win 5840 <nop,nop,timestamp 7918694 103962641>
(DF)
    12:16:39.478246 dsl092-028-174.sfo4.dsl.speakeasy.net.63307 >
    pound.http: P 1:481(480) ack 1 win 5840 <nop,nop,timestamp 7918694
    103962641> (DF)
    12:16:39.478267 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63307: . ack 481 win 6432
    <nop,nop,timestamp 103962645 7918694> (DF)
    12:16:39.490592 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63307: P 1:252(251) ack 481
    win 6432 <nop,nop,timestamp 103962646 7918694> (DF)
    12:16:39.499872 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63307: F 252:252(0) ack 481
    win 6432 <nop,nop,timestamp 103962647 7918694> (DF)
    12:16:39.519126 dsl092-028-174.sfo4.dsl.speakeasy.net.63307 >
    pound.http: . ack 252 win 6432 <nop,nop,timestamp 7918699 103962646>
    (DF)
    12:16:39.526995 dsl092-028-174.sfo4.dsl.speakeasy.net.63307 >
    pound.http: F 481:481(0) ack 253 win 6432 <nop,nop,timestamp 7918700
    103962647> (DF)
    12:16:39.527056 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63307: . ack 482 win 6432
    <nop,nop,timestamp 103962650 7918700> (DF)
[...]

    tcpdump: listening on eth0
    12:21:11.482834 dsl092-028-174.sfo4.dsl.speakeasy.net.63311 >
    pound.http: S 1058541488:1058541488(0) win 5840 <mss
    1460,sackOK,timestamp 7945901 0,nop,wscale 0> (DF)
    12:21:11.482874 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63311: S
    1590639533:1590639533(0) ack 1058541489 win 5792 <mss
    1460,sackOK,timestamp 103989846 7945901,nop,wscale 0> (DF)
    12:21:11.505233 dsl092-028-174.sfo4.dsl.speakeasy.net.63311 >
    pound.http: . ack 1 win 5840 <nop,nop,timestamp 7945904 103989846>
(DF)
    12:21:11.522169 dsl092-028-174.sfo4.dsl.speakeasy.net.63311 >
    pound.http: P 1:481(480) ack 1 win 5840 <nop,nop,timestamp 7945904
    103989846> (DF)
    12:21:11.522191 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63311: . ack 481 win 6432
    <nop,nop,timestamp 103989850 7945904> (DF)
    12:21:11.536881 stanford.43185 > team.http: S
    1596068952:1596068952(0) win 5840 <mss 1460,sackOK,timestamp
    103989851 0,nop,wscale 0> (DF)
    12:21:11.537026 team.http > stanford.43185: S
    2913789777:2913789777(0) ack 1596068953 win 5792 <mss
    1460,sackOK,timestamp 466223705 103989851,nop,wscale 0> (DF)
    12:21:11.537051 stanford.43185 > team.http: . ack 1 win 5840
    <nop,nop,timestamp 103989851 466223705> (DF)
    12:21:11.537410 stanford.43185 > team.http: P 1:515(514) ack 1 win
    5840 <nop,nop,timestamp 103989851 466223705> (DF)
    12:21:11.537704 team.http > stanford.43185: . ack 515 win 6432
    <nop,nop,timestamp 466223705 103989851> (DF)
    12:21:11.996837 team.http > stanford.43185: P 1:208(207) ack 515 win
    6432 <nop,nop,timestamp 466223751 103989851> (DF)
    12:21:11.999275 stanford.43185 > team.http: . ack 208 win 6432
    <nop,nop,timestamp 103989897 466223751> (DF)
    12:21:11.999647 team.http > stanford.43185: P 208:275(67) ack 515
    win 6432 <nop,nop,timestamp 466223751 103989897> (DF)
    12:21:11.999655 stanford.43185 > team.http: . ack 275 win 6432
    <nop,nop,timestamp 103989897 466223751> (DF)
    12:21:13.001153 team.http > stanford.43185: P 275:288(13) ack 515
    win 6432 <nop,nop,timestamp 466223852 103989897> (DF)
    12:21:13.003893 stanford.43185 > team.http: . ack 288 win 6432
    <nop,nop,timestamp 103989998 466223852> (DF)
    12:21:14.011015 team.http > stanford.43185: P 288:301(13) ack 515
    win 6432 <nop,nop,timestamp 466223953 103989998> (DF)
    12:21:14.047534 stanford.43185 > team.http: . ack 301 win 6432
    <nop,nop,timestamp 103990102 466223953> (DF)
    12:21:15.021408 team.http > stanford.43185: P 301:314(13) ack 515
    win 6432 <nop,nop,timestamp 466224054 103990102> (DF)
    12:21:15.024418 stanford.43185 > team.http: . ack 314 win 6432
    <nop,nop,timestamp 103990200 466224054> (DF)
    12:21:16.030897 team.http > stanford.43185: P 314:327(13) ack 515
    win 6432 <nop,nop,timestamp 466224155 103990200> (DF)
    12:21:16.031868 stanford.43185 > team.http: . ack 327 win 6432
    <nop,nop,timestamp 103990301 466224155> (DF)
    12:21:17.040595 team.http > stanford.43185: P 327:340(13) ack 515
    win 6432 <nop,nop,timestamp 466224256 103990301> (DF)
    12:21:17.040688 stanford.43185 > team.http: . ack 340 win 6432
    <nop,nop,timestamp 103990401 466224256> (DF)
    12:21:18.050558 team.http > stanford.43185: P 340:353(13) ack 515
    win 6432 <nop,nop,timestamp 466224357 103990401> (DF)
    12:21:18.050652 stanford.43185 > team.http: . ack 353 win 6432
    <nop,nop,timestamp 103990502 466224357> (DF)
    12:21:19.060642 team.http > stanford.43185: P 353:366(13) ack 515
    win 6432 <nop,nop,timestamp 466224458 103990502> (DF)
    12:21:19.060763 stanford.43185 > team.http: . ack 366 win 6432
    <nop,nop,timestamp 103990603 466224458> (DF)
    12:21:20.070500 team.http > stanford.43185: P 366:379(13) ack 515
    win 6432 <nop,nop,timestamp 466224559 103990603> (DF)
    12:21:20.070598 stanford.43185 > team.http: . ack 379 win 6432
    <nop,nop,timestamp 103990704 466224559> (DF)
    12:21:21.080433 team.http > stanford.43185: P 379:392(13) ack 515
    win 6432 <nop,nop,timestamp 466224660 103990704> (DF)
    12:21:21.080541 stanford.43185 > team.http: . ack 392 win 6432
    <nop,nop,timestamp 103990805 466224660> (DF)
    12:21:21.080672 team.http > stanford.43185: P 392:415(23) ack 515
    win 6432 <nop,nop,timestamp 466224660 103990805> (DF)
    12:21:21.080703 stanford.43185 > team.http: . ack 415 win 6432
    <nop,nop,timestamp 103990805 466224660> (DF)
    12:21:21.083145 team.http > stanford.43185: F 415:415(0) ack 515 win
    6432 <nop,nop,timestamp 466224660 103990805> (DF)
    12:21:21.083245 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63311: P 1:417(416) ack 481
    win 6432 <nop,nop,timestamp 103990806 7945904> (DF)
    12:21:21.083568 stanford.43185 > team.http: F 515:515(0) ack 416 win
    6432 <nop,nop,timestamp 103990806 466224660> (DF)
    12:21:21.083747 team.http > stanford.43185: . ack 516 win 6432
    <nop,nop,timestamp 466224660 103990806> (DF)
    12:21:21.083814 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63311: F 417:417(0) ack 481
    win 6432 <nop,nop,timestamp 103990806 7945904> (DF)
    12:21:21.116100 dsl092-028-174.sfo4.dsl.speakeasy.net.63311 >
    pound.http: . ack 417 win 6432 <nop,nop,timestamp 7946865 103990806>
    (DF)
    12:21:21.118114 dsl092-028-174.sfo4.dsl.speakeasy.net.63311 >
    pound.http: F 481:481(0) ack 418 win 6432 <nop,nop,timestamp 7946865
    103990806> (DF)
    12:21:21.118143 pound.http >
    dsl092-028-174.sfo4.dsl.speakeasy.net.63311: . ack 482 win 6432
    <nop,nop,timestamp 103990809 7946865> (DF)

Hope this helps. Let me know if I can do anything else.

/Bart
[...]

On Mon, 2004-02-09 at 20:29, Bart Teeuwisse wrote:[...]

This looks like some unrelated problem - could you have another look at
your config? Pound could find no back-end to satisfy an incoming
request, probably because it could not match the URL or could not
satisfy some HeadRequire/HeadDeny directive(s).

[...]

...snip...
[...]

Thanks for the effort, but this is not what we really need: all it shows
is that some packets went back and forth. We would like to see the
contents of those packets to try and track down your problem.[...]

Robert,
[...][...]
configuration CAN find a backend with Pound 1.4 + Gustav's patch. No
other changes have been made. Not to Pound nor the network
configuration. That pretty much tells me that it IS a pound problem,
introduced by Pound 1.6 current. I've run some more tests with
intermediate Pound versions too.

    Pound 1.4 doesn't compile because of a problem with libcrypto.a

    Pound 1.5 and 1.6 have the same problem as 1.6 current.

The complete pound.cfg reads:

    ListenHTTP 192.168.123.8,80

    LogLevel 2

    UrlGroup ".*"
    HeadRequire Host ".*team.praesagus.net"
    BackEnd 192.168.123.28,80,1
    EndGroup

And again, to be perfectly clear, this configuration works with Pound
1.4 + Gustav's patch but not with Pound 1.5, 1.6 or current.
[...]
sniffer- so that I can optain the information you need to track down the
problem.

/Bart

On Wed, 2004-02-11 at 01:13, Bart Teeuwisse wrote:[...]

I find this surprising - I am not aware of any change in this area since
1.4. Please have a look at the change logs or just diff the releases
(they are still available).
[...]

My personal preference is for tcpwatch. Ideally you use two instances:
one between the client and Pound, the second between Pound and the
back-end. This allows you to compare the original request to what gets
sent to the server. You could replace the tcpwatch instance between the
client and Pound with something like LiveHTTPHeaders if you use some
Mozilla flavour. In any case we would like to see the headers for the
following four stages of a failed transaction:

- browser -> Pound request
- Pound -> back-end request (as a result of the above)
- back-end -> Pound response
- Pound -> browser response

Make sure to send a FAILED transaction.[...]

Robert,
[...][...]
message starting this thread- for differences with later Pound versions. 
I wouldn't know where to look in the code, my C skill are not that advanced.
[...]

    * Pound runs on 192.168.123.8 at port 81 with tcpwatch listening to
      port 80 recording the traffic between Pound and the Browser.

    * The Webserver (AOLserver) runs on 192.168.123.28 port 81 with tcp
      listening to port 80 recording the traffic between Pound and the
      Webserver.

I have no log of the 'no backend' error as there is no traffic to record 
between Pound and the web server.

After removing 'HeadRequire Host' from pound.cfg to enable Pound to 
connect to the webserver I recorded the following traffic (using Pound 
version 1.6 current) of a FAILED request for a streaming page:

    * Between Pound and the Browser:

      [00:00.000 - client 66.92.28.174:63842 forwarded to 192.168.123.8:81]
      [00:00.000 - server connected]
      ==>GET /test/write HTTP/1.1
      ==>Host: team.praesagus.net
      ==>User-Agent: Elinks (0.3.2; Linux 2.4.20-20.8 i686)
      ==>Accept: */*
      ==>Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4,
      ISO-8895-5, ISO-8859-7, ISO-8895-9, ISO-8859-13, ISO-8859-15,
      ISO-8859-16, windows-1250, windows-1251, windows-1257, cp437,
      cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs,
      koi8-r, koi8-u, TCVN-5712, VISCII, utf-8
      ==>Connection: Keep-Alive
      ==>Pragma: no-cache
      ==>Cache-Control: no-cache
      ==>Cookie:
     
ad_session_id=2460002%2c0+%7b1156+1076531826+FEF81A5C0BA7DBA0BF4E34CD93AC68DB3A272089%7d
      ==>
      <==HTTP/1.0 200 OK
      <==MIME-Version: 1.0
      <==Content-Type: text/html
      <==Server: AOLserver/4.1
      <==
     
<==<html><header><title>Bla</title></header><body><h2>Bla</h2><hr><ol><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li></ol><hr></body></html>
      [00:09.143 - server closed]

    * Between Pound and the Webserver:

      [00:00.000 - client 192.168.123.7:50407 forwarded to
      192.168.123.28:81]
      ==>GET /test/write HTTP/1.1
      ==>Host: team.praesagus.net:81
      ==>User-Agent: Elinks (0.3.2; Linux 2.4.20-20.8 i686)
      ==>Accept: */*
      ==>Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4,
      ISO-8895-5, ISO-8859-7, ISO-8895-9, ISO-8859-13, ISO-8859-15,
      ISO-8859-16, windows-1250, windows-1251, windows-1257, cp437,
      cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs,
      koi8-r, koi8-u, TCVN-5712, VISCII, utf-8
      ==>Connection: Keep-Alive
      ==>Pragma: no-cache
      ==>Cache-Control: no-cache
      ==>Cookie:
     
ad_session_id=2460002%2c0+%7b1156+1076531826+FEF81A5C0BA7DBA0BF4E34CD93AC68DB3A272089%7d
      ==>X-Forwarded-For: 192.168.123.8
      ==>
      [00:00.001 - server connected]
      <==HTTP/1.0 200 OK
      <==MIME-Version: 1.0
      <==Content-Type: text/html
      <==Server: AOLserver/4.1
      <==
     
<==<html><header><title>Bla</title></header><body><h2>Bla</h2><hr><ol><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li></ol><hr></body></html>
      [00:09.096 - server closed]

Observation: The Webserver wrote each step a second appart. Pound did 
NOT return the response until it the Webserver closed the connection to 
Pound. The log can't show this, but I made sure this observation is correct.

To be complete, I've also recorded the traffic of the same request this 
time using Pound 1.4 + Gustav's patch:

    * Between Pound and Browser:

      [00:00.000 - client 66.92.28.174:63854 forwarded to 192.168.123.8:81]
      [00:00.001 - server connected]
      ==>GET /test/write HTTP/1.1
      ==>Host: team.praesagus.net
      ==>User-Agent: Elinks (0.3.2; Linux 2.4.20-20.8 i686)
      ==>Accept: */*
      ==>Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4,
      ISO-8895-5, ISO-8859-7, ISO-8895-9, ISO-8859-13, ISO-8859-15,
      ISO-8859-16, windows-1250, windows-1251, windows-1257, cp437,
      cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs,
      koi8-r, koi8-u, TCVN-5712, VISCII, utf-8
      ==>Connection: Keep-Alive
      ==>Pragma: no-cache
      ==>Cache-Control: no-cache
      ==>Cookie:
     
ad_session_id=2460002%2c0+%7b1159+1076532711+8E7554A62531A288FA121EDDA137EDDD897F81C0%7d
      ==>
      <==HTTP/1.0 200 OK
      <==MIME-Version: 1.0
      <==Content-Type: text/html
      <==Server: AOLserver/4.1
      <==
     
<==<html><header><title>Bla</title></header><body><h2>Bla</h2><hr><ol><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li></ol><hr></body></html>
      [00:09.151 - server closed]


    * Between Pound and Webserver:

      [00:00.000 - client 192.168.123.7:50441 forwarded to
      192.168.123.28:81]
      [00:00.000 - server connected]
      ==>GET /test/write HTTP/1.1
      ==>Host: team.praesagus.net
      ==>User-Agent: Elinks (0.3.2; Linux 2.4.20-20.8 i686)
      ==>Accept: */*
      ==>Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4,
      ISO-8895-5, ISO-8859-7, ISO-8895-9, ISO-8859-13, ISO-8859-15,
      ISO-8859-16, windows-1250, windows-1251, windows-1257, cp437,
      cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce, x-kam-cs,
      koi8-r, koi8-u, TCVN-5712, VISCII, utf-8
      ==>Connection: Keep-Alive
      ==>Pragma: no-cache
      ==>Cache-Control: no-cache
      ==>Cookie:
     
ad_session_id=2460002%2c0+%7b1159+1076532711+8E7554A62531A288FA121EDDA137EDDD897F81C0%7d
      ==>X-Forwarded-For: 192.168.123.8
      ==>
      <==HTTP/1.0 200 OK
      <==MIME-Version: 1.0
      <==Content-Type: text/html
      <==Server: AOLserver/4.1
      <==
     
<==<html><header><title>Bla</title></header><body><h2>Bla</h2><hr><ol><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li><li>Step</li></ol><hr></body></html>
      [00:09.108 - server closed]

Observation: The logs are virtually identical, yet this time each step 
is forwarded to the Browser by Pound as they come in from the Webserver.

Robert, let me know what you make of it.

/Bart

I looked at the logs and they don't show much. What we have here is a
simple case of re-packaging: OpenACS returns small packets, which Pound
re-packages into larger ones.

To convince yourself of this fact try to return a much longer response
(try 30-60K) and you'll see that the response from Pound to the client
arrives in pieces of MAXBUF - currently 8K.

Now you may claim that you want better granularity - so just change the
value of MAXBUF in pound.h to something smaller (probably 1-2K is the
smallest practical value), recompile and try again.

Let us know.

PS: about the failed request: the log of the request between the browser
and Pound would be very valuable.[...]

Robert,
[...]
does show improved granularity. Although not as fine as Gustav's patch. 
Granularity doesn't appear to improve below a MAXBUF of 1K.
[...]
requests for virtual servers that don't require a host header:

    [00:00.000 - client 66.92.28.174:61191 forwarded to 192.168.123.8:81]
    [00:00.001 - server connected]
    ==>GET /test/write HTTP/1.1
    ==>Host: team.praesagus.net
    ==>User-Agent: Elinks (0.3.2; Linux 2.4.20-20.8 i686)
    ==>Accept: */*
    ==>Accept-Charset: us-ascii, ISO-8859-1, ISO-8859-2, ISO-8859-4,
    ISO-8895-5, ISO-8859-7, ISO-8895-9, ISO-8859-13, ISO-8859-15,
    ISO-8859-16, windows-1250, windows-1251, windows-125\
    7, cp437, cp737, cp850, cp852, cp866, x-cp866-u, x-mac, x-mac-ce,
    x-kam-cs, koi8-r, koi8-u, TCVN-5712, VISCII, utf-8
    ==>Connection: Keep-Alive
    ==>
    <==HTTP/1.0 503 Service Unavailable
    <==Content-Type: text/html
    <==Content-Length: 169
    <==
    <==<html><head><title>503 Service
    Unavailable</title></head><body><h1>503 Service
    Unavailable</h1><p>The service is not available. Please try
again
    later.</p></body></html>
    [00:00.048 - server closed]

I'm at a loss here. Is there anyway to produce diagnostic information in 
Pound? The incoming request looks fine to me. Pound does not forward the 
request to a backend at all.

/Bart

Thanks for all the info - it was very useful. Please try:

1. Download and install the new -current I just uploaded. It should
solve the granularity problem.

2. Modify your config file to read

HeadRequire Host ".*team.praesagus.net.*"

which should fix your errors.

3. Please let us know how it all works.[...]

Robert,
[...]
[...]
page when configuring Pound.
[...]

/Bart