This is to announce the release of Pound v2.1.1. This is primarily a
bug-fix release.

Changes in this version (since 2.1):

Enhancements:
  - session IP behaves now like all other session types (no more sticky
    sessions).
  - RewriteLocation now accepts a value of 2. This avoids comparing the
    port number on the Listener, and thus should allow HTTP to HTTPS
    redirects.

Bug fixes:
  - fixed problem in str_be() - should fix the LogLevel 3 problems
  - for ANSI fanatics: added 'const' definitions wherever applicable
  - mutex handling error checking (just for completeness)

The software is at version 2.1.1 (beta quality). Further testing 
(especially under heavy loads), improvements and suggestions are
welcome.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Thanks for the enhancements.

> Bug fixes:
>   - fixed problem in str_be() - should fix the LogLevel 3 problems
>   - for ANSI fanatics: added 'const' definitions wherever applicable
>   
I think that this update will improve the readability of your source code.


>   - mutex handling error checking (just for completeness)
>
>   
I guess that the following instruction from the file "svc.c" is not 
complete.
"...
    if(ret_val = pthread_mutex_lock(&svc->mut))
        logmsg(LOG_ERR, "get_backend() lock: %s", strerror(ret_val));
..."

A program termination (abort) will be needed in this case because the 
error won't be recoverable here. A kind of logging can be additionally 
performed by another wrapper function.
Would you also like to minimize the amount of format string variants?

Regards,
Markus

>   - mutex handling error checking (just for completeness)
>   
Why was the addition of a function like "Pound_abort" from my suggestion 
"Improve correctness and code quality" not accepted?

How big is the probability that the message from your logging approach 
will not be noticed and the program will continue to run despite a 
potential memory corruption?

Regards,
Markus

I was encouraged to see the addition of the new RewriteLocation setting 
(see my recent posts) but I've set up another test server and am not 
seeing any difference in behavior with the value of 2.

Just thought I'd pass my experience along. BTW, I'm using Simon Matter's 
src rpm on RHEL 4.

Rob

Robert Segall wrote:
> This is to announce the release of Pound v2.1.1. This is primarily a
> bug-fix release.
>
> Changes in this version (since 2.1):
>
> Enhancements:
>   - session IP behaves now like all other session types (no more sticky
>     sessions).
>   - RewriteLocation now accepts a value of 2. This avoids comparing the
>     port number on the Listener, and thus should allow HTTP to HTTPS
>     redirects.
>
> Bug fixes:
>   - fixed problem in str_be() - should fix the LogLevel 3 problems
>   - for ANSI fanatics: added 'const' definitions wherever applicable
>   - mutex handling error checking (just for completeness)
>
> The software is at version 2.1.1 (beta quality). Further testing 
> (especially under heavy loads), improvements and suggestions are
> welcome.
>   

On Tue, 2006-09-12 at 10:32 +0200, SF Markus Elfring wrote:
> >   - mutex handling error checking (just for completeness)
> >   
> Why was the addition of a function like "Pound_abort" from my suggestion 
> "Improve correctness and code quality" not accepted?

Because it's not desirable. Aborting a program in a test environment is
OK, doing it in a live system is deadly.

> How big is the probability that the message from your logging approach 
> will not be noticed and the program will continue to run despite a 
> potential memory corruption?

That depends on the competence of the server manager.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

>>>   - mutex handling error checking (just for completeness)
>>>       
>> Why was the addition of a function like "Pound_abort" from my suggestion 
>> "Improve correctness and code quality" not accepted?
>>     
> Because it's not desirable. Aborting a program in a test environment is
> OK, doing it in a live system is deadly.
>   
My opinion is that it is the desired behaviour for safe and secure systems.
I suggest to consider the topic 
"http://en.wikipedia.org/wiki/Crash-only_software".


>> How big is the probability that the message from your logging approach 
>> will not be noticed and the program will continue to run despite a 
>> potential memory corruption?
>>     
> That depends on the competence of the server manager.
>   
An abnormal program termination can not be ignored and overlooked.
http://opengroup.org/onlinepubs/000095399/functions/abort.html

Example use case:
http://de.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
(I guess that this algorithm will not look into a log file for faults. 
If the primary server is not available for a while, the remaining 
"slaves" will select a new "master".)

Would like to look at 
"http://groups.google.de/group/comp.programming.threads/tree/browse_frm/thread/bd013d03610120d2/9989672acf27e396"

for usual advices?
There are different opinions how far an abort may be delayed. The 
internal program state (e. g. pthread data structures) might be 
corrupted in a way that the logging will not produce the expected 
results. Can the ignorance be avoided if the programm will be terminated 
as soon as possible because of important function return values like 
error codes?

Regards,
Markus

