----- Original Message ----- From: "sterling" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 12:59 AM Subject: Re: 2_0_28 tarballs rolled and available
> Hi - > > I still have an outstanding bug (and patch) that hasn't gotten a response. > I consider it a showstopper. Given the current default config simply add > a <Location /> stanza with auth enabled and that triggers the bug I > reported previously (the one where headers filters are never called). > > There is a workaround - to disable the ErrorDocument stuff - but still, it > seems to me like it should at least be double checked before 'beta'. ----- Original Message ----- From: "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 12:06 AM Subject: RE: 2_0_28 tarballs rolled and available > Compiles and installs fine on HP-UX !!.. I did some minimal tests and it > passes.. +1 for beta (ofcourse, i'd have loved to have the SSL session > caching stuff in the beta itself, but if it requires more time for review, > it's fine with me).. I think we _MISSED_ something here, there will be more than a single beta ;) John's observation that we have a problem with authentication of the /error/ locations, that fouls the HTTP headers entirely (against the RFC) is certainly legitimate, and is (everyone would agree) a showstopper to GA. But this can be worked around in config, so it isn't truly a showstopper to beta. Agree here with Madhu that we want the SSL session cache, before GA. Agree with rbb that we need some better proxy answers, before GA. Agree with Brian/Mladen that we have more optimization to do with headers and our overall table API, to enforce some type safety for future changes. And I have these three thorns, first and foremost negotiation (I'm getting some help to actually build the solution based on predefined expectations by setting up the tests _before_, while I twist the patch into correctness ;) And the fact that we don't yet die in core, in fact we don't die in already by ap_process_request_internal, if there is a file request that doesn't go through the dir/file walks (wasn't an absolute path or the module has a bug.) And some general, last minute thoughts on assuring our envvars are UTF-8 on Win32 (crucial to invoking everything based on UTF-8 assumptions.) Which all goes very nicely to DougM's work on variables, and the fact that we need some path-split API for APR, since win32 paths contain spaces, and are semi-colon seperatated, while unix'es are colon seperated, possibly quoted, potentially escaped [eeek!] And my Opinion on the Question? Yes - .28 is most certainly a BETA! Bill
