HTTP Request Header Detailed

Source: Internet
Author: User
Tags ranges unsupported windows support
The composition of the http header:
===============
 HTTP header fields include 4 types:
       general-header;
     request-header;
       response-header;
     entity-header.
 
********************************************** *****************************
 General Header Fields
===============================
   The general header is available for both request and response, but it cannot be used for entity.
 
 
       --- Cache-Control
       -- Connection
       -- Date
       -- Pragma
       -- Trailer
       --- Transfer-Encoding
       -- Upgrade
       -Via
       -- Warning
 
********************************************** *****************************
 Request Header Fields
=======================
 
   request-header fields allow the client to pass additional information about the request and the client to the server,
 
       -- Accept
       -- Accept-Charset
       -- Accept-Encoding
       -- Accept-Language
       -Authorization
       --- Expect
       -- From
       -- Host
       --- If-Match
       --- If-Modified-Since
       --- If-None-Match
       --- If-Range
       --- If-Unmodified-Since
       -- Max-Forwards
       --- Proxy-Authorization
       --- Range
       --- Referer
       -TE
       --- User-Agent
 
********************************************** *****************************
  Response Header Fields
=================================
 
   response-header fields allow the server to pass additional information about the response that cannot be placed in the Status-Line.
   These headers give information about the server.
 
      -- Accept-Ranges
      --- Age
      - ETag
      -- Location
      --- Proxy-Authenticate
      -- Retry-After
      --- Server
      --- Vary
      -- WWW-Authenticate
 
********************************************** *****************************
 Entity Header Fields
=========================
 
   Entity-header fields defines the retentionformation of the entity-body (header field data),
   If there is currently no body, define the resource information determined by the request.
   Some metainformation is optional; some are required.
 
       --- Allow
       -- Content-Encoding
       -- Content-Language
       -- Content-Length
       --- Content-Location
       -- Content-MD5
       -- Content-Range
       --- Content-Type
       --- Expires
       -- Last-Modified
       -- extension-header

[From] http://www.x5dj.com/userforum/00100239/00305167.shtml