On Tue, 2006-09-12 at 10:01 -0500, Rob Moore wrote:
> I was encouraged to see the addition of the new RewriteLocation setting 
> (see my recent posts) but I've set up another test server and am not 
> seeing any difference in behavior with the value of 2.
> 
> Just thought I'd pass my experience along. BTW, I'm using Simon Matter's 
> src rpm on RHEL 4.
> 
> Rob

I think I may have a solution: in svc.c, line 640, you now have:

if(rewr_loc == 1) {
        /*
         * check if the Location points to the Listener but with the wrong port
         */
        if(memcmp(&lstn->addr.sin_addr.s_addr, &addr.sin_addr.s_addr,
sizeof(addr.sin_addr.s_addr)) == 0
        && memcmp(&lstn->addr.sin_port, &addr.sin_port, sizeof(addr.sin_port))
!= 0)
            return 1;
    } else {
        /*
         * rewr_loc 2: check if the Location points to the Listener - same
address
         */
        if(memcmp(&lstn->addr.sin_addr.s_addr, &addr.sin_addr.s_addr,
sizeof(addr.sin_addr.s_addr)) == 0)
            return 1;
    }

Please remove the "else" part, so it looks like this:

if(rewr_loc == 1) {
        /*
         * check if the Location points to the Listener but with the wrong port
         */
        if(memcmp(&lstn->addr.sin_addr.s_addr, &addr.sin_addr.s_addr,
sizeof(addr.sin_addr.s_addr)) == 0
        && memcmp(&lstn->addr.sin_port, &addr.sin_port, sizeof(addr.sin_port))
!= 0)
            return 1;
    }

I hope this will fix the problem. If you can confirm it does we'll put
this into the next release.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Thanks for looking into this. I applied the changes you suggested but 
I'm not noticing any difference in behavior. BTW, I left the 
RewriteLocation set to 2 since it seemed independent of this change.

Rob

> That depends on the competence of the server manager.
>   
What can be done by this person or monitoring process if a message like 
"get_backend() lock: ..." will be extracted from a log file?
Can the reported return value be used to repair a pound program while it 
is running? - I guess that the only consistent reaction will be to 
immediately kill and restart it to try to circumvent an unexpected 
error/bug.

How much can the internal runtime environment be trusted to be in a 
consistent state because of the logging approach? - Thread-safety will 
be lost if a failed lock will be ignored in the source code. It does not 
help to defer the decision about error handling to an other place. It 
will be too late for the rescue in this case.

I would appreciate the addition of a function for an abnormal program 
termination. It might do small things before the final abort will be 
performed.

Regards,
Markus

This is to announce the release of Pound v2.1.2. This is primarily a
feature enhancement release.

Changes in this version (since 2.1.1):

Enhancements:
- Error replies are sent as pure HTML
- split error messages into:
    - LOG_ERR: errors (mostly fatal)
    - LOG_WARNING: errors (non-fatal)
    - LOG_NOTICE: problems
    - LOG_INFO: extra information
- removed msdav compile-time configuration flag
- removed MSDAV configuration flag
- extended xHTTP to allow for WebDAV, MS-DAV and MS-RPC (MS-RPC requires
  additional testing!)
- added RewriteDestination configuration flag to enable rewriting the
  Destination header (required for Subversion)
- time to serve the requests is logged in LogLevel 2

Bug fixes:
  - fixed (again) the RewriteRedirect 2 mode

The software is at version 2.1.2 (beta quality). Further testing 
(especially under heavy loads), improvements and suggestions are
welcome.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

On Thu, 2006-09-14 at 13:17 -0500, Rob Moore wrote:
> Thanks for looking into this. I applied the changes you suggested but 
> I'm not noticing any difference in behavior. BTW, I left the 
> RewriteLocation set to 2 since it seemed independent of this change.

I have no idea - in all our tests it works as expected. Could you
please:

- use the just released 2.1.2 (just to be sure you have the right thing)
- if the problem persists post some logs and traces
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

> - split error messages into:
>     - LOG_ERR: errors (mostly fatal)
>   
How many functions can be considered to be candidates for abnormal 
program termination (abort)?
Where are immediate reactions for safe error handling absolutely required?

Regards,
Markus

2.1.2 broke our current setup.

We currently have our BackEnds redirect to different domains based on  
the request (HeadRequire) and when I updated to 2.1.2 we would get  
raw headers displaying in the page with "sec: ###############" and  
"usec:##############" (seems like debugging info) at the top and  
bottom of the headers.. sometimes it would repeat many times.

Rolling back to 2.1 seems to have fixed things, but I would really  
like to have LogLevel 2 working correctly (as it was with 2.1.2)

Thanks,
-Blake

On Sep 18, 2006, at 9:19 AM, Robert Segall wrote:

