Why do I have 404 Not Found when Clicking home wordpress - wordpress

The Situation
Every time I click the home button below I find thaty it takes me to 404 not found as below that:
Wordpress dashboard
Error
I am not sure why this is occuring, but it seems to be redirecting to away from the port:8080 but I have set the wp_options site_url and home_url to http://localhost:8080/wordpress within phpAdmin. How could I fix this?
======
EDIT:
The behavior when looking in the log in the console after clicking the home button is:
Request URL: http://localhost:8080/wordpress/
Request Method: GET
Status Code: 301 Moved Permanently (from disk cache)
Remote Address: [::1]:8080
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Wed, 03 Feb 2021 17:40:28 GMT
Location: http://localhost/wordpress/
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1h PHP/7.4.13
X-Powered-By: PHP/7.4.13
X-Redirect-By: WordPress
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Followed by:
Request URL: http://localhost/wordpress/
Request Method: GET
Status Code: 404 Not Found
Remote Address: [::1]:80
Referrer Policy: strict-origin-when-cross-origin
Connection: Keep-Alive
Content-Length: 196
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 05 Feb 2021 06:59:33 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.46 (Win64) PHP/7.4.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
wp_admin settings

You still have to call your frontend under port 8080
localhost:8080/wordpress
EDIT:
Have a look here: themeisle.com/blog/install-xampp-and-wordpress-locally

Related

Go-reverseproxy interferes with .net [Authorize] attribute

I am running an ASP.NET MVC web application with Vue.js as frontend. For access control management, I am using pritunl-zero, a zero-trust reverse-proxy written in Go.
Locally the app works fine with anonymous authentication but deployed and protected from the proxy every method call that need auth will be denied with 401.0 from the IIS10 web server.
When I remove the proxy from the infrastructure it works.
Protected method call (eg)
[Authorize]
[HttpPut, Route("api/ping"), ResponseType(typeof(WorkflowDto))]
public IHttpActionResult PingWorkflow(WorkflowCommentDto commentDto)
Vue frontend log in console
createError.js:16
Uncaught (in promise) Error: Request failed with status code 401
at e.exports (createError.js:16:15)
at e.exports (settle.js:17:12)
at XMLHttpRequest.O (xhr.js:66:7)
The HTTP-header causing 401 response
GET /api/workflow/ping HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Cookie: pritunl-zero=MTY1NzY5OTc0NHxEdEU...
Host: workflow.host.de
Pragma: no-cache
Referer: https://workflow.host.de/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
The working HTTP-header
:authority: wf.host.de
:method: GET
:path: /api/workflow/Ping
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
cache-control: no-cache
cookie: pritunl-zero=MTY1Nzc3NjkwOHxZTVRUWUF5d0s0c180aTB...; pritunl-zero=MTY1NzgwMTE3MnxlWk9vYkZ2ZGQ0TTdVZmZKODdWb19SRzFSV...
pragma: no-cache
referer: https://wf.host.de/
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
The response from server (that one works)
cache-control: no-cache
content-length: 214
content-type: application/json; charset=utf-8
date: Thu, 14 Jul 2022 12:25:09 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
strict-transport-security: max-age=0; includeSubDomains; preload
x-aspnet-version: 4.0.30319
x-powered-by: ASP.NET
Response from server (401)
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 61
Content-Type: application/json; charset=utf-8
Date: Wed, 13 Jul 2022 08:09:12 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/10.0
X-Aspnet-Version: 4.0.30319
X-Powered-By: ASP.NET
Has anyone any hint how to fix this, that the application can work with the proxy?
What I tried:
New IIS with new site and new deployment
Many web.config settings regarding anonymous authentication
Different configs regarding the application pool
Latest update from pritunl
Thanks in advance for any hint.

DirectUpload fails with BadDigest DigitalOcean S3 ActiveStorage

