Encountering a situation where I redirect users with a 401 when they're not authorized to access a page. I have this in one of my routes:
res.redirect(401, '/login');
Seems simple enough, but the app loiters and doesn't redirect the user to /login. It just sits on a page similar to this:
Unauthorized. Redirecting to /login
Headers look fine too:
HTTP/1.1 401 Unauthorized
X-Powered-By: Express
Location: /login
Vary: Accept
Content-Type: text/html; charset=utf-8
Content-Length: 63
set-cookie: connect.sid=stuff; Path=/; HttpOnly
Date: Sun, 20 Nov 2016 02:20:07 GMT
Connection: keep-alive
The weird thing is that if I omit the status, the redirect happens normally:
res.redirect('/login'); // doesn't hang on page, redirect occurs immediately
I was under the impression that redirection would be automatic, but maybe not? Any insight?
401 is not a redirect status. Just use a regular (303) redirect instead – 401 is invalid if you’re not sending a WWW-Authenticate header anyway.
Related
HELP ME. how to send response code 301 with python, i tried to send with response
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://localhost/404.html
Content-Length: %d
but the server doesn't send URL to the web client
I recently made some changes to my website and wanted to inspect everything using google webmaster tools & update the sitemap using any site map generator i can find online.
However the sitemap generators fail to connect to my website and google claims the page to be unreachable i tried to remove my recently added .htaccess file but it didn't help
This is my .htaccess file which works fine for me. I can reach my page from all browsers with cleared cache etc ...
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^webdesign/(.*)$ /index.php?cl=$1
EDIT: Using Bing Webmaster Tools I receive:
HTTP/1.1 500 Internal Server Error
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Connection: close
Date: Tue, 26 Jan 2016 07:16:56 GMT
Pragma: no-cache
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Server: Apache/2.2.31 (Unix)
Set-Cookie: sec_session_id=bq05b1i45qerls9crr9pv1cgm7; path=/; HttpOnly
Set-Cookie: lang=de; expires=Wed, 27-Jan-2016 07:16:56 GMT; Max-Age=86400
X-Powered-By: PHP/5.6.17
Doing some research I got this fixed - actually the Bing Webmaster tools returned the needed hint.
The page actually always returned error 500 but still returned content. Browsers seem to ingore this - but the crawlers & tools don't.
Therefore the Problem was inside my code which caused the 500 result. With this info I was able to track it down and get it working again.
Few days ago i'm post question about nodeMcu POST request, can't find any solution i'm try next on:
conn=net.createConnection(net.TCP, 0)
conn:on("receive", function(conn, payload) print(payload) end )
conn:on("connection", function(c)
conn:send("GET /wifi?temp=24&hum=12&alert HTTP/1.1\r\n"
.."Host: www.weatherman.bl.ee\r\n"
.."Cache-Control: no-cache\r\n"
.."Connection: keep-alive\r\nAccept: */*\r\n\r\n")
end)
conn:connect(80, "www.weatherman.bl.ee")
But this request respond me with 301 error
HTTP/1.1 301 Moved Permanently
Date: Mon, 02 Nov 2015 20:03:50 GMT
Server: Apache
Location: http://www.weatherman.bl.ee/wifi/?temp=24&hum=12&alert
Content-Length: 270
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1
Any ideas? May be problem with header's?
Postman execute request fine
The server probably enforces a / at the end of the request URL path.
If you use the URL with an extra /, that the redirect response tries to redirect you, you shouldn't get a 301 response back.
/wifi/?temp=24&hum=12&alert
↑
└ extra slash
Status 301 is not an error, everything from 200-399 is considered success. In the case of 301 there will be a location header, that you use to build the redirected URL. 301 is returned by the server in response to a given URL, the only thing you can do (besides using location to follow it) on the client is use a different URL.
For a image gallery I have to use a CDN. Therefor I create a subdomain
image.example.com
This subdomain points via CNAME to the CDN URL.
Old image path:
http://www.example.com/files/thumbs
I changed all image path in the gallery to:
http://images.example.com/files/thumbs
I need a 301 redirect from
http://www.example.com/files/thumbs
to
http://images.example.com/files/thumbs
I made already a post about this.
Redirect folder to subdomain with folder
In coordination with anubhava I open now a new question.
I tried this:
RewriteCond %{HTTP_HOST} ^(?:www\.)?example\.com$ [NC]
RewriteRule ^(files/thumbs/.*)$ http://images.example.com/$1 [L,R=301,NC]
and this:
RewriteRule ^(files/thumbs/.*)$ http://images.example.com/$1 [L,R=301,NC]
Both rules result in: Too many redirects / never ending.
Important:
When the CDN has cached the image, everything works as it should. The CDN need 2 request and the 3rd request is a hit. When the CDN has no hit (first or second request) the redirection is not working.
When the CDN miss the file, the local server serv the image. Is there a rule that fits my needs?
thank you very much
-----Added more informations about the problem----
We have 2 scenarios - HIT and MISS:
Scenario 1 - The HIT
Please check the following steps and have a eye on the X-Cache and the http Status Code on top:
1. curl -I http://images.example.com/files/thumbs/my-cache-hitting-image.jpg
HTTP/1.1 200 OK
Date: Fri, 27 Mar 2015 07:37:10 GMT
Content-Type: image/jpeg
Content-Length: 14525
Connection: keep-alive
Last-Modified: Thu, 19 Mar 2015 12:44:39 GMT
Cache-Control: max-age=2592000
Expires: Sun, 26 Apr 2015 07:37:10 GMT
Vary: User-Agent
Server: NetDNA-cache/2.2
X-Cache: HIT
Accept-Ranges: bytes
Now we check the redirect in action (open old url):
curl -I http://www.example.com/files/thumbs/my-cache-hitting-image.jpg
HTTP/1.1 301 Moved Permanently
Date: Fri, 27 Mar 2015 07:39:06 GMT
Server: Apache
Location: http://images.example.com/files/thumbs/my-cache-hitting-image.jpg
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Perfect - Job done!
Scenario 2 - The Miss
curl -I http://images.example.com/files/thumbs/my-cache-missing-image.jpg
HTTP/1.1 301 Moved Permanently
Date: Fri, 27 Mar 2015 07:41:27 GMT
Content-Type: text/html; charset=iso-8859-1
Content-Length: 278
Connection: keep-alive
Location: http://images.example.com/files/thumbs/my-cache-missing-image.jpg
Vary: Accept-Encoding
Server: NetDNA-cache/2.2
Expires: Sun, 26 Apr 2015 07:41:27 GMT
Cache-Control: max-age=2592000
X-Cache: MISS
Fazit: When there is a MISS, it will result in a Loop because the CDN gives the request back to the origin and the origin is doing this:
curl -I http://www.example.com/files/thumbs/my-cache-missing-image.jpg
HTTP/1.1 301 Moved Permanently
Date: Fri, 27 Mar 2015 07:26:13 GMT
Server: Apache
Location: http://images.example.com/files/thumbs/my-cache-missing-image.jpg
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1
Its a loop that never ends. Maybe there is a way to check via httaccess Cond the status Code?!
I found a workarround. Maybe anybody will need it:
When I want a redirect from old (indexed) url to cdn url and cdn give it back to origin url that is also the old url, its runs of course into a loop.
Solution: Create a different URL where the CDN can catch the files. Therefore do the following:
Create a subdomain - Example:
catcher.example.com (normal A record)
Point this subdomain to your root directory of the website. Has to be the same directory as the original website directory.
Add catcher.example.com to the origin URL in your CDN Settings.
Add a rewrite cond that will force the redirect ONLY when there is OLD url and NOT from our catcher.example.com
RewriteCond %{REQUEST_URI} ^/files/thumbs
RewriteCond %{HTTP_HOST} ^www.example.com$
RewriteRule ^(files/thumbs/.*)$ http://images.example.com/$1 [L,R=301,NC]
(do I need the first RewriteCond?) Just in case I have added.
Result: No loop anymore. Because that way the CDN can catch the files from the catcher.example.com and the OLD links getting a redirect to the apache without result in a loop. It doestn matter from where the CDN can catch the file as long its the same file with the same directory path.
First tests are successfull. When I am wrong, please correct me.
You may say it will look at Content-Disposition for file name, but I'm talking about where there's nothing in that header and also URL is not so straight forward like http://website.com/myfile.zip. I leave some examples here but wondering how browser (I use FireFox) find out the right name in save as dialog. Does it know the URL syntax for famous websites ?
download links in sourceforge.net
download links in cnet.com
download from your own localhost
I used Fiddler2 for reverse engineering.
URL: http://mesh.dl.sourceforge.net/project/npp-plugins/Function List/FunctionList Plugin v2.1/FunctionList_2_1_UNI_dll.zip
Fiddler output sample:
HTTP/1.1 200 OK
Date: Sat, 13 Nov 2010 22:46:31 GMT
Server: Apache/2.2.9 (Debian)
Last-Modified: Thu, 18 Feb 2010 04:35:26 GMT
ETag: "142a602c-1fe24-47fd87eed7f80"
Accept-Ranges: bytes
Content-Length: 130596
Connection: close
Content-Type: application/zip
EDIT: Problem is Content-Disposition is not set at final response, instead it at one of redirection. HttpWebRespose header contains last response header (AllowAutoRedirect = true). I need to keep track of all responses and check if there is a Content-Disposition then remember it. How ?
The do use content-disposition or any other standard method. See this example I just get from SourceForge using Live HTTP Headers:
HTTP/1.1 302 Found
X-Powered-By: PHP/5.2.9
Content-Disposition: attachment; filename="FunctionList_2_1_UNI_dll.zip"
Location: http://mesh.dl.sourceforge.net/project/npp-plugins/Function%20List/FunctionList%20Plugin%20v2.1/FunctionList_2_1_UNI_dll.zip
Content-Type: text/html
Content-Length: 0
Date: Sat, 13 Nov 2010 22:30:00 GMT
Server: lighttpd/1.4.26
Note that they also use a redirect, maybe you get confused by that.
If its not the filename attribute of the Content-Disposition header, its likely some HTTP 302 redirect, or a hidden iframe with the file download.