Backgrounds
I've been using my own site to send a POST request to another site that requires a specific sender url, which is my site's url. And now I'm trying to send the automated POST request with my WPF application. I can't use httpclient's sendAsync function because that way I can't include valid site url for header. Therefore I'm trying to send the request from WebBrowser by loading the page and filling the input values, and then submitting the form. And here's my problem.
Problem
This target server that receives POST request requires a specific encoding, something other than UTF-8. And my site is configured to fit that encoding and works fine on the actual web browsers like chrome or IE. But when I send the exact same request from the WPF WebBrowser by loading the same page, somehow the encoding goes wrong. I'd like my WPF WebBrowser to send the POST request under specific encoding, but I can't find the way to do so. I'd be graceful for any advice. Thank you in advance.
What I've tried
I've inserted <meta encoding="~">to my html, also set <form charset="~"> on the form. But it still sends the invalid encoding request.
I've looked into my request's broken text and ran it through decoder which restores broken text into original one, so I could be confident that my request in WPF was encoded with UTF-8. Then I could find a WebBrowser.Document.encoding option. My defaultEncoding was set to UTF-8 and it caused all the problems. By fixing it to document.encoding = "myEncoding";, my problem was solved.
Related
Recently I have attended a training in mvc. The trainer said that - As per the security concerns we have to use HttpPost instead of HttpGet. Always use HttpPost.
Can anyone explain - what is the security issue when we use HttpGet?
When transmitting data over secure connection (https) body of the post request is encrypted and practically undreadable, you can only see address where data is going but not the data itself. Get on the other hand has no body and data has to be transmitted in either query string or as a path parameter. While it is true that query string does get encrypted as well, due to request logging on the server and browser it is possible to get hold of that data.
Anyone can insert image on public forum or stackoverflow with link to your web-site. Then happens next:
Browser looks at url in image tag
Browser find cookies corresponding to domain in url
Browser sends request to url with cookies of user
Your server performs action
Browser tries to parse response as image and fails
Browser renders error instead of image
But if you mark your action as Http Post only then this scenario isn't applicable for 90% of sites. But you should also consider that if hacker can create a form on other web-site then he still can make browser to perform request. So you need CSRF. Well, browsers made a lot to prevent cross-site requests, but it's still possible in some scenarios.
I've set up an HttpListener running on port 8086 on my custom server application, which works with JSON and XML over sockets. I can't change my server application to any other implementation, I am stuck with it for now.
I'm a bit new to Http, so feel free to correct my naviety below! I've searched, but can't find anything that deals with my exact problem.
When I use Hurl.it to send an HttpRequest to the server, the GetContext function fires no problem and I am able to send an html response back to Hurl.it.
Now, the question is, I want to be able to send out Reset Password email links in the form of "http://myip:PORT/resetpasswordseed=74283235" and have a browser be able to receive, parse and display a dynamically generated html form. (I will also need to add SSL to this a bit later, as I don't want a newly updated password being sent as plain text in a URL.)
Now, when I click the URL link http://myserverip:port/resetpassword with Edge or Firefox the GetContext function does not fire and the web browser times out. Have I missed something or am I trying to do something that is not possible? I don't get an error message or an exception or anything.
Any help would be appreciated.
Cheers
Craig.
In my Project i don't want to show query string values to users. For that case i used URL Rewriting in asp.net. So my URL Looks like below.
http://localhost/test/default.aspx?id=1
to
http://localhost/test/general.aspx
The first URL will be rewrites to second URL, but it will still executes the default.aspx page with that query string value. This is working fine.
But my question is that, is there any way the user can find that original URL in browser?
The answer is no.
The browser can't tell what actual script ended up servicing the request - it only knows what it sent to the server (unless the server issued a redirect, but then the browser would make a new request to the redirect target).
Since URL rewriting takes an incoming request and routes it to a different resource, I believe the answer is yes. Somewhere in your web traffic you are requesting http://localhost/test/default.aspx?id=1 and it is being rewritten as the new request http://localhost/test/general.aspx.
While this may hide the original request from displaying in the browser, at some point it did send that original URL as an HTTP GET.
As suggested, use Firebug or Fiddler to sniff the traffic.
I figured answer for my question. We can easily found the rewritten urls. If we saw the view source of that page in browser then we can see that original url with querystring values.
I´m sending the value of a variable via POST to a PHP page in C#. I get the data stream from the server that has all the web page in HTML with the value of the POST. This information is stored in a string variable.
I would like to open a browser and show the web page (maybe using System.Diagnostics.Process.Start("URL")), without having to save it in a file, this is showing the page in the moment and, when the browser is closed, no file is stored in the server.
Any idea?
Drop a WebBrowser control into a new form webBrowser1 and set its DocumentTextProperty to your result html
webBrowser1.DocumentText = ("<html><body>hello world</body></html>");
source:
<html><body>hello world</body></html>
You aren't going to be able to do that in an agnostic way.
If you simply wanted to open the URL in a browser, then using the Process class would work.
Unfortunately, in your case, you already have the content from creating the POST to the server, and you really want to stream that response in your application to the browser.
It's possible among the some browsers, but it's not able to be done in an agnostic way (and it's complicated even when targeting a specific browser).
To complicate matters, you want the browser to believe that the stream you are sending it is really coming from the server, when in reality, it's not.
I believe that your best bet would be to save the response to the file system in a temp file. However, before you do, add the <base> tag to the file with the URL that the file came from. This way, relative URLs will resolve correctly when rendered in the browser.
Then, just open the temporary file in the browser using the Process class.
I am trying to send a request to an url like this "http://mysite.dk/tværs?test=æ" from an asp.net application, and I am having trouble getting the querystring to encode correctly. Or maybe the querystring is encoded correctly, the service I am connecting to just doesn't understand it correctly.
I have tried to send the request with different browsers and logging how they encode the request with Wireshark, and I get these results:
Firefox: http://mysite.dk/tv%C3%A6rs?test=%E6
Ie8: http://mysite.dk/tv%C3%A6rs?test=\xe6
Curl: http://mysite.dk/tv\xe6rs?test=\xe6
Both Firefox, IE and Curl receive the correct results from the service. Note that they encode the danish special character 'æ' differently in the querystring.
When I send the request from my asp.net application using HttpWebRequest, the URL gets encoded this way:
http://mysite.dk/tv%C3%A6rs?test=%C3%A6
It encodes the querystring the same way as the path part of the url. The remote service does not understand this encoding, so I don't get a correct answer.
For the record, 'æ' (U+00E6) is %E6 in ISO-LATIN-1, and %C3%A6 in UTF-8.
I could change the remote service to accept the UTF-8 encoded querystring, but then the service would stop working in browsers and I am not really interested in that. Is there a way to specify to .NET that it shouldn't encode querystrings with UTF-8?
I am creating the webrequest like this:
var req = WebRequest.Create("http://mysite.dk/tværs?test=æ") as HttpWebRequest;
But the problem seems to originate from System.Uri which is apparently used inside WebRequest.Create:
var uri = new Uri("http://mysite.dk/tværs?test=æ");
// now uri.AbsolutePath == "http://mysite.dk/tv%C3%A6rs?test=%C3%A6"
It looks like you're applying UrlEncode over the entire URL - this isn't correct, paths and query strings are encoded differently as you've seen. What is doing the encoding of the URI, WebRequest?
You could manually build the various parts using a UriBuilder, or manually encode using UrlPathEncode for the path and UrlEncode for the query string names and values.
Edit:
If the problem lies in the path, rather than the query string you could try turning on IRI support, via web.config
<configuration>
<uri>
<iriParsing enabled="true" />
</uri>
</configuration>
That should then leave international characters alone in the path.
Have you tried the UrlEncode?
http://msdn.microsoft.com/en-us/library/zttxte6w.aspx
I ended up changing my remote webservice to expect the querystring to be UTF-8 encoded. It solves my immediate problem, the webservice can not be correctly called by both PHP and the .NET framework.
However, the behavior is now strange in browsers. Copy pasting an url like "http://mysite.dk/tv%C3%A6rs?test=%C3%A6" into the browser and then pressing return works, it even corrects the encoded characters and displays the location as "http://mysite.dk/tværs?test=æ". If then reload the page (F5) it still works. But if I click on the location bar and press return again, the querystring will become encoded with latin-1 and fail.
For anyone interested here is an old Firefox bugreport about the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=284474 (thanks to #dtb)
So, it seems there is no good solution.
Thanks to everyone who helped though!