-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


What is the known status of Pound-current?  I'm not sure whether to report
bugs or not... (i've got one or two at this point, but I don't know if
they are "known" bugs or not)

- -jason



- -- 
- -------------------------------------------------------------------
|                              |                                  |
| Jason Vasquez                | When their numbers dwindled from |
| jason(at)obiwan.homelinux.org   | 50 to 8, the other dwarves began |
| http://obiwan.homelinux.org  | to
suspect Hungry.               |
|                              |                                  |
|------------------------------------------------------------------
| Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt
      |
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/VhwZY6zA1HI6auYRAirJAKCf78sfm2oS3wUJd42XMDPRnrMG6gCeLS76
jZjlt0pScmC6lQugAr9uhUM=
=EbIE
-----END PGP SIGNATURE-----

On Wednesday 03 September 2003 18:51, you wrote:[...]

We always welcome problem reports. For your information, here is what has 
changed between 1.4 and -current. Most changes believed to be OK except where 
otherwise noted:

- we now offer the option of tracking sessions by Basic Authentication (in 
addition to URL, cookie and address).
- Pound does syntax checking of requests.
- User-defined request character set(s).
- Request size limit: requests larger than the user-specified limit are 
rejected.
- Single log function rather than #ifdefs (code clean-up); if Pound is 
compiled not to use syslog then separation of log messages between stdout 
(for regular information) and stderr.
- Added LogLevel 4 (same as 3 but without the virtual host info).
- Added support for streaming mode responses (still being tested, probably 
OK).
- Added HeadRemove directive: allows certain headers to be removed altogether 
from incoming requests.
- Added location rewriting on redirect: if the response is some kind of 
redirection and the Location indicates a known back-end it is rewritten to 
the address served by Pound (still being tested).

Please let us know what problems you ran into - we would like 1.5 to be as 
clean as possible.[...]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 6 Sep 2003, Robert Segall wrote:[...]

I just grabbed the most recent Pound-current (OK, I've got a little cron 
job that just alerted me to the newest one :)) -- I'm still seeing the 
issue I was a few days ago.

The setup:
o Linux server running 2.4.22, Apache 2.0.47 (RedHat, but custom built 
  kernel and Apache)
o Client running WinXP, Mozilla Firebird 0.6
o Pound-current configured to pass requests for everything back to Apache

Pound-1.4 is running on port 80 currently and working fine w/ the exact 
same config (except for changing the ports).

I send a basic request (well, dynamic PHP page with no Content-Length in
this case, which I thought may be related at first, but doesn't seem to be
when I try a static page with content-length)

The request takes a longish time from the client (5-10 seconds, instead of 
the usual 10 millisecond response), and nothing is displayed.

I get this error from Pound during the request:
06/Sep/2003 09:48:09 -0500: error copy cont: Success

I traced the conversation from the client to Pound w/ Ethereal if that's
any help, I'll paste it below.

Any ideas?
Thanks,
Jason

The HTTP Trace from Ethereal:

GET / HTTP/1.1
Host: obiwan.homelinux.org:81
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) 
Gecko/20030516 Mozilla Firebird/0.6
Accept: 
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=d45e20d92cd405adafa290d5e78bc7ee; 
JSESSIONID=KPOMNJJAINBM

HTTP/1.1 200 OK
Date: Sat, 06 Sep 2003 14:48:04 GMT
Server: Apache/2.0.47 (Unix) DAV/2 PHP/4.3.2 SVN/0.28.0+
X-Powered-By: PHP/4.3.2
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, 
pre-check=0
Pragma: no-cache
Last-Modified: Mon, 11 Aug 2003 10:48:26
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 574
Content-Type: text/html; charset=ISO-8859-1




- -- 
- -------------------------------------------------------------------
|                              |                                  |
| Jason Vasquez                | When their numbers dwindled from |
| jason(at)obiwan.homelinux.org   | 50 to 8, the other dwarves began |
| http://obiwan.homelinux.org  | to
suspect Hungry.               |
|                              |                                  |
|------------------------------------------------------------------
| Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt
      |
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/WfVaY6zA1HI6auYRAtoUAKCjMrFzXdyHFrQZVGnzrdk5wXwkWACfbK0T
KDLVvQCmJYNFgz4DGo0rT7g=
=nhDO
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 6 Sep 2003, Jason Vasquez wrote:[...]

