I want to encrypt the data inside the HTTP POST request so that the client himself cant see the format of request he is sending to the server via softwares like Charles.
I have implemented HTTPS but when I used Charles I can see whole request I am sending and the response I am receiving. So I thought to encrypt the POST request data.
Q1 Is it good practice to encrypt data of POST request?
Q2 Is there any other way to achieve this ie client cant see his request?
Related
https retrieves data from the server in secure way, http or https post method as I know sends data encoded for reassuring sensitive information. If both https and post method secures data what is the difference
HTTP POST request will be sent unencrypted and any middle man in the communication can see the plain text
However with HTTPS all the data is encrypted and only the server can decrypt it to see the data that's coming
You maybe misunderstanding that encoding is not encryption by the way.
When a web server receives a http(s) GET request from a client, it has access to some information such as:
The client IP
The request itself :
the headers (including the cookies)
the content
and... that's all ?
I am wondering if there is something else.
Indeed, I am trying to make a server that can access to a page where it can collect some information to update its database. The site denied access to my server but not to web browsers, even if I replicate the IP, the headers and the content.
Thanks for your help.
Yes, it's only what is contained in the request itself. The server cannot reach back to the client to "pull" information, it only has the information contained in the HTTP request and the underlying TCP/IP packet. That's:
the requesting IP address
the HTTP headers, including requested URL and HTTP method
the HTTP request body, if any
if it's HTTPS, any data exchanged during the TLS handshake, which is usually not very relevant for identifying anything significant
All of that information is voluntarily provided by the requesting client.
Just a quick question, and probably a stupid one.
But usually when a client connects to an http server, the server sends them the header and the html, correct?
I'm packet sniffing a realtime-chat, and attempting to reverse engineer a plain text protocol, and it's connected to a http server. This is why I ask, for verification.
Basically, this is correct. Anyways, you have to differentiate between for example GET and POST Requests.
While POST Requests normally have a "real" body with information that they are delivering to the Server, the body of GET Requests is empty for most of the time.
For the responses, your Claim is correct. The Header is sent to tell how big the response is, which MIME Type is used, etc.
Can somebody explain in a simple manner about what exactly happens with http and soap in web services.
I was going through http://vijaybalajithecitizen.blogspot.com/2008/11/aspnet-web-services-interview-questions.html
,it describes the soap but what about http, what are the relationship between them
When I call a webmethod from a asp.net application , is it a soap/http call...how does it return value.
How to detect if it is a soap/http call?
HTTP is the transport mechanism, SOAP is the payload protocol. SOAP can be transferred over other protocols, but HTTP is the most widely used. This is very similar to HTML and HTTP. HTTP is the transport, and HTML is the payload. You could also email an HTML file, which means it's no longer using HTTP.
When you call a webmethod (or any other webservice), it is a "SOAP over HTTP" call. HTTP includes a Content-Type header which is set to "soap+xml". That lets the server know what kind of payload is contained, and how to parse it. I'm not actually sure that ASP.NET webmethods look at that, though. It could just try to parse the HTTP request as SOAP, and error if it doesn't parse. You'd usually only check the Content-Type if you were able to support multiple formats on the same URL.
Values are returned as SOAP formatted messages in the HTTP response. So, instead of sending HTML back, the server sends an XML document in the SOAP format.
HTTP is a transport used to carry SOAP formatted payloads. You can also use TCP to transport SOAP as well, or whatever else might strike your fancy. HTTP is, obviously, the most common transport for the SOAP payload because these things were built for web-based RPC.
Also, can you SEND any header back? (return headers) when you run a web server?
Or, are headers limited?
Web pages are retrieved using the HTTP protocol. HTTP is text-based. Both, a client requesting and a server responding within a HTTP communication can add custom headers to the HTTP messages. Its up to the communicating parties how to process these. I would assume that an unknown header is dropped silently.