First, the basics
HTTP (HyperTextTransferProtocol) is an abbreviation of Hypertext Transfer Protocol. It is used to transfer WWW data. For details about the HTTP protocol, please refer to RFC2616. The HTTP protocol uses a request / response model. The client sends a request to the server. The request header contains the method, URI, protocol version, and MIME-like message structure containing the request modifier, client information, and content. The server responds with a status line. The corresponding content includes the version of the message protocol, the success or error code plus the server information, entity meta information, and possible entity content.
Generally, the HTTP message includes a request message from the client to the server and a response message from the server to the client. These two types of messages consist of a start line, one or more header fields, an empty line just the end of the header field, and an optional message body. The HTTP header field includes four parts: a general header, a request header, a response header, and an entity header. Each header field consists of a domain name, a colon (:), and a domain value. The domain name is case-insensitive. You can add any number of space characters before the domain value. The header field can be expanded to multiple lines. At the beginning of each line, use at least one space or tab.
1.General header field
The general header field includes header fields that are supported by both request and response messages. The general header field includes Cache-Control, Connection, Date, Pragma, Transfer-Encoding, Upgrade, and Via. The extension of the general header field requires both parties to support this extension. If there is an unsupported general header field, it will generally be treated as an entity header field. The following briefly introduces several common header fields used in UPnP messages.
Cache-Control header field
Cache-Control specifies the caching mechanism that requests and responses follow. Setting Cache-Control in the request message or response message does not modify the cache processing in another message processing. The cache instructions when requested include no-cache, no-store, max-age, max-stale, min-fresh, only-if-cached, and the instructions in the response message include public, private, no-cache, no-store, no-transform, must-revalidate, proxy-revalidate, max-age. The meaning of the instructions in each message is as follows:
Public indicates that the response can be cached by any cache area.
Private indicates that all or part of the response message for a single user cannot be processed by the shared cache. This allows the server to describe only a part of the user's response message, which is not valid for requests from other users.
no-cache indicates that request or response messages cannot be cached
no-store is used to prevent important information from being unintentionally released. Sending in the request message will make both request and response messages use no cache.
max-age indicates that the client can receive a response whose lifetime is not greater than a specified time (in seconds).
min-fresh indicates that the client can receive responses whose response time is less than the current time plus the specified time.
max-stale indicates that the client can receive response messages beyond the timeout period. If the value of the max-stale message is specified, the client can receive response messages that exceed the value specified for the timeout period.
Date header field
The Date header field indicates the time when the message was sent. The format of the time description is defined by rfc822. For example, Date: Mon, 31Dec200104: 25: 57GMT. The time described by Date represents the world standard time. To convert to local time, you need to know the time zone of the user.
Pragma header field
The Pragma header field is used to contain implementation-specific instructions. The most common is Pragma: no-cache. In the HTTP / 1.1 protocol, it has the same meaning as Cache-Control: no-cache.
Request message
The first line of the request message is in the following format:
Method SP Request-URI SP HTTP-Version CRLF
Method indicates that for Request-URI completed methods, this field is case sensitive, including OPTIONS, GET, HEAD, POST, PUT, DELETE, and TRACE. The methods GET and HEAD should be supported by all general web servers. The implementation of all other methods is optional. The GET method retrieves the information identified by the Request-URI. The HEAD method also retrieves the information identified by the Request-URI, but it does not return the message body when responding. The POST method can request the server to receive the entity information contained in the request. It can be used to submit forms and send messages to newsgroups, BBS, mail groups, and databases.
SP means space.
Request-URI follows the URI format. When this field is an asterisk (*), it means that the request is not for a specific resource address, but for the server itself.
HTTP-Version indicates the supported HTTP version, such as HTTP / 1.1.
CRLF stands for line feed carriage return.
The request header field allows the client to pass additional information about the request or about the client to the server. The request header field may contain the following fields: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, From, Host, If-Modified-Since, If-Match, If-None-Match, If-Range, If-Range , If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, User-Agent. The extension of the request header field requires both parties to support it. If there is an unsupported request header field, it will generally be treated as an entity header field.
Typical request message:
GEThttp: //class/download.microtool.de: 80 / somedata.exe
Host: download.microtool.de
Accept: * / *
Pragma: no-cache
Cache-Control: no-cache
Referer: http: //class/download.microtool.de/
User-Agent: Mozilla / 4.04 [en] (Win95; I; Nav)
Range: bytes = 554554-
The first line of the above example indicates that the HTTP client (possibly a browser, a downloader) obtained the file at the specified URL through the GET method. The brown part indicates the information of the request header field, and the green part indicates the general header part.
Host header field
The Host header field specifies the Intenet host and port number of the requested resource, and must indicate the location of the original server or gateway that requested the URL. The HTTP / 1.1 request must include the host header field, otherwise the system will return with a 400 status code.
Referer header
The Referer header field allows the client to specify the source resource address of the request uri. This can allow the server to generate a back-link list, which can be used to log in and optimize the cache. He also allows decommissioned or wrong connections to be traced for maintenance purposes. If the requested uri does not have its own uri address, the Referer cannot be sent. If a partial uri address is specified, this address should be a relative address.
Range header field
The Range header field may request one or more sub-ranges of the entity. E.g,
The first 500 bytes: bytes = 0-499
Represents the second 500 bytes: bytes = 500-999
Represents the last 500 bytes: bytes = -500
Range after 500 bytes: bytes = 500-
First and last bytes: bytes = 0-0, -1
Specify several ranges at the same time: bytes = 500-600,601-999
But the server can ignore this request header, if the unconditional GET contains the Range request header , The response will return with status code 206 (PartialContent) instead of 200 (OK).
User-Agent header
The content of the User-Agent header contains information about the user who made the request.
3.Response message
The first line of the response message has the following format:
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP-Version indicates the supported HTTP version, such as HTTP / 1.1.
Status-Code is a three-digit result code.
Reason-Phrase provides a simple text description for Status-Code. Status-Code is mainly used for automatic machine identification, and Reason-Phrase is mainly used to help users understand. The first number of Status-Code defines the category of the response. The last two numbers have no role in classification. The first number may take 5 different values:
1xx: Information response class, which indicates that the request is received and processing continues
2xx: Handle success response class, indicating that the action was successfully received, understood, and accepted
3xx: Redirection response class, in order to complete the specified action, must be further processed
4xx: client error, the client request contains a syntax error or is not executed correctly
5xx: server error, the server cannot perform a correct request
Response header fields allow the server to pass additional information that cannot be placed in the status line. These fields mainly describe server information and Request-URI further information. The response header fields include Age, Location, Proxy-Authenticate, Public, Retry-After, Server, Vary, Warning, WWW- Authenticate. The extension of the response header field requires both parties to support it. If there is an unsupported response header field, it will generally be treated as an entity header field.
Typical response message:
HTTP / 1.0200OK
Date: Mon, 31Dec200104: 25: 57GMT
Server: Apache / 1.3.14 (Unix)
Content-type: text / html
Last-modified: Tue, 17Apr200106: 46: 28GMT
Etag: "a030f020ac7c01: 1e9f"
Content-length: 39725426
Content-range: bytes554554-40279979 / 40279980
The first line of the above example indicates that the HTTP server responded with a GET method. The brown part indicates the information of the response header field, the green part indicates the general header part, and the red part indicates the information of the entity header field.
Location response header
The Location response header is used to redirect the recipient to a new URI address.
Server response header
The Server response header contains software information of the originating server that processed the request. This field can contain multiple product IDs and notes. Product IDs are generally ordered by importance.
4.Entity information
Both the request message and the response message can contain entity information. The entity information generally consists of an entity header field and an entity. The entity header field contains the original information about the entity. The entity header includes Allow, Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Etag, Expires , Last-Modified, extension-header. extension-header allows the client to define new entity headers, but these domains may not be recognized by the unaccepted party. The entity can be an encoded byte stream. Its encoding method is defined by Content-Encoding or Content-Type, and its length is defined by Content-Length or Content-Range.
Content-Type entity header
The Content-Type entity header is used to indicate the media type of the entity to the receiver. It specifies the type of the physical media that the HEAD method sends to the receiver, or the request media type sent by the GET method.
Content-Range entity header
It is used to specify the insertion position of a part of the entire entity. It also indicates the length of the entire entity. When the server returns a partial response to the client, it must describe the scope of the response and the entire entity length. General format:
Content-Range: bytes-unit SP first-byte-pos-last-byte-pos / entity-legth
For example, the form of the first 500 bytes of the transmission header field: Content-Range: bytes0-499 / 1234 Represents the range of transmission, Content-Length indicates the number of bytes actually transmitted.
Last-modified entity header
The Last-modified entity header specifies the last revision time of the content saved on the server.
5, HTTP header reference (microsoft)
Both HTTP requests and HTTP responses use headers to send information about HTTP messages. The header consists of a series of lines, each containing a name, followed by a colon, a space, and a value. The fields can be arranged in any order. Some header fields can be used for both request and response headers, while others can only be used for one of them.
Many request header fields allow clients to specify multiple acceptable options in the value section, and sometimes even rank their preferences. Multiple items are separated by commas. For example, a client can send a request header containing "Content-Encoding: gzip, compress," indicating that it can accept various compression types. If the server's response body is gzip-encoded, its response header will contain "Content-Encoding: gzip".
Some fields can appear multiple times in a single header. For example, the header can have multiple "Warning" fields.
The following table lists the HTTP 1.1 header fields. Note: Some header fields are MIME fields. MIME fields are defined in the Internet Engineering Task Force (IETF) document RFC 2045, but can also be used with the HTTP 1.1 protocol. For more information about the MIME and HTTP 1.1 specifications, see the IEIF page.
General header field
General header fields can be used for request messages and response messages.
Name Example value
Cache-Control "max-age = 10"
Connection "close"
Date "Tue, 11 Jul 2000 18:23:51 GMT"
Pragma "no-cache"
Trailer "Date"
Transfer-Encoding "chunked"
Upgrade "SHTTP / 1.3"
Via "HTTP / 1.1 Proxy1, HTTP / 1.1 Proxy2"
Warning "112 Disconnected Operation"
Request header field
The request header field is used only for request messages.
Name Example value
Accept "text / html, image / *"
Accept-Charset "iso8859-5"
Accept-Encoding "gzip, compress"
Accept-Language "en, fr"
Authorization [credentials]
Content-Encoding "gzip"
Expect "100-continue"
From "user@microsoft.com"
Host "www.microsoft.com"
If-Match "entity_tag001"
If-Modified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
If-None-Match "entity_tag001"
If-Range "entity_tag001" or "Tue, 11 Jul 2000 18:23:51 GMT"
If-Unmodified-Since "Tue, 11 Jul 2000 18:23:51 GMT"
Max-Forwards "3"
Proxy-Authorization [credentials]
Range "bytes = 100-599"
Referer "http://www.microsoft.com/resources.asp"
TE "trailers"
User-Agent "Mozilla / 4.0 (compatible; MSIE 5.5; Windows NT 5.0)"
 
