headers
Jeff Trawick | 2 May 2005 02:04
Picon

Re: [1.3 PATCH] rework suppress-error-charset feature

On 4/29/05, Jeff Trawick <trawick <at> gmail.com> wrote:
> On 4/29/05, Jim Jagielski <jim <at> jagunet.com> wrote:
> > +1 from me :)
> >
> > How appropriate would a 2.0/2.1 patch be as well?
> 
> You tell me.  I'm certainly willing to work up a 2.1 patch.
> 
> I have to confess to ignorance about the scope of the problem.

I found a description of the problem:

> When Apache issues a redirect in response to a client request, the response 
> includes some actual text to be displayed in case the client can't (or doesn't) 
> automatically follow the redirection. Apache ordinarily labels this text according 
> to the character set which it uses, which is ISO-8859-1.
> 
> However, if the redirection is to a page that uses a different character set, some 
> broken browser versions will try to use the character set from the redirection text
> rather than the actual page. This can result in Greek, for instance, being 
> incorrectly rendered.
Permalink | Reply | 4 comments |
headers
Yanbin Ma | 2 May 2005 14:23

RE: APR/HTTPD build on AIX 5.2 under PASE iSeries

It really depends on your needs. Check out IBM HTTP Server, that's an
IBM-built apache server. They're a number of releases behind, but they may
give you some pointers of what to include. 

Yanbin Ma

-----Original Message-----
From: Henri Gomez [mailto:henri.gomez <at> gmail.com] 
Sent: Saturday, April 30, 2005 3:47 AM
To: Discussion about Apache HTTPD
Subject: APR/HTTPD build on AIX 5.2 under PASE iSeries

Hi to all,

I'm trying to build the Apache 2.0.54 on iSeries PASE (AIX 5.2
emulation), using gcc 3.3.2 and  AIX ld.

What's the recommanded CFLAGS, LDFLAGS to be used ?

Regards
Permalink | Reply | 0 comments |
headers
sternmarc | 2 May 2005 14:47
Picon

Re: SSL error trapping

I got it working !
Here is my solution. Questions 1 & 4 still remain.
The additional module (ssl_error) also works, although I need to fine-tune it.
 
Feel free to criticize and enhance.
 
Marc
 
-------------------
 
In 'ssl_hook_Access( )' (ssl_engine_kernel.c), the last line can be replaced by:
 
    { /* MSTERN: SSL errors trapping */
        const char *ssl_client_verify = ssl_var_lookup( r->pool, r->server, r->connection, r, apr_pstrdup(r->pool, "SSL_CLIENT_VERIFY") );
        if ( ! ssl_client_verify ) {
      ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0, r->server, "Unable to get SSL Verification STATUS");
      return HTTP_INTERNAL_SERVER_ERROR; /* cannot find ssl_var_lookup( ) */
     }
 
        if ( ! *ssl_client_verify ) return HTTP_INTERNAL_SERVER_ERROR; /* not in a SSL session */
 
        if ( strcmp(ssl_client_verify, "NONE") == 0 ) return HTTP_INTERNAL_SERVER_ERROR; /* SSL negociation not finished */
 
     ap_log_error(APLOG_MARK, APLOG_NOERRNO | APLOG_DEBUG, 0, r->server, "Certificate Verification Status: %s", ssl_client_verify);
     if ( strcmp(ssl_client_verify, "SUCCESS") == 0 ) return DECLINED;
     if ( strncmp(ssl_client_verify, "GENEROUS", 8) == 0 ) return DECLINED;
    }
 
    apr_table_setn(r->notes, "ssl-access-forbidden", "1");
 
    { /* Check if mod_ssl_error is loaded */
        extern AP_DECLARE_DATA module *ap_top_module;
        module *m;
        for ( m = ap_top_module; m; m = m->next )
            if ( strcmp(m->name, "mod_ssl_error.c") == 0 ) return DECLINED;
    }
    return HTTP_FORBIDDEN;
