Апач ошибка 401

I currently have an application proxied through 2 separate web servers. One web server is running Apache 2.2 while the other web server is running Apache 2.4. While some of the configuration had to be changed to accommodate Apache 2.4, the configuration between these 2 web servers is essentially the same (we were upgrading web servers).

This application works fine when proxied through Apache 2.2, however when accessing the application through Apache 2.4 I run into an issue.

The application that I am accessing is constantly polling for data by sending out successive AJAX requests. After a certain amount of time/requests (does not seem to be consistent), the Apache 2.4 web server returns a 401 Unauthorized error causing the application to fail. Keep in mind that it works without issue for a period of time however the 401 error always presents itself within a couple of minutes.

When accessing the application via an internal IP or through the Apache 2.2 web server, I do not encounter this issue which leads me to believe Apache 2.4 is causing the issue. Something to do with the successive requests within a short period of time?

Is there a configuration setting that I need to include in Apache 2.4 in order for things to work properly? I am at a loss as to why the 401 error does not present itself initially (everything works fine initially), but does so after a short period of time.

Please let me know if you need any further information. I can provide any .conf files that are necessary. Your help is greatly appreciated.

Best Regards

EDIT: Apache 2.4 ‘apache2.conf’ file (comments removed):

Mutex file:${APACHE_LOCK_DIR} default

PidFile ${APACHE_PID_FILE}

Timeout 300

KeepAlive On

MaxKeepAliveRequests 100

KeepAliveTimeout 15

ServerLimit 2000

<IfModule event.c>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      150 
    ThreadLimit          64
    ThreadsPerChild      25
    MaxClients          2000
</IfModule>

User ${APACHE_RUN_USER}
Group ${APACHE_RUN_GROUP}

HostnameLookups Off

ErrorLog ${APACHE_LOG_DIR}/error.log

LogLevel debug