I'm trying to upload a file but I get an error message like the following:
https://sapco.nyc3.digitaloceanspaces.com/b3vcchphzgj5m8p6ld51yk7867uu?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=QTHCA5KKQUHAKMMATAIP%2F20200503%2Fnyc3%2Fs3%2Faws4_request&X-Amz-Date=20200503T214158Z&X-Amz-Expires=10800&X-Amz-SignedHeaders=content-md5%3Bcontent-type%3Bhost&X-Amz-Signature=7b77a0f1551a262586980b709fdc44a2bc173ab6ae7279385e831493b1d13e53
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>BadDigest</Code>
<BucketName>sapco</BucketName>
<RequestId>tx000000000000013462bc9-005eaf36fb-3518e03-nyc3a</RequestId>
<HostId>3518e03-nyc3a-nyc</HostId>
</Error>
How can I debug this further?
So far I have tried:
Resetting my Access and Secret keys.
At first I thought this was related to PWA-related work, but I migrated to an earlier branch and have the same issues.
Tried different files: each have the same error.
Happens both in prod. and locally.
Update 1: This randomly started working again on production. However it's still broken locally.
With the same file I have the 2 paths for the PUT request that leads to the error above.
https://sapco.nyc3.digitaloceanspaces.com/11eego5a6r9b4tslx7cex4p9x45u?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=QTHCA5KKQUHAKMMATAIP%2F20200504%2Fnyc3%2Fs3%2Faws4_request&X-Amz-Date=20200504T005319Z&X-Amz-Expires=10800&X-Amz-SignedHeaders=content-md5%3Bcontent-type%3Bhost&X-Amz-Signature=8d2037f7370eb137facc9d813fe35ed34e055313af06cd66819a72d886dfb018
https://sapco.nyc3.digitaloceanspaces.com/z4vc7ujtvid0akqfn4uou46407zl?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=QTHCA5KKQUHAKMMATAIP%2F20200504%2Fnyc3%2Fs3%2Faws4_request&X-Amz-Date=20200504T005405Z&X-Amz-Expires=10800&X-Amz-SignedHeaders=content-md5%3Bcontent-type%3Bhost&X-Amz-Signature=b4b28cebe56a9b6c12ddfb2cc335b84080a3bfc5e34e2c66e19001230f8b7512
The issue must be related to the way X-Amz-Signature is computed.
Digging further with bundle open activestorage I can see it's roughly here. https://cutt.ly/6yjc7u1
I verified the Content-Length and Content-MD5 are both the same (vs local and prod). (123803 and ujNHxwCuwZ1mak927GUX3g== respectively).
Update 2: I tried this in Firefox with the same image and no problem locally. There must be something fishy going on with the cache. I then tried an Incognito window and that also seemed to work. Finally, I did a hard refresh in Chrome and now I've unblocked myself. Didn't quite figure out what was going on but leaving a final piece of information for anyone else:
Chrome Request Headers (Not Working, 400 Error)
PUT /lw5lufemkgb7ww83pdc56qg2gb0j?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=QTHCA5KKQUHAKMMATAIP%2F20200504%2Fnyc3%2Fs3%2Faws4_request&X-Amz-Date=20200504T013900Z&X-Amz-Expires=10800&X-Amz-SignedHeaders=content-md5%3Bcontent-type%3Bhost&X-Amz-Signature=1ea88bf8550d9bab67b5bca3aa97f7b15f1a44e117dd4f5cea0744c898f70684 HTTP/1.1
Host: sapco.nyc3.digitaloceanspaces.com
Connection: keep-alive
Content-Length: 0
Pragma: no-cache
Cache-Control: no-cache
Accept: */*
DNT: 1
Content-MD5: ujNHxwCuwZ1mak927GUX3g==
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
Content-Type: image/jpeg
Origin: http://localhost:3000
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en
Firefox Request Headers (Works)
Host: sapco.nyc3.digitaloceanspaces.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: image/png
Content-Length: 254924
Referer: http://localhost:3000/
Content-MD5: z0lzYqq/S1TYxKqL0rJMPw==
Origin: http://localhost:3000
DNT: 1
Connection: keep-alive
Chrome Request Headers (Worked)
Host: sapco.nyc3.digitaloceanspaces.com
Connection: keep-alive
Content-Length: 123803
Pragma: no-cache
Cache-Control: no-cache
DNT: 1
Content-MD5: ujNHxwCuwZ1mak927GUX3g==
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36
Content-Type: image/jpeg
Accept: */*
Origin: http://localhost:3000
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: http://localhost:3000/
Accept-Encoding: gzip, deflate, br
Accept-Language: en
Hard refreshing resolved the issue.