Ooops -- sorry, looks like I was incorrect about that Content-Length
idea...sorry.  :)



- -- 
- -------------------------------------------------------------------
|                              |                                  |
| Jason Vasquez                | When their numbers dwindled from |
| jason(at)obiwan.homelinux.org   | 50 to 8, the other dwarves began |
| http://obiwan.homelinux.org  | to
suspect Hungry.               |
|                              |                                  |
|------------------------------------------------------------------
| Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt
      |
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/WfYbY6zA1HI6auYRAiG1AKDS24Rv45x5sZNp3lqDGbcetgf1wACbBc04
t7Rc3qEBm9m7olVJCcnSADo=
=nDxn
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ugh.  I'm sorry, I know this is bad form for me to keep replying to 
myself, but I thought I'd provide as much detail as possible.  I noticed 
that this error message appears twice in http.c, once while sending the 
request to the backend, and once during the response to the client (from 
what I understand).  I modified the messages to include which phase they 
were in, and this appears to be in response handling:

06/Sep/2003 10:01:36 -0500: error copy cont on response: Success

- -jason


- -- 
- -------------------------------------------------------------------
|                              |                                  |
| Jason Vasquez                | When their numbers dwindled from |
| jason(at)obiwan.homelinux.org   | 50 to 8, the other dwarves began |
| http://obiwan.homelinux.org  | to
suspect Hungry.               |
|                              |                                  |
|------------------------------------------------------------------
| Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt
      |
- -------------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/Wfc9Y6zA1HI6auYRAiEJAJ9Uq8F63ncx9ljcVwIg/2/T56y+bwCgmf3c
BdIj/1zwYfQX9548itLevw8=
=xsvb
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 6 Sep 2003, Jason Vasquez wrote:[...]

My form is getting worse and worse, but I want to get this resolved :)

Looking at the source (http.c), I've noticed that in the copy_bin method
whenver the response is less than MAXBUF bytes, BIO_read blocks for a few
seconds, and then returns -1.  If I create some content > than MAXBUF,
the request is working perfectly.

I'm not sure what else to do here, but I think this narrows down the 
problem quite a bit.

- -jason


- -- 
- -------------------------------------------------------------------
|                              |                                  |
| Jason Vasquez                | When their numbers dwindled from |
| jason(at)obiwan.homelinux.org   | 50 to 8, the other dwarves began |
| http://obiwan.homelinux.org  | to
suspect Hungry.               |
|                              |                                  |
|------------------------------------------------------------------
| Public Key: http://obiwan.homelinux.org/~jason/pubkey.txt
      |
- -------------------------------------------------------------------


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/WgTWY6zA1HI6auYRAnpmAJ4wsNM5bR3FoPjWwsJJ2pekSRzRgQCfZEZs
n/WiSvtrWXIQ8QmW3hE/lWg=
=iwoH
-----END PGP SIGNATURE-----

Hello!

Am Samstag, 6. September 2003 12:29 schrieb Robert Segall:
[...]

Works.
[...]

Works.
[...]

Perfect and very useful!
[...]

Not tested.
[...]

Looks good.
[...]

Works.
[...]

Whats that good for? Is there a single changeset (patch) for these changes? I 
think, we have a problem here that could be solved with it.
[...]

Not tested.
[...]

We had some strange effects with location redirection. Further testing 
required. Maybe this should be configurable.
[...]


Andi[...]

On Saturday 06 September 2003 18:01, you wrote:[...]

It would - except we never had any reports about it and can't replicate it.

Given that -current changes quite often I suggest you try downloading it 
again and test it - it may work better than last time...[...]

On Monday 08 September 2003 10:54, you wrote:[...]

This was added for OpenACS users. It seems sometimes their server returns 
very large replies by "streaming" the data: this is an old-style HTTP 
response (no content-length, no chunks, just data till EOF).
[...]

Feedback on this would be good. Assume your back-end replies with a redirect 
(code 30x) to some Location. Pound attempts to check if the Location contents 
is a "known" address (one of the known/defined back-ends or the Pound URL) 
and if necessary changes it to be the correct protocol and URL. Most 
importantly this would fix issues some servers have with http/https.
[...]

Thanks for the other reports.[...]