>> The specific meaning of the request header field
Accept: The MIME types that the browser can accept.
Accept-Charset: The character set accepted by the browser.
Accept-Encoding: The data encoding method that the browser can decode, such as gzip.
Accept-Language: The language type desired by the browser. It is used when the server can provide more than one language version.
Authorization: Authorization information, which usually appears in the response to the WWW-Authenticate header sent by the server.
Connection: Indicates whether a persistent connection is required. If the servlet sees the value "Keep-Alive" here, or sees that the request is using HTTP 1.1 (HTTP 1.1 defaults to persistent connections), it can take advantage of persistent connections when the page contains multiple elements (such as Applet, picture), significantly reducing the time required for download. To achieve this, the servlet needs to send a Content-Length header in the response. The simplest way to do this is to first write the content to a ByteArrayOutputStream and then calculate its size before the content is officially written.
Content-Length: indicates the length of the request message body.
Cookies: Set cookies, this is one of the most important request headers
From: The email address of the sender of the request. It is used by some special web clients, and it is not used by the browser.
Host: The host and port in the initial URL.
If-Modified-Since: Only returns the requested content after it has been modified after the specified date, otherwise it returns a 304 "Not Modified" response.
Pragma: Specifying a "no-cache" value means that the server must return a refreshed document, even if it is a proxy server and already has a local copy of the page.
Referer: Contains a URL, and the user starts from the page represented by the URL to access the currently requested page.
User-Agent: Browser type. This value is useful if the content returned by the servlet is related to the browser type.
UA-Pixels, UA-Color, UA-OS, UA-CPU: Non-standard request headers sent by some versions of Internet Explorer, indicating the screen size, color depth, operating system, and CPU type.
Response header fields
The response header field is only used in response messages.
Name Example value
Accept-Ranges "none"
Age "2147483648 (2 ^ 31)"
ETag "b38b9-17dd-367c5dcd"
Last-Modified "Tue, 11 Jul 2000 18:23:51 GMT"
Location "http: //localhost/redirecttarget.asp"
Proxy-Authenticate [challenge]
Retry-After "Tue, 11 Jul 2000 18:23:51 GMT" or "60"
Server "Microsoft-IIS / 5.0"
Vary "Date"
WWW-Authenticate [challenge]
Entity header field
The entity header field can be used for request messages or response messages. The entity header field contains information about the body of the message entity, such as the encoding format used.
Name Example value
Allow "GET, HEAD"
Content-Encoding "gzip"
Content-Language "en"
Content-Length "8445"
Content-Location "http: //localhost/page.asp"
Content-MD5 [md5-digest]
Content-Range "bytes 2543-4532 / 7898"
Content-Type "text / html"
Expires "Tue, 11 Jul 2000 18:23:51 GMT"
Last-Modified "Tue, 11 Jul 2000 18:23:51 GMT"
>> The specific meaning of the entity header field
Allow request methods (such as GET, POST, etc.) that the server supports.
Content-Encoding The encoding method of the document. Only after decoding can the content type specified by the Content-Type header be obtained. Compressing documents with gzip can significantly reduce the download time of HTML documents. Java's GZIPOutputStream can be easily gzip compressed, but only Netscape on Unix and IE 4, IE 5 on Windows support it.
Content-Length indicates the content length. This data is only needed when the browser is using a persistent HTTP connection.
Content-Type indicates what MIME type the subsequent document belongs to. Servlets default to text / plain, but usually need to be explicitly specified as text / html.
Date The current GMT time. You can use setDateHeader to set this header to avoid the trouble of converting time format.
When should Expires consider the document to be out of date and no longer cache it?
Last modified time of the Last-Modified document. The customer can provide a date through the If-Modified-Since request header, and the request will be treated as a conditional GET. Only documents with a modification time later than the specified time will be returned, otherwise a 304 (Not Modified) status will be returned.
Location indicates where customers should go to fetch documents. Location is usually not set directly, but through the sendRedirect method of HttpServletResponse, which also sets the status code to 302.
Refresh indicates in how many seconds the browser should refresh the document, in seconds. In addition to refreshing the current document, you can also let the browser read the specified page via setHeader ("Refresh", "5; URL = http: // host / path").
Note that this feature is usually implemented by setting <META. HTTP-EQUIV = "Refresh" C> in the HEAD area of the HTML page, because automatic refresh or redirection is important for HTML writers who cannot use CGI or Servlet. However, for servlets, setting the Refresh header directly is more convenient.
Note that the meaning of Refresh is "refresh this page or visit the designated page after N seconds", not "refresh this page or visit the designated page every N seconds". Therefore, continuous refresh requires sending a Refresh header each time, and sending a 204 status code can prevent the browser from continuing to refresh, whether it is using the Refresh header or <META. HTTP-EQUIV = "Refresh" ...>.
Note that the Refresh header is not part of the official HTTP 1.1 specification, but an extension, but both Netscape and IE support it.
Request header example
Here is a simple example of an HTTP request.
GET /articles/news/today.asp HTTP / 1.1
Accept: * / *
Accept-Language: en-us
Connection: Keep-Alive
Host: localhost
Referer: http: //localhost/links.asp
User-Agent: Mozilla / 4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Accept-Encoding: gzip, deflate
The request has a request line that includes a method (GET), a resource path (/articles/news/today.asp), and an HTTP version (HTTP / 1.1). Because the request has no body, everything after the request line is part of the header. Immediately after the header is a blank line, indicating that the header is over.
Example response header
The web server can respond to the previous request in several ways. Assuming the file is accessible and the user has permission to view the file, the response is similar to:
HTTP / 1.1 200 OK
Server: Microsoft-IIS / 5.0
Date: Thu, 13 Jul 2000 05:46:53 GMT
Content-Length: 2291
Content-Type: text / html
Set-Cookie: ASPSESSIONIDQQGGGNCG = LKLDFFKCINFLDMFHCBCBMFLJ; path = /
Cache-control: private
...
The first line of the response is called the status line. It contains the HTTP version, status encoding (200), and reason phrase used in the response. The example contains a header with five fields, followed by a blank line (carriage return and line feed), and then the first two lines of the response body.
For a complete and detailed description of HTTP headers, see the HTTP specification at http://www.w3.org/Protocols/.
 
