Skip to main content

HTTP & HTTPS

What is HTTP?

HTTP stands for Hypertext Transfer Protocol.
It is a communications protocol and is used to send and receive web pages and files over the internet.
HTTP works by using a user agent (e.g. a browser) to connect to a server. The server must be located using a URL or URI. This always contains http:// at the start. It normally connects to port 80 on a computer.

What is HTTPS?

HTTPS stands for Hypertext Transfer Protocol Secure. This is a more secure version of HTTP and starts with https:// at the beginning of the URL. It encrypts all the information that is sent and received. This can stop malicious users such as hackers from stealing the information and is often used on payment websites. HTTPS uses port 443 for communication instead of port 80.


What is an HTTP Request?

HTTP stands for Hypertext Transfer Protocol and is a way of sending messages from one computer to another computer over the internet.
An HTTP request is sent to a specific URL and consists of a VERB, a set of HTTP Headers and a Body or Payload.
An example HTTP request is:
GET https://http://testingkida.blogspot.com// HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: text/plain
Host: testingkida.blogspot.com/
User-Agent: Apache-HttpClient/4.5.4 (Java/1.8.0_144)
Accept: text/html,application/xhtml+xml


URL

URL is a Uniform Resource Locator and is the address we use to access websites and web applications. URLs occur most commonly to reference web pages (http), but are also used for file transfer (ftp), email (mailto), and other applications.

Request Verbs

Request VERB specifies the type of request e.g. GET, POST, PUT, DELETE.
A Web Browser will usually make GET requests and POST requests, whereas when working with HTTP APIs the typical HTTP Verbs used are: GET, POST, PUT, DELETE.
GET request, as the name suggests, asks for a resource or to read information from the server e.g. clicking on a link. GET requests are visible in the browser’s address bar.
POST request, on the other hand, supply information to the server e.g. submitting a login or registration form. To create an entity, we would use POST requests. Also, POST requests are not visible in the browser’s address bar.
PUT request is used to update information on the server. For example, an existing user wishes to update his password, then a PUT request is used.
DELETE request deletes information on the server.
Both POST and PUT requests would usually have a request body. GET and DELETE would not.

Request Headers

Request headers specify information such as the type of Browser, type of content in the message, and what type of response is accepted in return.

Request Body / Payload

A Payload is the body of the HTTP request or response.
A request body can be plain text, HTML, XML, JSON, Javascript, or a set of key-value pairs as form-data.
When browsing the Web, the Browser usually receives an HTML payload. This is the web page that you see rendered in the Browser.
Typically when working with an HTTP API we will send and receive JSON or XML payloads.
Not all HTTP messages can have payloads: POST and PUT can have payloads, GET and DELETE can not.

What is an HTTP Response?

When a request is sent to a server, the server returns a response. The response from the server tells you if your request was successful, or if there was a problem.
An HTTP response method is made up of three components: Response status code, response headers, response body.

Response Status Codes

  • 2xx for Success, the most common one is 200 which means “OK”.
  • 3xx for Redirection, the most common ones are 301 and 303 which mean “Permanent Redirect” and “Redirect for Undefined Reason”, respectively.
  • 4xx for Application Error, the most common ones are 403 and 404 which mean “Forbidden” and “Not Found”, respectively.
  • 5xx for Server Error, the most common one is 500 which means “Server Error”.



Comments

Post a Comment

Popular posts from this blog

Mobile Application Testing Checklist

1. DEVICE SPECIFIC CHECKS 1.1  Can the app be installed on the device? 1.2 Does the app behave as designed/desired if there is an incoming call? 1.3 Does the app behave as designed/desired if there is an incoming SMS? 1.4 Does the app behave as designed/desired if the charger is connected? 1.5 Does the app behave as designed/desired if the charger is disconnected? 1.6 Does the app behave as designed/desired if the device goes to sleeping mode 1.7 Does the app behave as designed/desired if the device resumes from sleeping mode 1.8  Does the app behave as designed/desired if the device resumes from lock screen? 1.9    Does the app behave as designed/desired if the device is tilted? 1.10  Does the app behave as designed/desired if the device is shaken? 1.11 Does the app behave as designed/desired if a local message is coming from another app (think   of: calendar reminders, to-do task etc.). 1.12 Does the app behave as designed/desired if a push message i...
Post a Comment
Read more

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11. ...
Post a Comment
Read more

Software Testing Tips

Here are some of the Best Testing Practices which I learned by Experience:  1) Learn to analyze your test results thoroughly. Do not ignore any test result. The final test result may be ‘pass’ or ‘fail’, but troubleshooting the root cause of ‘fail’ will give you the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. 2) Learn to maximize the test coverage each time you test any application. 100% test coverage might not be possible but still, you can always try to reach near it. 3) In order to ensure maximum test coverage, break your application under test (AUT), into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g : Lets assume that you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing ...
Post a Comment
Read more