Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Web server
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Send response message === Web server programs are able to send response messages as replies to client request messages.<ref name="rfc7230-2.1" /> An error response message may be sent because a request message could not be successfully read or decoded or analyzed or executed.<ref name="rfc7230-3.4" /> NOTE: the following sections are reported only as examples to help to understand what a web server, more or less, does; these sections are by any means neither exhaustive nor complete. ==== Error message ==== A web server program may reply to a client request message with many kinds of error messages, anyway these errors are divided mainly in two categories: * [[HTTP client errors]], due to the type of request message or to the availability of requested web resource;<ref name="rfc7231-6.5">{{cite IETF |rfc=7231 |sectionname=Client Error 4xx|section=6.5|title=RFC 7231, HTTP/1.1: Semantics and Content|page=58}}</ref> * [[HTTP server errors]], due to internal server errors.<ref name="rfc7231-6.6">{{cite IETF |rfc=7231 |sectionname=Server Error 5xx|section=6.6|title=RFC 7231, HTTP/1.1: Semantics and Content|pages=62-63}}</ref> When an error response / message is received by a client browser, then if it is related to the main user request (e.g. an URL of a web resource such as a web page) then usually that error message is shown in some browser window / message. ==== URL authorization ==== A web server program may be able to verify whether the requested URL path:<ref name="rfc7235-1">{{cite IETF |rfc=7235 |sectionname=Introduction|section=1|title=RFC 7235, HTTP/1.1: Authentication|page=3}}</ref> * can be freely accessed by everybody; * requires a user authentication (request of user credentials, e.g. such as [[user name]] and [[password]]); * access is forbidden to some or all kind of users. If the authorization / access rights feature has been implemented and enabled and access to web resource is not granted, then, depending on the required access rights, a web server program: * can deny access by sending a specific error message (e.g. access [[List of HTTP status codes#403|forbidden]]); * may deny access by sending a specific error message (e.g. access [[List of HTTP status codes#401|unauthorized]]) that usually forces the client browser to ask human user to provide required user credentials; if authentication credentials are provided then web server program verifies and accepts or rejects them. ==== URL redirection ==== {{Main|URL redirection}} A web server program ''may'' have the capability of doing URL redirections to new URLs (new locations) which consists in replying to a client request message with a response message containing a new URL suited to access a valid or an existing web resource (client should redo the request with the new URL).<ref name="rfc7231-6.4">{{cite IETF |rfc=7231 |sectionname=Response Status Codes: Redirection 3xx |section=6.4|title=RFC 7231, HTTP/1.1: Semantics and Content|pages=53β54}}</ref> URL redirection of location is used:<ref name="rfc7231-6.4" /> * to fix a directory name by adding a final slash '/';<ref name="ws-directory-listings" /> * to give a new URL for a no more existing URL path to a new path where that kind of web resource can be found. * to give a new URL to another domain when current domain has too much load. Example 1: a URL path points to a '''directory''' name but it does not have a final slash '/' so web server sends a redirect to client in order to instruct it to redo the request with the fixed path name.<ref name="ws-directory-listings" /> From:<br /> <code>/directory1/directory2</code><br /> To:<br /> <code>/directory1/directory2/</code> Example 2: a whole set of documents has been '''moved inside website''' in order to reorganize their file system paths. From:<br /> <code>/directory1/directory2/2021-10-08/</code><br /> To:<br /> <code>/directory1/directory2/2021/10/08/</code> Example 3: a whole set of documents has been '''moved to a new website''' and now it is mandatory to use secure HTTPS connections to access them. From:<br /> <code><nowiki>http://www.example.com/directory1/directory2/2021-10-08/</nowiki></code><br /> To:<br /> <code><nowiki>https://docs.example.com/directory1/2021-10-08/</nowiki></code> Above examples are only a few of the possible kind of redirections. ==== Successful message ==== A web server program is able to reply to a valid client request message with a successful message, optionally containing requested '''web resource data'''.<ref name="rfc7231-6.3">{{cite IETF |rfc=7231 |sectionname=Successful 2xx|section=6.3|title=RFC 7231, HTTP/1.1: Semantics and Content|pages=51-54}}</ref> If web resource data is sent back to client, then it can be '''static content''' or '''dynamic content''' depending on how it has been retrieved (from a file or from the output of some program / module).
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)