i integrating with an software, where they sending their document to my url with too large query string value. i.e. more than 75000 char for a parameter. i am in a R&D phase to check whether integration is works. i came to know that browsers will limit the query string. i want to get their document into to my server. i google but not get the answer. the url is in following fashion
Http:\\myurl?document=thierdocument in base64 encoded format
guide me to overcome the problem
This is not going to work. The query string is limited to a few thousand characters depending on the browser (i.e. 2083 characters for IE). Use a HTTP POST instead and put the document in binary format in the body of the request.
The main idea of a URL was to be a Uniform Resource Locator, not to pass all the data as part of the URL itself. You cannot work around the browser limits on URLs (neither should you arguably) - an alternative could be passing the document id in form of a number or Guid, then looking up that document to process as part of your page.
My suggestion is to move the data from query string, to post form.
My suggestion is to move the data from query string, to post form.
Why ?
one reason is the the url data, including your big string, is used to know if the page is going to cached by the browser or not. So I think that browser him self have a problem remeber this big string.
other reason is that this url is travel as it is, a big one, and is very possible to not reach the target.
The 2083 charatercs in IE I think that is refered only on URL, not on the included data.
You will have to do it using POST query.
Taken from What is the limit on QueryString / GET / URL parameters?
The spec for URL length does not dictate a minimum or maximum URL
length, but implementation varies by browser. On Windows: Opera
supports ~4050 characters, IE 4.0+ supports exactly 2083 characters,
Netscape 3 -> 4.78 support up to 8192 characters before causing errors
on shut-down, and Netscape 6 supports ~2000 before causing errors on
start-up.
Related
I need to validate user input for an href on the server side and need to make sure only http:// and https:// are allowed as a protocol (if specified at all.) The objective is to eliminate possible malicious code like javascript:... or anything alike.
What makes it difficult is the number of ways the colon could be encoded in such string e.g. :, :, :, : , :. I'd like to transform the value and see it as the browsers do before they render the page.
One option could be building a DOM document using AngleSharp as it does the perfect job when parsing attributes. Then I could retrieve the value and validate it but it seems somewhat of an overkill to build the whole DOM tree just to parse one value. Is there a way to use AngleSharp to parse just an attribute value? Or is there a lib which I could use just for this task?
I also found this question, but the method used in there does not really parse the URIs the way browsers do.
You want the HtmlDecode() method. You may need to add a reference to the project to use it.
I have a web page that uses a webmail service to send emails. This is on an company intranet using a Microsoft Exchange server. My website created an email with a link to an image handler on my website. In my code, I can print some debug messages and I see:
<img src='http://tav.target.com/VIBEHandler.ashx?id=z064441_45975&type=Amazing'/>
But in the email, when I view the source code, I see this:
<img src="http://tav.target.com/VIBEHandler.ashx?id=z064441_45975&type=Amazing"/>
My single quotes changed to double quotes (no big deal).
&
changed to
&
This causes the URL to not work and images appear as the red "x", indicating a missing image.
How can I preserve my URL?
Your 3rd party emailing service might be converting your HTML document to a valid XML document for compatibility reasons.
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
Basically, in XML, an ampersand character represents and XML entity, and can not be used unless you place the text within a CDATA node. Your 3rd party service seems to just be converting the & to & , which would work to safely display the value, but doesn't do too much for a URL.
http://www.w3schools.com/xml/xml_cdata.asp
If I were in your situation, I would URL encode the image URL when generating the HTML document that is being sent out. This way, it is both a proper link, and a valid XML string.
HttpUtility.UrlEncode(myUrlString);
http://msdn.microsoft.com/en-us/library/4fkewx0t%28v=vs.110%29.aspx
Hope this helps!
The best solution we could come up with is to use a single variable with multiple values separated with an underscore. This eliminates the need for the '&' symbol entirely and makes everything happy and compatible.
The URL is basically a link to an image handler so we can include images in emails without the use of attachments, shared drives, etc. The image handler can also do things like merge images together to create a single image (WAY better than trying to overlap images in emails which almost NEVER works). I simply added some code to the image handler that can check for and dissect the "meta-variable" in my URL.
http://sample.com?var=ONE_TWO_THREE
http://sample.com?var1=ONE&var2=TWO&var3=THREE
The URL now looks more clean and can have as many variables as I want so long as I put everything in the exact correct order, read it all in using the same sequence, don't miss anything, and document everything well. I COULD go one step farther and specify what each variable means:
http://sample.com?var=first-Nicolai_last-Dutka_age-34_etc-foobar
But that just tells the whole world what all my variables mean! Hypothetically, I could do:
http://sample.com?var=24154#kja&nl897q45pjkh8&&^HJ435
Then it would be up to me to determine where the breaking points are to bust that up into the variables:
24151, kja*, n1897, 45, etc
Of course, I'm not going to be that complex and will likely just stick to:
http://sample.com?var=ONE_TWO_THREE
Enjoy!
I'm working with SSRS 2008 R2 with the ReportService2010 soap endpoint with the ReportExecutionService.
For parameters that have large values, SSRS has some smarts to automatically tokenize a drill-down report URL (summed up nicely in this thread):
The problem is related to the RS System Property
StoredParametersThreshold. This value (defaults to 1500) determine
the number of characters a URL can contain before SSRS replaces that
URL with a token. The reason for this functionality is that some
browsers/servers limit the URL length of a URL. Since report
parameter value combinations can be really long, we try to be smart
and tokenize the URL so that the URLs will work. A possible work
around is to increase the value of StoredParametersThreshold.
The URL (decoded for easier viewing) looks something like this:
http://iprod-ssrs/ReportServer?http://iprod-reports/admin/web/Report+Library/Drill-down+Companyids.rdl&rs:StoredParametersID=cjesl5vk0y2tbv55e1qjrz55&rs:ParameterLanguage=&rc:Parameters=Collapsed
The problem is, in my custom viewer, I cannot use these tokenized URLs and need to retrieve the actual parameter name/value so that I may execute the drill-down report.
Is it possible to get the parameter values using the rs:StoredParametersID key?
According to this post from 2010 you can't retrieve the actual parameters http://social.msdn.microsoft.com/Forums/en/sqlreportingservices/thread/6809f9e3-b411-4f05-96a6-47e273220a70 though maybe that's changed. Good luck!
I have windows application in which web page is loaded using the windows (.NET) browser control. The windows application needs to send some information to the web page (aspx) and now it's achieved using query string.
Now we want to send more details which may be in the XML format.
How can we pass the large amount of data (like XML) in such case?
If you want to send (more) data, you should use method POST. (That way you don't really need to care whether it's XML or something as long as the particular form can handle it correctly.)
Query string should be used only to specify the resource. Typically query string is used with GET method like http://server/giveme.php?report&number=123. (If that string is used with browser, it should open connection to server:80 and say GET /giveme.php?report&number=123. (Then some headers follow, etc.)
Use of POST is very similar except that after the method, URI (/hereis.php?report&number=124) and some HTTP headers, also data is sent (which can really be any data).
Also remember that GET is supposed to be used only for queries: you can call GET /giveme.php?report&number=123 a thousand times and you should still get the same report no. 123 (or some updated version). (So GET should not be used to send data, but to get data.)
For POST, this is not expected: Each time POST from you is accepted, you actually post some data to the server, and normally you should not get away with doing POST /hereis.php?report&number=124 multiple times. (Well, you can design your application to accept POST /hereis.php?report, but that's up to you and it's another story.)
I have a Silverlight application that is building a URL. This URL is a call to a REST-based service. This service expects a single parameter that represents a location. The location is in the form of "city, state". To build this URL, I'm calling the following code:
string url = "http://www.example.com/myService.svc/";
url += HttpUtility.UrlEncode(locationTextBox.Text);
If a user enters "chicago, il" into locationTextBox, the result looks like this:
http://www.example.com/myService.svc/chicago%2c+il
In reality though, I was kind of expecting the URL to look like;
http://www.example.com/myService.svc/chicago,%20il
When testing my service via the browser URL, the one I am expecting works. However, the URL that is being generated is not working. What am I doing wrong?
I would recommend Uri.EscapeDataString instead of using HttpUtility functions. See discussion in Server.UrlEncode vs. HttpUtility.UrlEncode.
Try to use the UrlPathEncode() method.
View the remarks at:
http://msdn.microsoft.com/en-us/library/h10z5byc.aspx
Quote:
You can encode a URL using with the
UrlEncode() method or the
UrlPathEncode() method. However, the
methods return different results. The
UrlEncode() method converts each space
character to a plus character (+). The
UrlPathEncode() method converts each
space character into the string "%20",
which represents a space in
hexadecimal notation. Use the
UrlPathEncode() method when you encode
the path portion of a URL in order to
guarantee a consistent decoded URL,
regardless of which platform or
browser performs the decoding.
The safest bet is to use the AntiXss library. It has more standard (and secure) versions for encoding contents to various purposes (like Url encodes, Html and HtmlAttribute encodes, and more).
there's the old 3.1 version available for download from MS site (http://www.microsoft.com/downloads/details.aspx?FamilyId=051ee83c-5ccf-48ed-8463-02f56a6bfc09), which will work with older .NET versions, and the new one at http://wpl.codeplex.com/