----- Original Message -----
Sent: Friday, April 29, 2005 12:26 PM
Subject: SSL error trapping

In case a SSL connection fails because a certificate is expired, or a CRL is unavailable, etc., the browser receives a SSL error that results in a cryptic technical error displayed to the user - sometimes only an error number like in Firefox. In such a situation, the SSL connection could be established, and a HTTP_FORBIDDEN (403) error returned. By adding another module, It is even possible to trap the exact SSL error and redirect to a page with the specific error message ("Your certificate is expired", "We cannot check the validity of the certificate - retry later", ..).
 
I plan to add all of this, but I'd like to check with everybody the best design and implementation.
 
Technical description (based on 2.0.54):
In ssl_io_filter_connect( (ssl_engine_io.c), we have 2 cases (at line 1147 and 1173) where the connection may break because of certificates verification/validation problem:  ' return ssl_filter_io_shutdown(filter_ctx, c, 1); '
If we do not return, we can trap the error in 'ssl_hook_Access( )' (ssl_engine_kernel.c).
At the end, instead of returning DECLINED, we have to check the certification verification result, then return either DECLINED or HTTP_FORBIDDEN.
This is quite generic; then we may use another module to make redirections depending on the exact error.
 
Questions and choices:
 
1. Could this be accepted as a standard feature (thus for everybody), or should I use
    - a compilation flag
    - a run-time directive
 
2. Does the other module trapping the 'hook_access' receive the control in case of the previous module returns a HTTP_FORBIDDEN error ?
If not, we could detect at run-time that the trapping module is loaded (how exactly ?), and, in this case, return DECLINED.
 
3. To check the certification verification process, I can use the string "SSL_CLIENT_VERIFY", but isn't there any real error code (int) available ? It would be cleaner to use the exact OpenSSL error codes than a string. I cannot find this code, even inside 'ssl_hook_Access( )' in ssl_engine_kernel.c. Awk ...
 
4. Should this trapping be extended to other non fatal SSL errors ? Is it also possible to trap fatal errors and redirect to HTTP ?
 
If you have other remarks or ideas, please tell me.
 
Marc
Permalink | Reply | 7 comments |
headers
Rici Lake | 2 May 2005 16:25

Re: [1.3 PATCH] rework suppress-error-charset feature


On 1-May-05, at 7:04 PM, Jeff Trawick wrote:

> I found a description of the problem:
>
>> When Apache issues a redirect in response to a client request, the 
>> response
>> includes some actual text to be displayed in case the client can't 
>> (or doesn't)
>> automatically follow the redirection. Apache ordinarily labels this 
>> text according
>> to the character set which it uses, which is ISO-8859-1.
>>
>> However, if the redirection is to a page that uses a different 
>> character set, some
>> broken browser versions will try to use the character set from the 
>> redirection text
>> rather than the actual page. This can result in Greek, for instance, 
>> being
>> incorrectly rendered.

If the action is required to compensate for a browser bug, wouldn't it 
be better to leave it as an environment variable and set it with 
BrowserMatch?
Permalink | Reply | 3 comments |
headers
Dmitri Tikhonov | 2 May 2005 21:14

Re: [PROPOSAL] Branch 2.1.x on May 13

Why do I suddenly have the "I Have A Dream" speech flashes? ;-)

   - Dmitri.

Paul Querna wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I think that most other developers agree that 2.1.x/trunk has enough
> features for a 2.2.x GA branch.
> 
> I believe 2.1.x is a moving target.
> 
> I think it is hard to stabilize a moving target.
> 
> I believe we should always keep trunk open for development.
> 
> I believe in order to create a stable 2.1.x, in preparation for a 2.2.x
> GA branch.
> 
> I think we should branch 2.1.x from trunk to stabilize it.
> 
> Once 2.1.x is in a branch, I believe trunk should become 2.3.x.
> 
> I believe having 2.1.x in a stabilization branch will speed the release
> of 2.2.x.
> 
> I believe that 2.1.x should have a set branch date.  Based on past
> history, I do not think we have been successful without a set date.
> 
> I am proposing the branch date be May 13, 2005.
> 
> Votes/Comments/Alternatives/Ideas/etc are all welcome.
> 
> Thanks,
> 
> - -Paul
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> 
> iD8DBQFCcrj/94h19kJyHwARAr0uAKC2giVIv+alNrM2WATOa6QZKN+58QCgktoe
> i/FE+UING3GZU80G/NEpeX4=
> =DCRq
> -----END PGP SIGNATURE-----
Permalink | Reply | 0 comments |
headers
Justin Erenkrantz | 2 May 2005 21:18
Gravatar

Re: [PROPOSAL] Branch 2.1.x on May 13

--On Friday, April 29, 2005 3:45 PM -0700 Paul Querna 
<chip <at> force-elite.com> wrote:

> I am proposing the branch date be May 13, 2005.

++1.  -- justin
Permalink | Reply | 0 comments |
headers
Jim Jagielski | 2 May 2005 21:26
Favicon

Re: [PROPOSAL] Branch 2.1.x on May 13

I'm +1 for branching 2.2-alpha... However, there are 2 outstanding
show-stoppers. Do we expect these to be addressed before the branch.
I think so, especially if they require API changes
Permalink | Reply | 5 comments |
headers
Justin Erenkrantz | 2 May 2005 21:28
Gravatar

Re: [PROPOSAL] Branch 2.1.x on May 13

--On Monday, May 2, 2005 3:26 PM -0400 Jim Jagielski <jim <at> jaguNET.com> 
wrote:

> I'm +1 for branching 2.2-alpha... However, there are 2 outstanding
> show-stoppers. Do we expect these to be addressed before the branch.
> I think so, especially if they require API changes

Why couldn't we fix those up after the branch?  The point would be to stop 
making 2.1.x a moving target so that we can fix the showstoppers.  -- justin
Permalink | Reply | 4 comments |
headers
Jim Jagielski | 2 May 2005 21:33
Favicon

Re: [PROPOSAL] Branch 2.1.x on May 13

Justin Erenkrantz wrote:
> 
> --On Monday, May 2, 2005 3:26 PM -0400 Jim Jagielski <jim <at> jaguNET.com> 
> wrote:
> 
> > I'm +1 for branching 2.2-alpha... However, there are 2 outstanding
> > show-stoppers. Do we expect these to be addressed before the branch.
> > I think so, especially if they require API changes
> 
> Why couldn't we fix those up after the branch?  The point would be to stop 
> making 2.1.x a moving target so that we can fix the showstoppers.  -- justin
> 

I thought the whole idea about having a 2.1 dev version was to avoid
monkeying around with the API and the problems when we were doing
1.3 and 2.0. Once we branch, it is possible that we'll run into
issues that may require a bump, but I think entering into a 2.2
tree "expecting" one may not be prudent. And it's only the
2nd showstopper which could be considered "valid" enough to
delay the branch.

--

-- 
===========================================================================
   Jim Jagielski   [|]   jim <at> jaguNET.com   [|]   http://www.jaguNET.com/
    "There 10 types of people: those who read binary and everyone else."
Permalink | Reply | 2 comments |
headers
Nick Kew | 2 May 2005 21:34

Re: [PROPOSAL] Branch 2.1.x on May 13

Justin Erenkrantz wrote:

> Why couldn't we fix those up after the branch?  The point would be to
> stop making 2.1.x a moving target so that we can fix the showstoppers. 

+1 on that.  Not on the timing, though: I won't have time for apache
until after Xtech[1], so that's a definite abstension on anything
happening on May 13th.

[1] where I'm giving a presentation on Apache as a platform for XML
    apps on the Web.

--

-- 
Nick Kew
Permalink | Reply | 0 comments |

Gmane