CySa+ URL Analysis video,HTTP methods are incorrectly explained
-
In the URL Analysis for the CySa+ prep. The instructor is describing the HTTP methods but gets several of them completely wrong and gives an incorrect explanation in the demo on POST requests.
In the video he describes that PUT requests are to "put files onto the server" which is not an accurate description of this type of HTTP method. PUT is used update a resource that has already been created. He also does not seem to accurately explain the POST request either and then also goes into a demo example and states that the URL parameters can be seen in the query string in the URL during a POST request which is also not true.
Query parameters are only shown when a GET request is submitted, not during a POST request.
-
Hey @Zachary-Tackett
Thanks for your input on this as we always strive to be as accurate as we possibly can.
From my experience, I've always used PUT to "Put files onto the server". This probably has to do with my journey into cybersecurity. The first time I encountered PUT was in the context of uploading webshells. I was "PUT-ting" webshells on web servers.
After a little research, I found...
From https://www.w3schools.com/tags/ref_httpmethods.asp (emphasis mine)
"PUT is used to send data to a server to CREATE/update a resource."
From https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/PUT
"The HTTP PUT request method CREATES A NEW RESOURCE or replaces a representation of the target resource with the request payload."
From https://www.rfc-editor.org/rfc/rfc2616#page-55
" The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent
via the 201 (Created) response. If an existing resource is modified,
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
to indicate successful completion of the request. If the resource
could not be created or modified with the Request-URI, an appropriate
error response SHOULD be given that reflects the nature of the
problem. The recipient of the entity MUST NOT ignore any Content-*
(e.g. Content-Range) headers that it does not understand or implement
and MUST return a 501 (Not Implemented) response in such cases."So, I think we're both correct on this one.
As far as POST goes, I think you're spot on. From what I understand, you can have query strings with POST, but that query string won't have anything to do with the POST data which is probably what was confusing me and I appreciate the heads-up.
Cheers,
Daniel