DO YOU HAVE TO HAVE SSL OFFLOAD TO GET STATUS CODE
SSL offloading, often performed by a load balancer or a reverse proxy, is the process of removing the SSLbased encryption from incoming traffic to reduce the load on the web server.
Now, let’s talk about HTTP status codes and SSL (Secure Sockets Layer).
HTTP status codes are returned by the server to indicate the status of a requested resource. The resource could be a webpage, an image, a script, etc. These codes are independent of the transport layer (SSL/TLS).
When a client (e.g., a web browser) makes an HTTP request over SSL (HTTPS), the request is encrypted and sent to the server. The server then decrypts the request, processes it, and returns a response. This response includes an HTTP status code which is then encrypted and sent back to the client. The client decrypts the response to read the status code.
This process is independent of whether SSL offloading is occurring or not. If SSL offloading is being used, the load balancer or reverse proxy would decrypt the traffic instead of the server, but the handling of HTTP status codes would not change. They are still generated by the server and sent to the client in the response, whether the response is being encrypted by the server or the load balancer.
The crucial factor is that SSL/TLS operates at a lower layer in the networking stack than the HTTP protocol, so the server can return HTTP status codes over SSL/TLS connections without any problems.
DETAILS
Let’s elaborate more on HTTP status codes, SSL, and SSL offloading.
When a client, usually a web browser, makes a request to a server, the server processes the request and responds with a status code. HTTP status codes are a standard part of HTTP responses. They are three digit numbers where the first digit defines the class of response, for example:
2xx: Successful responses
3xx: Redirection messages
4xx: Client error responses
5xx: Server error responses
These status codes provide the client with information about the result of its request, such as whether it was successful or not, and if not, what kind of error occurred.
When a client makes a request over HTTPS (HTTP over SSL/TLS), the entire HTTP request and response are encrypted. This means the HTTP headers, the body content, and the status code are all encrypted.
Now, SSL offloading is the process of moving the CPUintensive work of encrypting and decrypting SSL traffic from a web server to a separate device, often a load balancer or a reverse proxy. This is typically done to reduce the load on the web server and allow it to focus on serving content.
However, whether or not SSL offloading is used does not directly affect the generation and handling of HTTP status codes. Regardless of whether the SSL encryption/decryption is happening on the web server itself or on a separate device, the HTTP status code is generated by the server after it processes the request.
When the server generates its response, including the status code, the response is then encrypted (either by the server itself or by the device handling SSL offloading) before being sent over the network. When the client receives the response, it decrypts it, thus gaining access to the status code and the rest of the response.
So to test HTTP status codes over HTTPS, you would make an HTTP request to the server over an SSL/TLS connection, then look at the status code in the server’s response after it’s been decrypted. The exact method of doing this would depend on the tools you’re using to make the request and receive the response.
TESTING WITH CURL
F5 Config:
HTTP Monitor:
Type: HTTP
Parent Monitor: http
Send String: GET / HTTP/1.1\r\nHost: cordero.me\r\nConnection: Close\r\n\r\n
Receive String: HTTP/1\.[01] 200
HTTPS Monitor:
Type: HTTPS
Parent Monitor: https
Send String: GET / HTTP/1.1\r\nHost: cordero.me\r\nConnection: Close\r\n\r\n
Receive String: HTTP/1\.[01] 200
CURL Command:
curl -I https://cordero.me
HTTP/1.1 200 OK
Date: Thu, 15 Jun 2023 20:16:21 GMT
Server: Apache/2.4.56 (Debian)
Link: <https://cordero.me/wp-json/>; rel="https://api.w.org/"
Content-Type: text/html; charset=UTF-8
F5 Config:
HTTP Monitor:
Type: HTTP
Parent Monitor: http
Send String: GET /api/octopusservernodes/ping HTTP/1.0\r\n
Receive String: HTTP/1\.[01] 200
HTTPS Monitor:
Type: HTTPS
Parent Monitor: https
Send String: GET /api/octopusservernodes/ping HTTP/1.0\r\n
Receive String: HTTP/1\.[01] 200
CURL Command:
curl -I -X GET https://mia-octopus01.cordero.me/api/octopusservernodes/ping
HTTP/1.1 200 OK
Cache-Control: private
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Expires: Wed, 14 Jun 2023 20:08:30 GMT
Server: Octopus Deploy/ Microsoft-HTTPAPI/2.0
SITES TO HELP TEST
Here’s a list of online HTTP status code testing services you can use for testing:
1. httpstat.us
A super simple service for generating different HTTP codes. It’s useful for testing how your own scripts deal with varying responses. For instance, you can get a 503 Service Unavailable response with https://httpstat.us/503
2. httpbin.org
httpbin.org is a simple HTTP request/response service, and it provides endpoints for various status codes. For example, you can get a 403 Forbidden response with https://httpbin.org/status/403
3. Postman Echo
Postman Echo is a service that you can use to test your REST clients and make sample API calls. It provides endpoints for different status codes. For example: https://postman-echo.com/status/404
4. RESTful-Service (GoRest)
GoRest (https://gorest.co.in/) is a public API for testing and prototyping. It does not directly return specific status codes, but it’s a good tool for practicing API interaction.
5. Webhook.site
With Webhook.site, you instantly get a unique, random URL that you can use to test and debug webhooks and HTTP requests. It doesn’t directly return specific status codes, but it’s a very flexible tool for inspecting HTTP requests.
6. RequestBin
RequestBin gives you a URL that collects requests you send to it so you can inspect them in a human-friendly way. Use it to see what your HTTP client is sending or to inspect and debug webhook requests. (https://requestbin.com/)
7. Mockbin
Mockbin allows you to generate custom endpoints to test, mock, and track HTTP requests and responses. (https://mockbin.org/)
Remember, these tools are primarily for testing and debugging HTTP requests. They may not represent the behavior of a full-fledged web application or API, but they are useful for understanding how your application or service interacts with different HTTP status codes.