Server response header states status code 301 despite correct hostname

I've made a simple client socket in c that has been mostly successful.
The problem I'm having is my client socket receives a 301 status from, ironically, www.w3.org.
Observe, when I send the following GET with my client c socket
GET / HTTP/1.1
Host: time.com
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
I receive
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 12 Nov 2015 08:44:34 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Thu, 12 Nov 2015 08:40:48 GMT
Cache-Control: max-age=74, must-revalidate
X-nananana: Batcache
Vary: Cookie
X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
X-Pingback: http://time.com/xmlrpc.php
X-UA-Compatible: IE=edge,chrome=1
Link: <http://ti.me/nACNOw>; rel=shortlink
Content-Encoding: gzip
X-ac: 4.ord _dca
However, when I send a GET request to www.w3.org.
GET / HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
I receive
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: http://www.w3.org/
Connection: close
When google chrome sends a similar GET to www.w3.org
GET / HTTP/1.1
Host: www.w3.org
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
The server responds with
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=600
Content-Length: 39276
Content-Location: Home.html
Content-Type: text/html; charset=utf-8
Date: Sun, 15 Nov 2015 04:40:47 GMT
ETag: "996c-524790d293380;89-3f26bd17a2f00"
Expires: Sun, 15 Nov 2015 04:50:47 GMT
Last-Modified: Sat, 14 Nov 2015 05:00:14 GMT
P3P: policyref="http://www.w3.org/2014/08/p3p.xml"
Server: Apache/2
TCN: choice
Vary: negotiate,accept
Why does my client's GET receive a 301 despite its near equivalence with Chrome's GET?
Do some websites have a strict set of required HTTP header fields?
Is there a bigger picture that I'm missing?
w3.org enforces the canonical URL www.w3.org with a permanent redirect. Requesting just w3.org will result in a HTTP 301. The canonical URL is a matter of preference so it shouldn't be assumed that the non-prefixed URL will always redirect to the www prefixed one.

IIS6 Compression only working over HTTPS

We have recently enabled compression in IIS6 for our ASP.NET applications (some 2.0 some 4.0) and have found that GZip is only being performed when the request is made over HTTPS.
This problem is being seen on all servers in our web farm. I have also checked that the same problem exists regardless of the browser used.
I've searched for over an hour and can't find anything on this, so hoping someone may be able to help. Examples follow
HTTP Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Referer: http://www.google.co.uk
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTP Response (not GZipping):
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 65568
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 26 Sep 2013 09:26:46 GMT
HTTPS Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTPS Response (GZip working):
HTTP/1.1 200 OK
Cache-Control: private
Date: Thu, 26 Sep 2013 09:29:39 GMT
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
UPDATE
I've run a request trace in IIS - the offending requests have the following line
IISCompression DYNAMIC_COMPRESSION_NOT_SUCCESS "NO_MATCHING_SCHEME"

Can't find the correct header for a request on Windows server

I made an HTML page with some JavaScript that works fine on my laptop on Linux, but fails when I upload it on a Windows server. I think it is a header issue so I am not writing the Ajax code, but the request headers :
Ajax Request :
GET /index-1.html HTTP/1.1
Host: mydomain.com
Connection: keep-alive
Accept: undefined
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1553.0 Safari/537.36 SUSE/30.0.1553.0
Referer: http://mydomain.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Server Answer :
HTTP/1.1 406 Not Acceptable
Content-Type: text/html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 19 Sep 2013 19:40:44 GMT
Content-Length: 1346
What should I set the headers to?
If you actually read the description of status code 406 you'll quickly find out that the problem is likely caused by "accept: undefined".

Resources