Hello!
On Tue, Mar 03, 2015 at 03:14:50PM +0100, Michael Kliewe wrote:
> Hi again,
>
> On Mar 2, 2015, at 3:56 PM, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Mon, Mar 02, 2015 at 03:32:03PM +0100, Michael Kliewe wrote:
> >
> >> Hi Maxim,
> >>
> >> On Mar 2, 2015, at 3:14 PM, Maxim Dounin wrote:
> >>
> >>> Hello!
> >>>
> >>> On Mon, Mar 02, 2015 at 01:12:44PM +0100, Michael Kliewe
> >>> wrote:
> >>>
> >>>> with your changes there is a problem:
> >>>> nginx now just sends the header if the connection is
> >>>> encrypted. If the connection is not encrypted, then there is
> >>>> no header sent to the auth script.
> >>>> In the auth script I cannot distinguish between "user did not
> >>>> use encryption" and "nginx doesn't have the feature" (because
> >>>> of mixed nginx versions).
> >>>> With the original version of the patch this was possible.
> >>>
> >>> Try updating all your nginx instances before using the header
> >>> for something limiting, it is expected to resolve your
> >>> problem.
> >>>
> >>> Either way, the only safe thing to do if "nginx doesn't have
> >>> the feature" is to assume there is no SSL if SSL matters. And
> >>> that's what current behaviour encourages.
> >>
> >> You are kind of right, but currently I'm distinguishing between
> >> "encrypted", "not-encrypted" and "unknown", because we have
> >> different versions of nginx in different setups. I cannot update
> >> all nginx versions in parallel in all setups. That's why your
> >> tip does not help me ;-/
> >> I need to distinguish between "not-encrypted" and "unknown",
> >> because I want to warn all users still using not-encrypted
> >> connections. With your patch I cannot distinguish between them,
> >> and would send false warnings...
> >
> > So switch off warnings till the update is complete. That's an
> > easy way to go.
> >
> > Alternatively, you may use the "auth_http_header" directive
> > (http://nginx.org/r/auth_http_header) to distinguish between
> > various installations.
>
> I'm sorry, I don't really want to repeat my arguments, but as I
> said I don't have control over all nginx servers that are used.
> Some will be "older", some will be newer. And I cannot force
> "them" to introduce the auth_http_header to just send the nginx
> version or capability of sending Auth-SSL header or not...
If you can't, than just switch off warnings till the update is
complete, as already suggested.
> Filipe's patch is working fine since > 6 month, it's either
> sending 0 or 1. The 0 is an important information and should not
> be dropped.
>
> Can you tell me the disadvantage of sending "off" in case the
> connection is unencrypted? I don't really see the problem at the
> moment why you don't add the else branch, you are dropping
> information that is needed (and that was there in the original
> patch)... It's just 3 lines more code and doesn't hurt anybody,
> but provides important information to the auth script.
As already explained, the problem is that the header will be added
forever for all setups, and it will be waste of resources in all
these setups. It will be waste of resources in your setup as well
after the transition period.
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
