A fatal 301 redirect...

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

A fatal 301 redirect...

Pierre Couderc
I did use wrongly a 301 redirect....

I have corrected now, but the redirect remains.

I use wget :

nous@pcouderc:~$ wget https://www.ppp.fr
--2018-09-17 23:52:44--  https://www.ppp.fr/
Resolving www.ppp.fr (www.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
78.234.252.95
Connecting to www.ppp.fr
(www.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://test.ppp.fr/ [following]
--2018-09-17 23:52:44--  https://test.ppp.fr/
Resolving test.ppp.fr (test.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
78.234.252.95
Connecting to test.ppp.fr
(test.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.3’....

In access.log :

2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET /
HTTP/2.0" 200 21511 "-" "Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36"
2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET
/fuveau.png HTTP/2.0" 404 271 "https://test.ppp.fr/" "Mozilla/5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81
Safari/537.36"


I am pretty sure that I have removed the fatal redirect, and I have
checked that   the only 301 remaining are on port 80 :
     location / {
         return 301 https://$server_name$request_uri;
     }

So I suppose there is a cache somewhere where nginx keeps its secret and
fatal 301 ? How can I remove it ?

Thanks

PC
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: A fatal 301 redirect...

Jeff Dyke
I think this problem is better solved allowing 80 to be open and a separate server block.  Since i terminate from haproxy, from memory something like this, in the same vhost file.  Obviously you can listen here on H/2 if you want to as well.

server {
   listen 80 default_server;
  server_name test.ppp.fr;
  return 301 https://$server_name$request_uri;
}

Best,
jeff

On Mon, Sep 17, 2018 at 6:10 PM Pierre Couderc <[hidden email]> wrote:
I did use wrongly a 301 redirect....

I have corrected now, but the redirect remains.

I use wget :

nous@pcouderc:~$ wget https://www.ppp.fr
--2018-09-17 23:52:44--  https://www.ppp.fr/
Resolving www.ppp.fr (www.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
78.234.252.95
Connecting to www.ppp.fr
(www.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://test.ppp.fr/ [following]
--2018-09-17 23:52:44--  https://test.ppp.fr/
Resolving test.ppp.fr (test.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
78.234.252.95
Connecting to test.ppp.fr
(test.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘index.html.3’....

In access.log :

2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET /
HTTP/2.0" 200 21511 "-" "Mozilla/5.0 (X11; Linux x86_64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36"
2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET
/fuveau.png HTTP/2.0" 404 271 "https://test.ppp.fr/" "Mozilla/5.0 (X11;
Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81
Safari/537.36"


I am pretty sure that I have removed the fatal redirect, and I have
checked that   the only 301 remaining are on port 80 :
     location / {
         return 301 https://$server_name$request_uri;
     }

So I suppose there is a cache somewhere where nginx keeps its secret and
fatal 301 ? How can I remove it ?

Thanks

PC
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: A fatal 301 redirect...

Maxim Dounin
In reply to this post by Pierre Couderc
Hello!

On Tue, Sep 18, 2018 at 12:10:22AM +0200, Pierre Couderc wrote:

> I did use wrongly a 301 redirect....
>
> I have corrected now, but the redirect remains.
>
> I use wget :
>
> nous@pcouderc:~$ wget https://www.ppp.fr
> --2018-09-17 23:52:44--  https://www.ppp.fr/
> Resolving www.ppp.fr (www.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
> 78.234.252.95
> Connecting to www.ppp.fr
> (www.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://test.ppp.fr/ [following]
> --2018-09-17 23:52:44--  https://test.ppp.fr/
> Resolving test.ppp.fr (test.ppp.fr)... 2a01:e34:eeaf:c5f0::fee6:854e,
> 78.234.252.95
> Connecting to test.ppp.fr
> (test.ppp.fr)|2a01:e34:eeaf:c5f0::fee6:854e|:443... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/html]
> Saving to: ‘index.html.3’....
>
> In access.log :
>
> 2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET /
> HTTP/2.0" 200 21511 "-" "Mozilla/5.0 (X11; Linux x86_64)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36"
> 2a01:e34:eeaf:c5f0::feb1:b1c9 - - [18/Sep/2018:00:04:34 +0200] "GET
> /fuveau.png HTTP/2.0" 404 271 "https://test.ppp.fr/" "Mozilla/5.0 (X11;
> Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81
> Safari/537.36"
>
>
> I am pretty sure that I have removed the fatal redirect, and I have
> checked that   the only 301 remaining are on port 80 :
>      location / {
>          return 301 https://$server_name$request_uri;
>      }
>
> So I suppose there is a cache somewhere where nginx keeps its secret and
> fatal 301 ? How can I remove it ?

In no particular order:

- There are no log lines in the access log coresponding to the
  requests you've made with wget.  This means that either you are
connecting to the wrong server (check the IP address) or logging
is not properly configured (check your logging configuration).

- There are no "secret caches" in nginx.  The only caches are ones
  explicitly configured using coresponding configuration
directives - usually proxy_cache for HTTP proxying.

- A common mistake is to change configuration without actually
  reloading it.  Make sure to reload the configuration after
changes, and make sure to look into error log to find out if it
was actually reloaded or the configuration reload failed.

- If in doubt, looking into full configuration as show with "nginx
  -T" might help.  If still in doubt, the most advanced (yet
low-level) instrument is debug log
(http://nginx.org/en/docs/debugging_log.html).

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: A fatal 301 redirect...

Pierre Couderc


On 09/18/2018 02:55 AM, Maxim Dounin wrote:

> Hello!
>
> On Tue, Sep 18, 2018 at 12:10:22AM +0200, Pierre Couderc wrote:
>
>> I did use wrongly a 301 redirect....
>>
>> I have corrected now, but the redirect remains.
>>
>> I
>> In no particular order:
>>
>> - There are no log lines in the access log coresponding to the
>>    requests you've made with wget.  This means that either you are
>> connecting to the wrong server (check the IP address) or logging
>> is not properly configured (check your logging configuration).
Mmm... I double check
>>
>> - There are no "secret caches" in nginx.  The only caches are ones
>>    explicitly configured using coresponding configuration
>> directives - us
Thank you, I needed thsi answer.
>> ually proxy_cache for HTTP proxying.
>>
>> - A common mistake is to change configuration without actually
>>    reloading it.  Make sure to reload the configuration after
>> changes, and make sure to look into error log to find out if it
>> was actually reloaded or the configuration reload failed.
Oh, I have well reloaded or restarted  nginx 10 or 100 times !!
>>
>> - If in doubt, looking into full configuration as show with "nginx
>>    -T" might help.
Oh yes, after painfull experience (all sites stopped!!), I never change
a line in config file without testing it thyis way!!
>>   If still in doubt, the most advanced (yet
>> low-level) instrument is debug log
>> (http://nginx.org/en/docs/debugging_log.html).
Thank you, this is the only way...

Thank you to help me to think.
PC
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx