HTTP GET vs POST SE-2840 Dr. Mark L. Hornick
A Form is a webpage containing HTML input elements that allow a user to enter information A form consists of static HTML markup… …as well as controls that permit input of various kinds of data SE-2840 Dr. Mark L. Hornick
In the old days, <form> elements were used to contain input elements whose data would be automatically submitted to a web server when the submit button was pressed <body> <h3>Fill out the fields below:</h3> <form action=“http://...” method=“post”> <!– or method=“get” <p>Your name: <br /> First: <input type="text" id=“first” name=“firstname" /> <br> Last: <input type="text" id=“last” name=“lastname" /> </p> <p>Press <strong>Send</strong> to submit your information. <!– ‘submit’ is s special type of button that automatically causes the browser to collect the form data and generate an http request to the url <input id=“send” type="submit" value="Send" /> </form> </body> Obsolete! SE-2840 Dr. Mark L. Hornick
What happened when forms were submitted? 1) You browse to a webpage containing forms and fill it out; then press the submit button 3)The server receives the form data and passes it on to a resource for processing. Obsolete! 2)The browser automatically packages the data in the form and sends it to the web server via an http POST (or GET) request Web Browser 4) The Web application generates a response and sends it to the browser – the usual response was a new web page or “redirect” command to tell the browser what page to display next. Web Server SE-2840 Dr. Mark L. Hornick
HTML <form> tag element …and the name of the Web Resource that will process the form data if it is submitted The opening <form> tag – all form elements go between the opening and closing tag. Obsolete! <form action="http://<url>" method=“post"> <!-- form elements go here --> </form> The method attribute specifies which HTTP message will be used to send the data in the form to the server – default is “get” The required action attribute specifies the url of where to send the form’s data. SE-2840 Dr. Mark L. Hornick
In modern web page implementation, we use JS and Ajax to generate GET and POST requests See code in Phone.html and Phone.js: <input id="send" type="button" value="Submit"> $("#send").click( function() { console.log("submit clicked"); doAjaxSubmitRequest(); // invoke ajax request to POST new data to the server }); CS-4220 Dr. Mark L. Hornick
GET vs. POST scenarios Browser/JS sends HTTP GET request with parameters Fill out form and press SEND Server responds, but does not change state; the GET request is IDEMPOTENT Browser/JS sends HTTP POST request with parameters Server changes state by accepting data; responds indicating success or failure. Fill out form and press SEND SE-2840 Dr. Mark L. Hornick
HTTP GET appends parameters to the end of the URL (insecure) The parameters are plainly visible in the url (insecure!), even when https is used GET requests also have a limit of 256 characters in the URL Use GET only to provide small amounts of insensitive data which the server app will NOT use to modify its internal state! SE-2840 Dr. Mark L. Hornick
HTTP POST encodes parameters into the HTTP POST header A post request header can be securely encrypted (using HTTPS) in order to protect sensitive data, such as a credit card numbers or passwords There is no limit on the size of the data packet that can be sent to the server Note: You cannot bookmark a url that was generated as a POST message, since the form data is not in the bookmarked url Always use POST to send form data that Is sensitive (use https encryption in that case) If the data is large (>256 bytes) Will change the state of the web application SE-2840 Dr. Mark L. Hornick
Cross-Origin Resource Sharing (CORS) Modern browsers apply a “same-origin” policy to web pages as a security precaution RFC 6454 defines the “origin” of a web page as the combination of protocol, host, port (http://localhost:3003/welcome.html) When enforced, this policy prevents the web page from accessing resources from an origin that differs from that of the web page itself Different origin means that the protocol, url , or port of the requested resource In some circumstances, enforcing this policy is too restrictive and is relaxed This is how a web page can freely access images, stylesheets, and scripts from other servers – for example: bootstrap.css and jquery.js However, the policy is NOT relaxed (i.e. IS ENFORCED) when a web page attempts to access a “different origin” resource via an XMLHttpRequest (i.e. an Ajax call to a different server) CS-4220 Dr. Mark L. Hornick This Photo by Unknown Author is licensed under CC BY-SA
The CORS standard defines a specific mechanism that a browser and server must implement For Ajax, the browser first makes an HTTP OPTIONS request to the server, asking for permission to make a subsequent HTTP GET or POST This is called a “preflight” request Certain headers in the HTTP OPTIONS request are used to convey the information the browser supplies to the server For example, the HTTP OPTIONS preflight request header may contain Host: http://www.mcts.com Origin: http://localhost:3003 The server responds with “approval” or “denial” with certain HTTP headers in the response For example, if the server’s HTTP OPTIONS response header contains Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET this indicates that the server allows GET (but not PUT) requests from ANY origin as it is serving up public content If the response indicates “denial”, or the server simply does not honor/respond to the HTTP OPTIONS request, the browser does not make the subsequent HTTP GET/POST and the Ajax request fails NOTE: It is possible to disable the preflight request on the browser, but this undermines security – so it is not recommened/dangerous.
CORS flowchart MCTS Path https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#/media/File:Flowchart_showing_Simple_and_Preflight_XHR.svg