Re: TLSv1.3
well well if its not BANNED USER Reindl harrold using a ghost account On Tue, Apr 3, 2018 at 5:02 AM, li...@rhsoft.net wrote: > > > no, it's just an opinion based on the Chrome will penalty non-https in > general (bseides: the ACME challenge is happy with a automatic rediect > to https even if it's a self-signed certificate) > > that opinion completly ignores setups where the load-balancer does >
Re: TLSv1.3
Am 02.04.2018 um 20:56 schrieb Helmut K. C. Tessarek: > On 2018-03-29 04:16, Stefan Eissing wrote: >> Besides, except for data center setups, Apache will be used *only* >> with https: (and http: redirects to https:) very, very soon. That >> shifts the average expertise of an admin setting up a https: site. > > This statement makes me a bit nervous. Are you saying that there won't > be a way to use Apache with http anymore? no, it's just an opinion based on the Chrome will penalty non-https in general (bseides: the ACME challenge is happy with a automatic rediect to https even if it's a self-signed certificate) that opinion completly ignores setups where the load-balancer does tls-offloading/caching and has a dediacted connection in a seperated network to the backend servers which are http-only forever the load-balancer can be http://trafficserver.apache.org/ as example which also does HTTP2-over-TLS for the client while the backend connection is also HTTP/1.1 forever - in that case mod_h2/mod_md are not part of the game and even mpm_prefork stays untouched
Re: TLSv1.3
Hello,
On 2018-03-29 04:16, Stefan Eissing wrote:
> Besides, except for data center setups, Apache will be used *only*
> with https: (and http: redirects to https:) very, very soon. That
> shifts the average expertise of an admin setting up a https: site.
This statement makes me a bit nervous. Are you saying that there won't
be a way to use Apache with http anymore? (Since I don't know what a
data center setup entails that is - new directive, http only setup, ...)
Also, the 'will be used' part is a bit puzzling. This part rather
suggests that all users will magically only use https from that point
forward. Or was it meant as "Apache will only use https anymore"?
I'm basically using https anyway, however there are connections that
*must* be plain http, e.g. the ACME challenge. I like to use my own
scripts for maintaining the certificates thus I am not using the Apache
module, which further means that I must have control over Apache's http
setup.
I'm doing something like this:
ServerName HOSTNAME:80
Alias "/.well-known/acme-challenge/"
"/COMMON_DIR/acme-challenge/.well-known/acme-challenge/"
Require all granted
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [QSA,L,R=301]
ServerName HOSTNAME:443
# Your "real" configuration here
Can you please elaborate on your above statement and clear that up for me?
Cheers,
K. C.
--
regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944
Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944
/*
Thou shalt not follow the NULL pointer for chaos and madness
await thee at its end.
*/
signature.asc
Description: OpenPGP digital signature
Re: Bugzilla open tasks by year
On Fri, Mar 30, 2018 at 11:50 AM, Luca Toscano wrote: > > 2018-03-26 11:35 GMT+02:00 Nick Kew : >> >> > As hackathon project it could be good to review some of those >> > older-than-2011 tasks and see which ones are good to keep and which ones >> > can >> > be closed for no-activity/stale/not-valid-anymore/etc.. >> >> Good idea. Deal collectively with some of those judgement-calls that >> stump a solo bug-blitz. >> >> What we perhaps also need is a review of our bugzilla categories and >> workflow. >> For example, sometimes a PR is submitted with a proposed patch likely to >> be useful >> for some but not appropriate for inclusion in standard HTTPD. I’ve always >> left those >> open, which leaves them as not-bugs in the bugzilla count. Maybe we could >> deal >> with those with a new RESOLVED category (RESOLVED-PATCH?) and update the >> docs to invite users to search patch-bugs? >> > > We could also use http://www.apache.org/dist/httpd/patches/ to collect > those, and then link them in bugzilla closing the task (one should be able > to find them if searching etc...). Those patches would get stale very soon > though, so not sure what's best; ideally a patch is either accepted or not, > and the correspondent task eventually closed to avoid polluting whoever is > triaging/resolving the open ones :) Because these are not "published" by httpd (due to not being appropriate), the /dist/httpd/ tree is very problematic. If a patches tree of "interesting things under consideration" is needed, that would fit better under the httpd.a.o/dev/ tree.