> This is to announce the release of Pound v2.1.2. This is primarily a
> feature enhancement release.
>
> Changes in this version (since 2.1.1):
>
> Enhancements:
> - Error replies are sent as pure HTML
> - split error messages into:
>     - LOG_ERR: errors (mostly fatal)
>     - LOG_WARNING: errors (non-fatal)
>     - LOG_NOTICE: problems
>     - LOG_INFO: extra information
> - removed msdav compile-time configuration flag
> - removed MSDAV configuration flag
> - extended xHTTP to allow for WebDAV, MS-DAV and MS-RPC (MS-RPC  
> requires
>   additional testing!)
> - added RewriteDestination configuration flag to enable rewriting the
>   Destination header (required for Subversion)
> - time to serve the requests is logged in LogLevel 2
>
> Bug fixes:
>   - fixed (again) the RewriteRedirect 2 mode
>
> The software is at version 2.1.2 (beta quality). Further testing
> (especially under heavy loads), improvements and suggestions are
> welcome.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to  
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
> http://www.apsis.ch/pound/pound_list/archive/ 
> 2006/2006-09/1157993815000/1158596375000

> 2.1.2 broke our current setup.
>
> We currently have our BackEnds redirect to different domains based on
> the request (HeadRequire) and when I updated to 2.1.2 we would get
> raw headers displaying in the page with "sec: ###############" and
> "usec:##############" (seems like debugging info) at the top and
> bottom of the headers.. sometimes it would repeat many times.

I've included the patch below in my rpms. I guess Robert just forgot to
remove the line in question.

Simon

--- Pound-2.1.2/http.c.orig     2006-09-18 18:12:18.000000000 +0200
+++ Pound-2.1.2/http.c  2006-09-19 10:39:48.000000000 +0200
(at)(at) -366,7 +366,6 (at)(at)
     struct timezone tz;

     gettimeofday(&tv, &tz);
-fprintf(stderr, "sec %ld, usec %ld\n", tv.tv_sec, tv.tv_usec);
     return tv.tv_sec * 1000000.0 + tv.tv_usec;
 #else
     return time(NULL) * 1000000.0;

Hi, Simon,

I've been looking for your 2.1.2 rpm -- might it be available today?

Thanks,

Rob

Simon Matter wrote:
>> 2.1.2 broke our current setup.
>>
>> We currently have our BackEnds redirect to different domains based on
>> the request (HeadRequire) and when I updated to 2.1.2 we would get
>> raw headers displaying in the page with "sec: ###############" and
>> "usec:##############" (seems like debugging info) at the top and
>> bottom of the headers.. sometimes it would repeat many times.
>>     
>
> I've included the patch below in my rpms. I guess Robert just forgot to
> remove the line in question.
>
> Simon
>
> --- Pound-2.1.2/http.c.orig     2006-09-18 18:12:18.000000000 +0200
> +++ Pound-2.1.2/http.c  2006-09-19 10:39:48.000000000 +0200
> (at)(at) -366,7 +366,6 (at)(at)
>      struct timezone tz;
>
>      gettimeofday(&tv, &tz);
> -fprintf(stderr, "sec %ld, usec %ld\n", tv.tv_sec, tv.tv_usec);
>      return tv.tv_sec * 1000000.0 + tv.tv_usec;
>  #else
>      return time(NULL) * 1000000.0;
>
>   

On Sep 19, 2006, at 5:14 AM, Simon Matter wrote:

>> 2.1.2 broke our current setup.
>>
>> We currently have our BackEnds redirect to different domains based on
>> the request (HeadRequire) and when I updated to 2.1.2 we would get
>> raw headers displaying in the page with "sec: ###############" and
>> "usec:##############" (seems like debugging info) at the top and
>> bottom of the headers.. sometimes it would repeat many times.
>
> I've included the patch below in my rpms. I guess Robert just  
> forgot to
> remove the line in question.

This looks purely cosmetic though.... the functionality loss issue is  
what concerns me.  Or is the fprintf actually causing the headers to  
be invalid?

-Blake

> Hi, Simon,
>
> I've been looking for your 2.1.2 rpm -- might it be available today?

It's there now. The reason for delaying it was that I first wanted to make
sure that it works.

Simon