IncludeOptional mods-enabled/*.load
IncludeOptional mods-enabled/*.conf

Include ports.conf

<Directory />
    Options FollowSymLinks
    AllowOverride None
    Require all denied
</Directory>

<Directory /usr/share>
    AllowOverride None
    Require all granted
</Directory>

<Directory /var/www/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

AccessFileName .htaccess

<FilesMatch "^\.ht">
    Require all denied
</FilesMatch>

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\""     vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\""    combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

IncludeOptional conf-enabled/*.conf

IncludeOptional sites-enabled/*.conf

EDIT 2: Apache 2.4 Virtual Host Config

<VirtualHost *:80>
    ServerName application.url.com:80
    ServerAlias application.url.com
    ServerAdmin noreply@noreply.com

    DocumentRoot /sharedfilesystem/htdocs

    <Directory />
            Options -Indexes +FollowSymLinks
            AllowOverride None
    </Directory>

    <Directory /sharedfilesystem/htdocs>
            Options -Indexes +FollowSymLinks +MultiViews
            AllowOverride None
            Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/application.url.com/error.log

    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/application.url.com/access.log combined

    RewriteEngine On

    RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
    RewriteCond %{REQUEST_FILENAME} !/maintenance.html
    RewriteRule ^.*$ /maintenance.html [L]

    RewriteCond %{QUERY_STRING} !^$
    RewriteCond %{QUERY_STRING} ^referredBy=.*$ [NC]

    Include conf.d/*.conf
</VirtualHost>

EDIT 3: Apache 2.4 .conf file:

<Location "/ApplicationName">
    ProxyPass http://xx.x.x.xxx:8081/ApplicationName
    ProxyPassReverse http://xx.x.x.xxx:8081/ApplicationName
</Location>

Alias "/scripts" "/sharedfilesystem/scripts"
<Directory "/sharedfilesystem/scripts">
    Options None +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Alias "/css" "/sharedfilesystem/css"
<Directory "/sharedfilesystem/css">
    Options None +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Alias "/images" "/sharedfilesystem/images"
<Directory "/sharedfilesystem/images">
    Options None +FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

<Macro Template $templateName>
    AliasMatch (?i)^/$templateName(.*) "/sharedfilesystem/$templateName/htdocs$1"
    <Directory "/sharedfilesystem/$templateName/htdocs">
            Options None +FollowSymLinks
            AllowOverride None
            Require all granted
    </Directory>
</Macro>

Use Template TemplateName

EDIT 4: Output of CURL Command:

* About to connect() to application.url.com port 80 (#0)
*   Trying xx.xx.xx.xx... connected
> GET /ApplicationName HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: application.url.com
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Date: Wed, 10 Jan 2018 17:17:30 GMT
< Server: Apache-Coyote/1.1
< Location: http://application.url.com/ApplicationName/
< Content-Length: 0
< Content-Type: text/plain
<
* Connection #0 to host application.url.com left intact
* Closing connection #0

EDIT 5: Virtual Host error.log:

[proxy_http:error] [pid 2139:tid 140080089888512] (104)Connection reset by peer: [client xx.x.x.xx:57710] AH01102: error reading status line from remote server xx.x.x.xxx:8081, referer: http://application.url.com/ApplicationName/control?vi=jlsut7u1d05np
[proxy:error] [pid 2139:tid 140080089888512] [client xx.x.xx.xx:57710] AH00898: Error reading from remote server returned by /ApplicationName/entryFailure, referer: http://application.url.com/ApplicationName/control?vi=jlsut7u1d05np

EDIT 6: Virtual Host access.log showing successive 200 responses then 401 response:

xx.x.xx.xx - - [05/Jan/2018:15:47:34 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185254581&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:35 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185255012&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:35 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185254703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:35 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185255461&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:36 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185255913&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:36 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185255703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:36 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185256430&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:37 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185256994&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 626 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:37 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185256703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=23 HTTP/1.1" 200 627 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:37 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185257423&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:37 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185257888&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:38 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185257703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:38 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185258320&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:38 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185258760&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:39 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185258703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:39 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185259341&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:39 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185259900&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:40 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185259707&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:40 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185260345&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 385 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:40 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185260825&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 349 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:41 -0500] "GET /ApplicationName/rest/view/59oe744gqs05i/update?_=1515185260703&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 200 386 "http://application.url.com/ApplicationName/control?vi=59oe744gqs05i" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
xx.x.xx.xx - - [05/Jan/2018:15:47:41 -0500] "GET /ApplicationName/rest/view/7r3aa5jfn22ld/update?_=1515185261272&casPartySeq=490&casConfSeq=1054&casQaSeq=490&ctxSeq=24 HTTP/1.1" 401 345 "http://application.url.com/ApplicationName/control?vi=7r3aa5jfn22ld" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"

Источник

This is my VirtualHost configuration:

<VirtualHost *:80>

     ServerName example.com
     DocumentRoot /var/www/example.com/public

     <Directory /var/www/example.com/public>
             Options +FollowSymLinks
             AllowOverride All
             Require user user1 user2
     </Directory>

     <Location /error/401>
             Require all granted
     </Location>

     ErrorLog ${APACHE_LOG_DIR}/example.com.error.log
     LogLevel warn
     CustomLog ${APACHE_LOG_DIR}/example.com.access.log combined

     ErrorDocument 500 /error/500
     ErrorDocument 404 /error/404
     ErrorDocument 401 /error/401

</VirtualHost>

But still when I intentionally fail authentication (or when I directly open /error/401), I get this:

Unauthorized

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.

Additionally, a 401 Unauthorized error was encountered while trying to use an ErrorDocument to handle the request.

What am I doing wrong? According to the doc linked below, Location should be processed after Directory so this should work.

http://httpd.apache.org/docs/current/sections.html#merging

EDIT:

Just so it’s clear, this is the problematic part:

Additionally, a 401 Unauthorized error was encountered while trying to use an ErrorDocument to handle the request.

Источник
Account Suspended

Error 400: Bad Request

If an HTTP request completely fails to adhere to the HTTP protocol, the web server may classify it as being abnormal and serve a 400 error page. This error shows that the request was not in a format that the server recognized.

This error is primarily an error in programming, either on the client or the server.

Error 401: Authorization Required (Unauthorized)

When encountering a 401: Authorization Required error it means that you simply entered the password incorrectly on a server login form. If you no longer remember the username and password, you can reset it by following the steps listed in this article.

Below is what a common 401 page looks like.

But do keep in mind that 401 pages can look very different from site to site.

For more information about Error 401, please see this Wikipedia article.

Error 403: Forbidden

While using the internet, you may run into an Error 403 – Forbidden page. This page appears when you don’t have access to the page you are trying to view. This can be caused by a few things, below we will cover the most common.

  • The folder you are trying to access does not have a index page and has indexing turned off.
    • You can check this in more detail by reading this article.
  • An incorrectly configured htaccess file
  • The file has incorrect permissions set (USER does not have read permissions).
    • You can look into this by following the steps in this article.

You can also check the error logs to attempt to get more details. For information on how to check the error logs.

Below is what a common 403 page looks like.

But do keep in mind that 403 pages can look very different from site to site.

For more information about Error 403, please see this Wikipedia article.

Error 404: Page Not Found

While using the internet, you may run into a 404: Page Not Found error. This means that you are accessing a page that does not exist. In most situations, its because the link that took you to the page was not updated to reflect a new file location. Below we will outline a few things you may want to check if you are seeing this error on your website.

Please keep in mind that links are cAsE-SenSiTive

  • If you are using a flat html website (not using a sript/application like wordpress). we recomend that you use FTP or the file manager to check if the file you are attempting to access is in the correct location.
  • If you are using a script/application like WordPress, you may want to make sure that the page is published and the link you are attempting to use is correct.
  • If the page was working before, you may want to check to see if other pages are affected. If they are, you may have a site wide issue such as a bad update for a script/software, incorrect use of redirects, etc.

Note: In some cases you may be redirected away from the original link to the home page, or another error page. Keep this in mind when debugging the issue.

Below is what a common 404 page looks like.

But do keep in mind that 404 pages can look very different from site to site.

For more information about Error 404, please see this Wikipedia article.

Error 405: Method Not Allowed

The 405 error page seldom occurs as it explicitly shows that the mail user agent(email client) in use is attempting to access the server via a restricted method. The error would show a problem with the client software.

Error 406: Not Acceptable

A 406 error occurs when the server is unable to accommodate a request for data in a specific format. However, most browsers accept any data received from the server. If you encounter this error, contact the software’s technical support for assistance.

Error 407: Proxy Authentication Required

A 407 error, similar to a 401 error, is a problem with authentication. The distinction is basically in how the server expects the authentication. While a server generating a 401 error requires direct authentication, a 407 error occurs when an authentication is required via a proxy.

Error 408: Request Time-Out

This error occurs when the server disconnects you from the client due to a long time has passed between the initial connection and the transfer of data.

Several possible issues can cause this problem, including a high load on the client matching, problems with your local area network, problems with your ISP, difficulties with the route to the server, and ultimately it could be caused by a high load on the server.

If you encounter this error, run a traceroute for any issues or delays:

How do I perform a traceroute?

Error 409: Conflicting Request

When a call to the server conflicts a set rule, the server may cause a 409 error to show that two requests conflict with one another. This issue is almost never caused by standard web server authority or security as those methods produce different errors. A 409 error page normally needs an application specific issue that is not defined by the HTTP protocol.

Error 410: Gone

A 410 error page, similar to a 404 error page, can sometimes be generated to indicate that the data requested is not available.  The primary difference between the two errors is that a 410 error page generates additional information to show that the data previously existed but is no longer available.  If a server has no process for recognizing if data previously existed, then a 404 error page is served.

Error 411: Content Length Required

The server may need a length of data to be specified when using HTTP protocols that require storing data on a server, such as PUT or POST.  If the length of data needs to be specified by the server and the request fails to define the length of data, the server returns a 411 error.

Error 412: Precondition Failed

If a browser or client, sending an HTTP data stream to the server, can incorporate specs for the data stream, this functionality is referred to as a precondition. If a precondition is required, but not satisfied, the server generates a 412 error.

This issue can only occur when a client-side application does not satisfy a spec set by itself, diagnose this issue as a problem with the client and identify the precondition that is not satisfied.

Error 413: Payload Too Large (Request Entity Too Large)

The 413 error code means that the server is rejecting a call since the request data stream is larger than the server is willing or able to process. What is or is not “too large” is contingent on the call the client is making and the restriction set on the server. The server might close the connection to deter the client from continuing the request.

If the issue is temporary, the server should generate a
Retry-After header field to show that the issue is temporary and when the client may try again.

Error 414: URI Too Long (Request-URI Too Long)

The 414 error page is triggered when the URL is set up in a way that successfully reaches the server, however, is too long for the server to interpret due to server constraints.

If you encounter this error, recode the website to utilize a shorter URL.

Error 415: Unsupported Media Type

When a browser or client uses an HTTP protocol to transfer data to the server, the server may require specifying the media type transmitted. A 415 error occurs when any of the following conditions are met:

  • The specified media type does not match the original media included in the request.
  • The original media provided in the request is conflicting with the current resource data.
  • The original media included is conflicting with the method specified in the HTTP request.

The majority of users do not encounter this error as it is a characteristic of programming issues with a specific feature, and needs development to fix.

Troubleshooting this issue requires you to analyze the media type that your client is trying to transfer via HTTP, and what kind of media type the request is claiming to send, and the expected media type by the server.

Error 421: Too Many Connections

The highest number of connections allowed from one IP is 8 for shared and reseller servers, if you experience a 421 error, this indicates that you have exceeded the max connections allowed. Additionally, you can no longer control your FTP connections via FTP Connections in SiteAdmin or cPanel; you must manage the FTP session via your FTP client.  For more information on managing FTP sessions, please review the article below.

FTP: Create and manage additional FTP accounts

Error 500: Internal Server Error

At some point, you may run into an error page that reads Internal Server Error or Error 500. This is whats known as a server error and can be caused by a large number of things. Below we have outlined some of the most common ones.

  • CHMOD is set to 777
    • For security reasons, we don’t allow permissions of 777. When you attempt to use this permission type, the page will display a internal server error. For more information about this, please see our CHMOD article.
  • A incorrectly configured htaccess file.
    • htaccess files are very powerful, but in turn when incorrectly used or configured, can cause errors. You can attempt to disable or comment out parts of the htaccess file to see what line is causing the issue.
    • One of the most common htaccess issues that would cause a internal server error is attempting to use php_flag. We don’t support the use of php_flags on our servers. Any custom php changes should be made through a .user.ini file.

There are a number of other reasons that may cause this error. Checking the error log is a good way of starting to narrow down the problem. For information on how to check the error logs.

Below is what a common 500 error looks like.


But do keep in mind that 500 errors can look very different from site to site.

Error 501: Not Implemented

This error message is usually due to a problem with the browser or client used to access the server. The error message means that the HTTP method utilized by the browser or client is not supported or recognized by the server. Also, the methods currently specified by the HTTP protocol are as follows: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, and CONNECT.

Error 502: Bad Gateway

This error message can generate in various forms(HTTP 502, Temporary Error (502), 502 Service quickly Overloaded,  and 502 Proxy Error). This error message occurs when one server receives an invalid response from another server that is trying to load a website or execute another request. The problem is often a network issue between servers on the internet.  You can take some measures to alleviate the issue such as use a different browser to load the site, refresh the page, start a new browsing session, or clear your browser cache.

Error 503: Service Unavailable

This status code usually occurs when your server is undergoing maintenance or temporarily overloaded. A 503 error lets visitors know that, although the service or data is temporarily not available, the website still exists.

Error 504: Gateway Timeout

When attempting to access a website and a response is not provided after a certain amount of time, a 504 error page may appear in your browser. 504 errors are usually the result of trying to reach a server that is either undergoing maintenance or not correctly functioning.

Error 505: HTTP Version Not Supported

If a client uses a version of the HTTP protocol that is no longer supported by the server, a 505 occurs. This error is rare and using a client that uses the current HTTP protocol standards resolves the issue.

Account Suspension

An encounter with the Account Suspended page is a strong indicator of some concerns with the account to which the website is linked. When an account is suspended, traffic to all the websites on the particular cPanel account in question are redirected to a generic account suspension page. When the account is then unsuspended, this redirect will be removed automatically.

The first cause of the suspension typically occurs when an account reaches delinquent billing status. If you are the account holder, you can review any outstanding invoices by logging into your BloxPortal (https://www.snapblox.com/portal). While logged into BloxPortal as the account holder, you can also update the payment information and pay payment for any outstanding invoices. After all outstanding invoices have been cleared up, your hosting will be unsuspended and your website(s) will return to full functionality.

If you encounter the suspended page, and your account is fully up to date in regards to billing, the suspension may be attributed to resource usage on your website. Depending on the type of hosting plan you have with us, you may have limits on how many shared (CPU, Memory, etc) resources you may use. If your account is found using to many of the shared resources our team will contact you via a ticket.For more information on the resource usage, you can check the resources overview section of our knowledgebase.

In the event you encounter the suspended page and your account is in good standing, please check your email messages or BloxPortal for communication from our staff. If you do not have any communication from our staff, please get in touch with us and we will investigate right away.

Источник

The Basics of 401 Unauthorized Apache Server

Welcome to our comprehensive guide on 401 Unauthorized Apache Server! If you have ever encountered this error code while browsing the internet, we are here to help you understand what it means and how to deal with it.

So, what exactly is 401 Unauthorized Apache Server? In simple terms, it is an HTTP status code that indicates the client – in this case, your web browser – has failed to provide the necessary authentication credentials to access the requested URL. This could happen for a variety of reasons, such as mistyping your login credentials, accessing a restricted page, or a server-side configuration issue.

The Origins of 401 Unauthorized Apache Server

The 401 Unauthorized Apache Server error code is part of the HTTP/1.0 specification, which was first introduced in 1996. It has since been adopted by newer versions of the HTTP protocol, including HTTP/1.1 and HTTP/2.0.

It is important to note that the Apache web server, which is a widely used open-source server software, is not the only server that can produce this error code. Other web servers such as Nginx, Microsoft IIS, and Lighttpd can also generate 401 Unauthorized responses.

How 401 Unauthorized Apache Server Works

When you access a webpage or resource on a server, your browser sends a request to the server, asking for permission to access the file. If the server requires authentication, it responds with a 401 Unauthorized status code, along with a WWW-Authenticate header, which specifies the authentication method to use.

At this point, your browser should prompt you to enter your login credentials. Once you provide the correct username and password, your browser sends another request to the server, this time including the authorization header with your credentials. If the server verifies your credentials, it will respond with a 200 OK status code and serve the requested content.

The Risks of 401 Unauthorized Apache Server

While 401 Unauthorized Apache Server may seem like a harmless error code, it can actually pose a security risk if not addressed promptly. For example, if an attacker repeatedly sends unauthorized requests to a server, they could cause a denial of service (DoS) attack, effectively taking down the website or service.

Additionally, if sensitive or confidential information is being transmitted over the network, an attacker could intercept the traffic and obtain the authentication credentials, allowing them to access the restricted content.

Fixing 401 Unauthorized Apache Server Errors

Now that you understand what 401 Unauthorized Apache Server is and why it matters, let’s dive into some practical ways to fix this error. Here are some common solutions:

Check Your Credentials

The first thing to check when you encounter a 401 Unauthorized Apache Server error is your login credentials. Make sure you are using the correct username and password, and that your caps lock key is not on. If you are unsure about your credentials, try resetting your password or contacting the website administrator for assistance.

Clear Your Browser Cache

If the error persists even after entering the correct login credentials, try clearing your browser cache and cookies. Sometimes, cached data can cause authentication issues, and clearing it can help resolve the problem.

Check Your URL

Make sure that you are trying to access the correct URL. If you have bookmarked a page or copied a link, double-check that it is not outdated or incorrect. Sometimes, mistyping a URL can also result in a 401 Unauthorized error.

Disable Browser Extensions

If none of the above solutions work, try disabling any browser extensions that may be interfering with your authentication. Ad blockers, VPNs, and other add-ons can sometimes cause issues with login forms, so check your browser settings and disable any suspect extensions.

Contact the Website Administrator

If all else fails, contact the website administrator or support team for assistance. They should be able to identify any server-side issues and provide guidance on how to resolve the error.

The Advantages of 401 Unauthorized Apache Server

While 401 Unauthorized Apache Server may seem like a nuisance, it actually offers several advantages, including:

Enhanced Security

The 401 Unauthorized error is a security feature that helps protect sensitive data and prevent unauthorized access. By requiring authentication, servers can ensure that only authorized users can access restricted content.

Standardized Protocol

The HTTP protocol and status codes are widely adopted and understood by web developers, making it easier to maintain and troubleshoot web applications.

Scalability and Flexibility

Web servers can use 401 Unauthorized responses to manage access to different types of content, users, and devices. This allows for more granular control over network resources and can help scale applications to meet growing demands.

The Disadvantages of 401 Unauthorized Apache Server

Despite its benefits, 401 Unauthorized Apache Server can cause several drawbacks, such as:

Compatibility Issues

Because the HTTP protocol and status codes are constantly evolving, some older browsers or devices may not support newer authentication methods, resulting in compatibility issues.

User Frustration

If users encounter 401 Unauthorized errors frequently, it can lead to frustration and decreased trust in the website or service. This could result in lower engagement, revenue, or customer loyalty.

Increased Server Load

If a server receives a high volume of unauthorized requests, it can put a strain on the server resources and impact performance for legitimate users.

The Technical Details of 401 Unauthorized Apache Server

Now that we have covered the basics of 401 Unauthorized Apache Server, let’s delve into the technical aspects of this error code. In this section, we will explore the following topics:

The Anatomy of a 401 Unauthorized Response

A 401 Unauthorized response consists of a status code, a message, and a WWW-Authenticate header. Let’s break down each component:

Status Code

Message

WWW-Authenticate Header

401

Unauthorized

Basic realm=”Restricted Area”

The status code 401 indicates that the client failed to provide valid authentication credentials. The message “Unauthorized” is a human-readable version of the status code. The WWW-Authenticate header specifies the authentication method to use, in this case, the Basic authentication scheme with a realm of “Restricted Area”.

The Different Types of Authentication Schemes

The authentication method specified in the WWW-Authenticate header can vary depending on the server configuration and the application requirements. Here are some common authentication schemes:

Basic Authentication

Basic authentication is the simplest and most widely used authentication scheme. It involves sending the username and password in plain text (base64-encoded) over the network. While this method is easy to implement, it is also insecure, as the credentials can be intercepted and decoded by a skilled attacker.

Digest Authentication

Digest authentication is a more secure alternative to basic authentication. It involves hashing the username and password values before sending them over the network. The server then compares the hash values with the stored passwords to authenticate the user. This method is less vulnerable to interception and replay attacks.

OAuth Authentication

OAuth authentication is a protocol that allows users to authenticate with a third-party service (such as Google or Facebook) instead of providing their own credentials. The user grants permission to the third-party app to access specific resources on their behalf. This method is increasingly popular for web applications that require social authentication.

The Troubleshooting Steps for 401 Unauthorized Apache Server

If you encounter a 401 Unauthorized Apache Server error, here are some steps you can take to troubleshoot the issue:

Step 1: Check the Server Logs

The first step in troubleshooting any server error is to check the server logs. The logs can provide valuable information about the root cause of the error, such as incorrect login credentials, expired tokens, or server misconfiguration.

Step 2: Verify Your Credentials

Double-check that you are using the correct username and password, and that your login credentials have not expired. If you are unsure about your credentials, try resetting your password or contacting the website administrator for assistance.

Step 3: Clear Your Browser Cache

If you have recently changed your login credentials, try clearing your browser cache and cookies to ensure that your browser is not using outdated data. Sometimes, cached data can cause authentication issues, and clearing it can help resolve the problem.

Step 4: Check the URL

Make sure that you are trying to access the correct URL. If you have bookmarked a page or copied a link, double-check that it is not outdated or incorrect. Sometimes, mistyping a URL can also result in a 401 Unauthorized error.

Step 5: Contact the Website Administrator

If you have tried all of the above steps and the error persists, contact the website administrator or support team for assistance. They should be able to identify any server-side issues and provide guidance on how to resolve the error.

Frequently Asked Questions about 401 Unauthorized Apache Server

Q1. What does the 401 Unauthorized Apache Server error code mean?

A1. The 401 Unauthorized Apache Server error code indicates that the server requires authentication but the client has failed to provide the necessary credentials.

Q2. What are some common causes of 401 Unauthorized Apache Server errors?

A2. Some common causes of 401 Unauthorized Apache Server errors include mistyped login credentials, expired tokens, server-side misconfiguration, and restricted access to a resource.

Q3. How can I fix a 401 Unauthorized Apache Server error?

A3. There are several ways to fix a 401 Unauthorized Apache Server error, such as checking your login credentials, clearing your browser cache, verifying the URL, disabling browser extensions, and contacting the website administrator for assistance.

Q4. Is 401 Unauthorized Apache Server an HTTP/1.0 status code?

A4. Yes, 401 Unauthorized Apache Server is part of the HTTP/1.0 specification and has since been adopted by newer versions of the protocol.

Q5. Can 401 Unauthorized Apache Server cause security risks?

A5. Yes, 401 Unauthorized Apache Server can pose security risks if not addressed promptly. Attackers could use repeated unauthorized requests to cause a denial of service attack or intercept traffic and obtain authentication credentials.

Q6. What are the advantages of 401 Unauthorized Apache Server?

A6. 401 Unauthorized Apache Server offers several advantages, such as enhanced security, standardized protocol, and scalability and flexibility.

Q7. What are the disadvantages of 401 Unauthorized Apache Server?

A7. Some common disadvantages of 401 Unauthorized Apache Server include compatibility issues, user frustration, and increased server load.

Conclusion

We hope this guide has helped you understand the intricacies of 401 Unauthorized Apache Server and how to deal with it when encountered. Remember, the key to resolving this error code is to double-check your login credentials, clear your browser cache, and contact the website administrator if all else fails. By following these simple steps, you can ensure a more secure and robust browsing experience.

Closing Disclaimer

This article is for informational purposes only and should not be construed as legal or professional advice. The authors and publishers of this article assume no liability for any errors or omissions or for any damages resulting from the use of the information contained herein.

Video:Understanding 401 Unauthorized Apache Server

Источник

HTTP response status code 401 Unauthorized is a client error that is returned by the server to indicate that the HTTP request has to be authenticated, and that appropriate login credentials have not yet been received.

Usage

When the 401 Unauthorized error message is received, the client understands that valid login credentials need to be supplied in advance of being granted access to the requested resource. It may be that the client needs to first log in to the system, or alternatively, supply credentials as part of the HTTP request. It may also be that the login credentials are not valid. It is relevant to distinguish this from 403 Forbidden, which informs the client that the action is not allowed.

When the server sends a 401 Unauthorized response, it must include the WWW-Authenticate response header. This informs the client as to what authorization methods it allows. IANA has a list of the standard authentication schemes, varying in both security and popularity. The specifications for common Authentication schemes can be found at the following links:

  • Basic

    This type of authentication is the transmission of credentials and ID/Password pairs RFC 7617.

  • Bearer

    This authentication, also known as token authentication, relies on security tokens that are generated by the server and returned to the client following a successful login. The client is responsible for sending these tokens in any subsequent attempt to access secure resources RFC 6750.

  • Digest

    HTTP Digest access authentication is a challenge-response protocol that can be used to authenticate resource requests RFC 7616.

  • HOBA

    Short for HTTP Origin-Bound Authentication, is a scheme that does not require the server to maintain a list of stored passwords, and thus is not vulnerable to phishing attacks RFC 7486.

  • Mutual

    Mutual authentication, also known as two-way authentication, is similar to the basic and digest authentication schemes, with the difference that the server is guaranteed to know the client’s encrypted password. Essentially, the client and server authenticate each other before the interaction continues RFC 8120.

  • AWS4-HMAC-SHA256

    This is an authentication algorithm designed to provide authentication information to Amazon Web Services AWS S3 API Reference.

More than one Authentication method can be specified by the server, either on multiple lines or a single, comma-delimited line. When the client has the credentials required, they are sent to the server using the Authorization request header.

Note

Search engines like Google will not index a URL with 401 Unauthorized response status, and consequently, URLs that have been indexed in the past but are now returning this HTTP status code will be removed from the search results.

Example

In the example, the client requests a resource and the server responds with the 401 Unauthorized status code to indicate that the resource is protected. As part of the response, the server indicates that it supports both basic authorization and mutual authorization. The client responds by stating that it is providing a username:password pair using the basic authentication protocol, which is specified in the Authorization header. Finally, the server responds by transmitting the requested resource.

Initial request

GET /documents/tech-news HTTP/1.1
Host: www.example.re

Initial response

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic; realm=”Documents”
WWW-Authenticate: Mutual

Next request, including Authorization

GET /documents/tech-news HTTP/1.1
Host: www.example.re
Authorization: Basic RXhhbXBsZTphaQ==

Final response

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 25000

<PDF document included in message body>

Code references

.NET

HttpStatusCode.Unauthorized

Rust

http::StatusCode::UNAUTHORIZED

Rails

:unauthorized

Go

http.StatusUnauthorized

Symfony

Response::HTTP_UNAUTHORIZED

Python3.5+

http.HTTPStatus.UNAUTHORIZED

Java

java.net.HttpURLConnection.HTTP_UNAUTHORIZED

Apache HttpComponents Core

org.apache.hc.core5.http.HttpStatus.SC_UNAUTHORIZED

Angular

@angular/common/http/HttpStatusCode.Unauthorized

Takeaway

The 401 Unauthorized status code indicates that authorization is required to access the requested resource. The server will inform which Authentication method(s) it supports and the client is required to authenticate itself before access is granted. Several common authentication schemes exist.

See also

  • RFC 7235

Last updated: August 2, 2023

Источник

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • Андроид ошибка при подключении к камере
  • Античит фейсит ошибка 12175
  • Аномальные ошибки при оценке параметров сигналов
  • Апач не запускается код ошибки 1
  • Андроид ошибка при копировании файла или папки

    • Добавить комментарий

    ;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: