The query string is composed of a series of field – value pair. Below is the pattern of query string:
field1=value1&field2=value2&field3=value3
An URL that contains query string can be depicted as follow:
http://TestFile.com/tag?name=Rajiv&role=Administrator
The URL and query string separated by a question mark (?). Query string consist of two parts (field and value), and each of pair separated by ampersand (&). So the example above consists of two query strings which are name and type with value of each field ‘Rajiv’ and ‘Administrator’ respectively.
Javascript can be used for retrieves query string values too. We need the following code to get query string pairs (field & value) using Javascript:
The above code will return string started with ampersand in the URL (ampersand included). So if we run the above code against the following URL: http://localhost:8088/postings/QrStr/TestFile.htm?name=Rajiv&role=Administrator
The return value is ?name=Rajiv&role=Administrator
To understand the concept better I have write two simple HTML pages that show how to get query string values using Javascript. This is the first file (testqrstr.htm):
<html>
<head>
<title>Test Query Strings: Index Page </title>
<script lang=”javascript” type=”text/javascript”>
function testQueryStrings()
{
// change the window.location with your own.
window.location = “/…/TestFile.htm?name=Rajiv&role=Administrator”;
}
</script>
</head>
<body>
<input type=”button” id=”btn” value=”Test Query Strings” onclick=”testQueryStrings()” />
</body>
</html>
The output produced by testjs.htm is similar like the output of Test.aspx, when we click the button it will bring us to TestFile.htm (of course with the specified query strings!). Here testjs.htm:
<html>
<head>
<title>Test Query Strings: Final Page</title>
<script lang=”javascript” type=”text/javascript”>
var qrStr = window.location.search;
var spQrStr = qrStr.substring(1);
var arrQrStr = new Array();
// splits each of pair
var arr = spQrStr.split(’&’);
for (var i=0;i<arr.length;i++){
// splits each of field-value pair
var index = arr[i].indexOf(’=');
var key = arr[i].substring(0,index);
var val = arr[i].substring(index+1);
// saves each of field-value pair in an array variable
arrQrStr[key] = val;
}
document.write(”<h1>Name parameter: “+arrQrStr["name"]+”. Role parameter: “+arrQrStr["role"]+”</h1>”);
</script>
</head>
<body>
</body>
</html>
What I was did in TestFile.htm just retrieve the query strings (through window.location.search), save each of field – value pair in an array variable named arrQrStr and echo the content of arrQrStr variable.
field1=value1&field2=value2&field3=value3
An URL that contains query string can be depicted as follow:
http://TestFile.com/tag?name=Rajiv&role=Administrator
The URL and query string separated by a question mark (?). Query string consist of two parts (field and value), and each of pair separated by ampersand (&). So the example above consists of two query strings which are name and type with value of each field ‘Rajiv’ and ‘Administrator’ respectively.
Javascript can be used for retrieves query string values too. We need the following code to get query string pairs (field & value) using Javascript:
The above code will return string started with ampersand in the URL (ampersand included). So if we run the above code against the following URL: http://localhost:8088/postings/QrStr/TestFile.htm?name=Rajiv&role=Administrator
The return value is ?name=Rajiv&role=Administrator
To understand the concept better I have write two simple HTML pages that show how to get query string values using Javascript. This is the first file (testqrstr.htm):
<html>
<head>
<title>Test Query Strings: Index Page </title>
<script lang=”javascript” type=”text/javascript”>
function testQueryStrings()
{
// change the window.location with your own.
window.location = “/…/TestFile.htm?name=Rajiv&role=Administrator”;
}
</script>
</head>
<body>
<input type=”button” id=”btn” value=”Test Query Strings” onclick=”testQueryStrings()” />
</body>
</html>
The output produced by testjs.htm is similar like the output of Test.aspx, when we click the button it will bring us to TestFile.htm (of course with the specified query strings!). Here testjs.htm:
<html>
<head>
<title>Test Query Strings: Final Page</title>
<script lang=”javascript” type=”text/javascript”>
var qrStr = window.location.search;
var spQrStr = qrStr.substring(1);
var arrQrStr = new Array();
// splits each of pair
var arr = spQrStr.split(’&’);
for (var i=0;i<arr.length;i++){
// splits each of field-value pair
var index = arr[i].indexOf(’=');
var key = arr[i].substring(0,index);
var val = arr[i].substring(index+1);
// saves each of field-value pair in an array variable
arrQrStr[key] = val;
}
document.write(”<h1>Name parameter: “+arrQrStr["name"]+”. Role parameter: “+arrQrStr["role"]+”</h1>”);
</script>
</head>
<body>
</body>
</html>
What I was did in TestFile.htm just retrieve the query strings (through window.location.search), save each of field – value pair in an array variable named arrQrStr and echo the content of arrQrStr variable.
QueryString property of Request Object. When surfing internet you should have seen weird internet address such as one below.
http://www.localhost.com/Webform.aspx?name=asp&article=framework
This html addresses use QueryString property to pass values between pages.
Disadvantages of this approach
private void btnSubmit_Click(object sender, System.EventArgs e)
{
string p1 = this.txtName.Text.Replace("&","%26");
p1 = this.txtName.Text.Replace(" ","%20");
string p2 = this.txtArticle.Text.Replace("&","%26");
p2 = this.txtArticle.Text.Replace(" ","%20");
string redirectweb= "WebForm.aspx?" + "Name=" + p1 + "&Article=" + p2;
Response.Redirect(redirectweb);
}
Since this is a such a common problem Asp.Net should have some way to solve. There it is Server.UrlEncode. Server.UrlEncode method changes your query strings to so that they will not create problems.
private void btnSubmit_Click(object sender, System.EventArgs e)
{
Response.Redirect("WebForm.Aspx?" +
"Name=" + Server.UrlEncode(this.txtName.Text) +
"&Article=" + Server.UrlEncode(this.txtArticle.Text));
}
http://www.localhost.com/Webform.aspx?name=asp&article=framework
This html addresses use QueryString property to pass values between pages.
Disadvantages of this approach
- QueryString have a max length, If you have to send a lot information this approach does not work.
- QueryString is visible in your address part of your browser so you should not use it with sensitive information.
- QueryString can not be used to send & and space characters.
private void btnSubmit_Click(object sender, System.EventArgs e)
{
string p1 = this.txtName.Text.Replace("&","%26");
p1 = this.txtName.Text.Replace(" ","%20");
string p2 = this.txtArticle.Text.Replace("&","%26");
p2 = this.txtArticle.Text.Replace(" ","%20");
string redirectweb= "WebForm.aspx?" + "Name=" + p1 + "&Article=" + p2;
Response.Redirect(redirectweb);
}
Since this is a such a common problem Asp.Net should have some way to solve. There it is Server.UrlEncode. Server.UrlEncode method changes your query strings to so that they will not create problems.
private void btnSubmit_Click(object sender, System.EventArgs e)
{
Response.Redirect("WebForm.Aspx?" +
"Name=" + Server.UrlEncode(this.txtName.Text) +
"&Article=" + Server.UrlEncode(this.txtArticle.Text));
}
The QueryString collection is used to retrieve the variable values in the HTTP query string.
The HTTP query string is specified by the values following the question mark (?), like this:
<a href= "MYTestPage.asp?id=24">Link with a query string</a>
The line above generates a variable named id with the value "24".
Query strings are data that is appended to the end of a page URL. They are commonly used to hold data like page numbers or search terms or other data that isn't confidential. Unlike ViewState and hidden fields, the user can see the values which the query string holds without using special operations like View Source.
An example of a query string can look like http://www.MyApplication.com/MYTestPage.aspx?id=24;active=1. Query strings are included in bookmarks and in URLs that you pass in an e-mail. They are the only way to save a page state when copying and pasting a URL.
Query strings are also generated by form submission, or by a user typing a query into the address bar of the browser.
if (Request.QueryString["id"] != null)
{
// Do something with the querystring
}
The only problem with the above check to see if the query string is null, is that we don't take into consideration if the query string is filled or not.
if (!String.IsNullOrEmpty(Request.QueryString["id"]))
{
// Do something with the querystring
}
Then there is the data type of the query string.
The Query String Structure
Query strings are appended to the end of a URL. First a question mark is appended to the URL's end and then every parameter that we want to hold in the query string. The parameters declare the parameter name followed by = symbol which followed by the data to hold. Every parameter is separated with the ampersand symbol.
You should always use the HttpUtility.UrlEncode method on the data itself before appending it.
Query String Limitations
Query string technique when passing from one page to another but that is all. If the first page need to pass non secure data to the other page it can build a URL with a query string and then redirect. You should always keep in mind that a query string isn't secure and therefore always validate the data you received. There are a few browser limitation when using query strings. For example, there are browsers that impose a length limitation on the query string. Another limitation is that query strings are passed only in HTTP GET command.
The HTTP query string is specified by the values following the question mark (?), like this:
<a href= "MYTestPage.asp?id=24">Link with a query string</a>
The line above generates a variable named id with the value "24".
Query strings are data that is appended to the end of a page URL. They are commonly used to hold data like page numbers or search terms or other data that isn't confidential. Unlike ViewState and hidden fields, the user can see the values which the query string holds without using special operations like View Source.
An example of a query string can look like http://www.MyApplication.com/MYTestPage.aspx?id=24;active=1. Query strings are included in bookmarks and in URLs that you pass in an e-mail. They are the only way to save a page state when copying and pasting a URL.
Query strings are also generated by form submission, or by a user typing a query into the address bar of the browser.
if (Request.QueryString["id"] != null)
{
// Do something with the querystring
}
The only problem with the above check to see if the query string is null, is that we don't take into consideration if the query string is filled or not.
if (!String.IsNullOrEmpty(Request.QueryString["id"]))
{
// Do something with the querystring
}
Then there is the data type of the query string.
The Query String Structure
Query strings are appended to the end of a URL. First a question mark is appended to the URL's end and then every parameter that we want to hold in the query string. The parameters declare the parameter name followed by = symbol which followed by the data to hold. Every parameter is separated with the ampersand symbol.
You should always use the HttpUtility.UrlEncode method on the data itself before appending it.
Query String Limitations
Query string technique when passing from one page to another but that is all. If the first page need to pass non secure data to the other page it can build a URL with a query string and then redirect. You should always keep in mind that a query string isn't secure and therefore always validate the data you received. There are a few browser limitation when using query strings. For example, there are browsers that impose a length limitation on the query string. Another limitation is that query strings are passed only in HTTP GET command.
Any COM component you have deployed today can be used from managed code, and in common cases the adaptation is totally automatic.
Specifically, COM components are accessed from the .NET Framework by use of a runtime callable wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET Framework-compatible interfaces. For OLE automation interfaces, the RCW can be generated automatically from a type library. For non-OLE automation interfaces, a developer may write a custom RCW and manually map the types exposed by the COM interface to .NET Framework-compatible types.
Managed types you build today can be made accessible from COM, and in the common case the configuration is totally automatic. There are certain new features of the managed development environment that are not accessible from COM. For example, static methods and parameterized constructors cannot be used from COM. In general, it is a good idea to decide in advance who the intended user of a given type will be. If the type is to be used from COM, you may be restricted to using those features that are COM accessible.
Depending on the language used to write the managed type, it may or may not be visible by default.
Specifically, .NET Framework components are accessed from COM by using a COM callable wrapper (CCW). This is similar to an RCW (see previous question), but works in the opposite direction. Again, if the .NET Framework development tools cannot automatically generate the wrapper, or if the automatic behavior is not what you want, a custom CCW can be developed.
Specifically, COM components are accessed from the .NET Framework by use of a runtime callable wrapper (RCW). This wrapper turns the COM interfaces exposed by the COM component into .NET Framework-compatible interfaces. For OLE automation interfaces, the RCW can be generated automatically from a type library. For non-OLE automation interfaces, a developer may write a custom RCW and manually map the types exposed by the COM interface to .NET Framework-compatible types.
Managed types you build today can be made accessible from COM, and in the common case the configuration is totally automatic. There are certain new features of the managed development environment that are not accessible from COM. For example, static methods and parameterized constructors cannot be used from COM. In general, it is a good idea to decide in advance who the intended user of a given type will be. If the type is to be used from COM, you may be restricted to using those features that are COM accessible.
Depending on the language used to write the managed type, it may or may not be visible by default.
Specifically, .NET Framework components are accessed from COM by using a COM callable wrapper (CCW). This is similar to an RCW (see previous question), but works in the opposite direction. Again, if the .NET Framework development tools cannot automatically generate the wrapper, or if the automatic behavior is not what you want, a custom CCW can be developed.
There are two aspects to in-process communication: between contexts within a single application domain, or across application domains. Between contexts in the same application domain, proxies are used as an interception mechanism. No marshaling/serialization is involved. When crossing application domains, we do marshaling/serialization using the runtime binary protocol.
Cross-process communication uses a pluggable channel and formatter protocol, each suited to a specific purpose.
If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about what channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic must travel through firewalls)
TCP channel w/ binary formatter (TCP is a higher performance option for local-area networks (LANs)
When making transitions between managed and unmanaged code, the COM infrastructure (specifically, DCOM) is used for remoting. In interim releases of the CLR, this applies also to serviced components (components that use COM+ services). Upon final release, it should be possible to configure any remotable component.
Distributed garbage collection of objects is managed by a system called "leased based lifetime." Each object has a lease time, and when that time expires, the object is disconnected from the remoting infrastructure of the CLR. Objects have a default renew time-the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.
Cross-process communication uses a pluggable channel and formatter protocol, each suited to a specific purpose.
If the developer specifies an endpoint using the tool soapsuds.exe to generate a metadata proxy, HTTP channel with SOAP formatter is the default.
If a developer is doing explicit remoting in the managed world, it is necessary to be explicit about what channel and formatter to use. This may be expressed administratively, through configuration files, or with API calls to load specific channels. Options are:
HTTP channel w/ SOAP formatter (HTTP works well on the Internet, or anytime traffic must travel through firewalls)
TCP channel w/ binary formatter (TCP is a higher performance option for local-area networks (LANs)
When making transitions between managed and unmanaged code, the COM infrastructure (specifically, DCOM) is used for remoting. In interim releases of the CLR, this applies also to serviced components (components that use COM+ services). Upon final release, it should be possible to configure any remotable component.
Distributed garbage collection of objects is managed by a system called "leased based lifetime." Each object has a lease time, and when that time expires, the object is disconnected from the remoting infrastructure of the CLR. Objects have a default renew time-the lease is renewed when a successful call is made from the client to the object. The client can also explicitly renew the lease.