>
> Thanks,
>
> Rob
>
> Simon Matter wrote:
>>> 2.1.2 broke our current setup.
>>>
>>> We currently have our BackEnds redirect to different domains based on
>>> the request (HeadRequire) and when I updated to 2.1.2 we would get
>>> raw headers displaying in the page with "sec: ###############" and
>>> "usec:##############" (seems like debugging info) at the top and
>>> bottom of the headers.. sometimes it would repeat many times.
>>>
>>
>> I've included the patch below in my rpms. I guess Robert just forgot to
>> remove the line in question.
>>
>> Simon
>>
>> --- Pound-2.1.2/http.c.orig     2006-09-18 18:12:18.000000000 +0200
>> +++ Pound-2.1.2/http.c  2006-09-19 10:39:48.000000000 +0200
>> (at)(at) -366,7 +366,6 (at)(at)
>>      struct timezone tz;
>>
>>      gettimeofday(&tv, &tz);
>> -fprintf(stderr, "sec %ld, usec %ld\n", tv.tv_sec, tv.tv_usec);
>>      return tv.tv_sec * 1000000.0 + tv.tv_usec;
>>  #else
>>      return time(NULL) * 1000000.0;
>>
>>
>
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-09/1157993815000/1158678768000
>

>
> On Sep 19, 2006, at 5:14 AM, Simon Matter wrote:
>
>>> 2.1.2 broke our current setup.
>>>
>>> We currently have our BackEnds redirect to different domains based on
>>> the request (HeadRequire) and when I updated to 2.1.2 we would get
>>> raw headers displaying in the page with "sec: ###############" and
>>> "usec:##############" (seems like debugging info) at the top and
>>> bottom of the headers.. sometimes it would repeat many times.
>>
>> I've included the patch below in my rpms. I guess Robert just
>> forgot to
>> remove the line in question.
>
> This looks purely cosmetic though.... the functionality loss issue is
> what concerns me.  Or is the fprintf actually causing the headers to
> be invalid?

Without looking at the code in detail, I think the fprintf was just used
to test the gettimeofday() values while doing tests with the code. And
then, I guess Robert uses a platform where HAVE_GETTIMEOFDAY is false and
that's why he didn't realize that the fprintf line is still there.

Simon

>
> -Blake
>
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-09/1157993815000/1158686392000
>

Hi, Robert,

I've updated to 2.1.2 using Simon's RPM and I'm experiencing a different 
issue. Now the https request results in a 501 response. I've verified 
that the backend server is never contacted. I can define a http listener 
running at port 80 and it works as expected.

I've looked in the log and it's not very enlightening:

Sep 20 16:03:34 robtest pound: bad request "GET / HTTP/1.1" from 10.5.3.57

Is there somewhere else I can look or a switch I can specify that will 
provide additional info?

Thanks,

Rob

Robert Segall wrote:
> On Thu, 2006-09-14 at 13:17 -0500, Rob Moore wrote:
>   
>> Thanks for looking into this. I applied the changes you suggested but 
>> I'm not noticing any difference in behavior. BTW, I left the 
>> RewriteLocation set to 2 since it seemed independent of this change.
>>     
>
> I have no idea - in all our tests it works as expected. Could you
> please:
>
> - use the just released 2.1.2 (just to be sure you have the right thing)
> - if the problem persists post some logs and traces
>   

On Tue, 2006-09-19 at 14:14 +0200, Simon Matter wrote:
> > 2.1.2 broke our current setup.
> >
> > We currently have our BackEnds redirect to different domains based on
> > the request (HeadRequire) and when I updated to 2.1.2 we would get
> > raw headers displaying in the page with "sec: ###############" and
> > "usec:##############" (seems like debugging info) at the top and
> > bottom of the headers.. sometimes it would repeat many times.
> 
> I've included the patch below in my rpms. I guess Robert just forgot to
> remove the line in question.
> 
> Simon
> 
> --- Pound-2.1.2/http.c.orig     2006-09-18 18:12:18.000000000 +0200
> +++ Pound-2.1.2/http.c  2006-09-19 10:39:48.000000000 +0200
> (at)(at) -366,7 +366,6 (at)(at)
>      struct timezone tz;
> 
>      gettimeofday(&tv, &tz);
> -fprintf(stderr, "sec %ld, usec %ld\n", tv.tv_sec, tv.tv_usec);
>      return tv.tv_sec * 1000000.0 + tv.tv_usec;
>  #else
>      return time(NULL) * 1000000.0;

Many thanks Simon, this goes into the next release.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

> Bug fixes:
> [...]
>   - for ANSI fanatics: added 'const' definitions wherever applicable
>   
Would you also like to clean-up the globals "h..." and "err_..." in the 
source file "http.c"?
How do you think about to specifiy constant character arrays there 
instead of pointers for string literals?
http://c-faq.com/decl/strlitinit.html

Regards,
Markus

This is to announce the release of Pound v2.1.3. This is primarily a
bug-fix release. It (hopefully) addresses the urgent problems that were
discovered in 2.1.2. Further enhancements should be expected in 2.1.4.

Changes in this version (since 2.1.2):

Bug fixes:
  - fixed the problem with the verb definition in HTTPS listeners
  - removed the spurious printf in cur_time

The software is at version 2.1.3 (beta quality). Further testing 
(especially under heavy loads), improvements and suggestions are
welcome.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904