Appendix: the meaning of HTTP protocol status codes
Status Code Status Message Meaning
100 Continue The initial request has been accepted and the client should continue to send the rest of the request. (New in HTTP 1.1)
101 Switching Protocols server will follow the client's request to switch to another protocol (HTTP 1.1 new
200 OK Everything works, the response documents for GET and POST requests follow.
201 Created The server has created the document and its Location header gives its URL.
202 Accepted The request has been accepted, but processing has not been completed.
203 Non-Authoritative Information The document has been returned normally, but some response headers may be incorrect because a copy of the document is used (new in HTTP 1.1).
204 No Content There is no new document and the browser should continue to display the original document.
205 Reset Content There is no new content, but the browser should reset what it displays. Used to force the browser to clear form input (new in HTTP 1.1).
206 Partial Content The client sent a GET request with a Range header and the server completed it (new in HTTP 1.1).
300 Multiple Choices The document requested by the customer can be found in multiple locations that are already listed in the returned document. If the server wants to propose a preference, it should indicate it in the Location response header.
301 Moved Permanently The document requested by the client is elsewhere. The new URL is given in the Location header. The browser should automatically access the new URL.
302 Found is similar to 301, but the new URL should be considered a temporary replacement, not a permanent one. Note that the corresponding status information in HTTP 1.0 is "Moved Temporatily". When this status code appears, the browser can automatically access the new URL, so it is a useful status code. Note that this status code can sometimes be replaced with 301. For example, if the browser incorrectly requests http: // host / ~ user (missing trailing slash), some servers return 301, and some return 302. Strictly speaking, we can only assume that the browser will automatically redirect only when the original request was a GET. See 307.
303 See Other is similar to 301/302, except that if the original request is a POST, the redirected target document specified by the Location header should be fetched via GET (new in HTTP 1.1).
304 Not Modified The client has a buffered document and issued a conditional request (usually providing an If-Modified-Since header indicating that the client only wants documents that are newer than the specified date). The server tells the client that the original buffered document can still be used.
305 Use Proxy The document requested by the client should be fetched through the proxy server indicated by the Location header (new in HTTP 1.1).
307 Temporary Redirect is the same as 302 (Found). Many browsers incorrectly redirect in response to a 302 response, even if the original request was a POST, even if it can only redirect when the response to the POST request is 303. For this reason, HTTP 1.1 added 307 to more clearly distinguish several status codes: When a 303 response occurs, the browser can follow redirected GET and POST requests; if it is a 307 response, the browser can only follow Redirection of GET requests. (New in HTTP 1.1)
400 Bad Request A syntax error occurred.
401 Unauthorized customer attempted unauthorized access to a password-protected page. The response will include a WWW-Authenticate header, and the browser will display the username / password dialog box accordingly, and then issue the request again after filling in the appropriate Authorization header.
403 Forbidden resource is not available. The server understood the client's request but refused to process it. This is usually caused by the permission settings of files or directories on the server.
404 Not Found Unable to find the resource at the specified location. This is also a commonly used response,
405 Method Not Allowed The request methods (GET, POST, HEAD, DELETE, PUT, TRACE, etc.) are not applicable to the specified resource. (New in HTTP 1.1)
406 Not Acceptable The specified resource has been found, but its MIME type is not compatible with what the client specified in the Accpet header (new in HTTP 1.1).
407 Proxy Authentication Required is similar to 401, which means that the client must first be authorized by the proxy server. (New in HTTP 1.1)
408 Request Timeout The client has not made any requests during the server license wait time. The customer can repeat the same request later. (New in HTTP 1.1)
409 Conflict is usually related to a PUT request. The request cannot succeed because the request conflicts with the current state of the resource. (New in HTTP 1.1)
410 Gone The requested document is no longer available, and the server does not know which address to redirect to. It differs from 404 in that it returns 407 to indicate that the document has permanently left the specified location, while 404 indicates that the document is unavailable for unknown reasons. (New in HTTP 1.1)
411 Length Required The server cannot process the request unless the client sends a Content-Length header. (New in HTTP 1.1)
412 Precondition Failed Some preconditions specified in the request header failed (new in HTTP 1.1).
413 Request Entity Too Large The size of the target document exceeds the size that the server is currently willing to process. If the server thinks it can process the request later, it should provide a Retry-After header (new in HTTP 1.1).
414 Request URI Too Long URI is too long (new in HTTP 1.1).
416 Requested Range Not Satisfiable The server cannot meet the Range header specified by the client in the request. (New in HTTP 1.1)
500 Internal Server Error The server encountered an unexpected condition and could not complete the client's request.
501 Not Implemented The server does not support the functionality required to implement the request. For example, the client sends a PUT request that is not supported by the server.
When the 502 Bad Gateway server acts as a gateway or proxy, in order to complete the request to access the next server, the server returned an illegal response.
503 Service Unavailable The server failed to respond due to maintenance or overload.
504 Gateway Timeout is used by a server that acts as a proxy or gateway, indicating that a response from a remote server cannot be obtained in a timely manner. (New in HTTP 1.1)
505 HTTP Version Not Supported The server does not support the HTTP version specified in the request


Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.