Tone's Notes

It’s remarkably hard to search for syntax like “<%=” if you want to find something that speaks about the syntax rather than all the pages that use it.

I ran into a case where apparently identical code blocks in the same .ascx file were being treated differently. One was expanded and the other was treated as a literal.

The problem ended up being that a “runat=server” attribute had been added to the element with the failing code block.

I’m sure there’s a concise statement somewhere about how to escape code blocks and how they can be embedded in layers of quotations. I just haven’t found it yet.

Any pointers out there?

Signed up for Google’s free site search service.

Modified their template to the following:

<form id="searchform" method="get" action="http://www.google.com/custom">

<input type="hidden" name="cof"

 value="S:http://blogs.toneengel.com/;GL:0;AH:left;LH:60;L:http://blogs.toneengel.com/skins/btone/images/sggb60.jpg“

+“;LW:60;AWFID:b764e198d2896699;">

<input type="hidden" name="domains" value="blogs.toneengel.com">

<input type="hidden" name="sitesearch" value="blogs.toneengel.com">

<p id="searchlabel"><label for="q" accesskey="4">Search this site:</label></p>

<p id="searchinput"><input type="text" id="q" name="q" size="18" maxlength="255" value="">&nbsp;
<input type="submit" value="Search"></p>

</form>

But this works much better within an ASP.NET page:

function googleSearch(searchString) {

     var cof = "S:http://blogs.toneengel.com/;GL:0;AH:left;LH:60;L:http://blogs.toneengel.com/skins/btone/images/sggb60.jpg;“+

“LW:60;AWFID:b764e198d2896699;";

     var domains = "blogs.toneengel.com";

     var sitesearch = "blogs.toneengel.com";

     var q = escape(searchString).replace(/\+/g,"%2B");

     location.href="http://www.google.com/custom?cof="+cof+"&domains="+domains+"&sitesearch="+sitesearch+"&q="+q;

}

<input type="text" id="searchString" onkeypress="if (event.keyCode == 13) googleSearch(searchString.value);" >

<input type="button" value="Google" onclick="googleSearch(searchString.value);">

Thanks to Mark Pilgrim for putting me on to this service.

http://www.joelonsoftware.com/index.html

The documentation for the HttpRequest and Uri classes was a little thin on some of their properties, so I ran some experiments to figure it out. Quite a bit of clarify emerged along with a few quirks that suggested some design rules to work around. Here’s the executive summary along with the actual experimental results.

Summary:

1.      PathInfo is path-like information following the target page and preceding the query string. It is parsed in the Url.Segments array just like the rest of the path.

2.      Path = FilePath + PathInfo.

3.      Authority = Host + Port, if Port is non-standard, otherwise Authority = Host.

4.      Fragment is generally, but not always, missing from Request.Url.Fragment.

5.      Don’t assume the last Segments array item will be the filename of the executing page because of PathInfo parsing.

6.      All non-physical paths are relative. They contain no scheme, host, or port information.

7.      PathInfo can not be included in the argument to Server.Transfer. You get an exception.

8.      Never supply Query arguments or Fragment in a Server.Transfer. You’ll get unpredictable results when combined with IHttpModule RewritePath.

9.      The PhysicalPath property corresponds to the FilePath property and NOT the CurrentExecutionFilePath.

10.  The ONLY evidence of a server transfer (Server.Transfer) is in the CurrentExecutionFilePath property.

11.  The ONLY evidence of a rewrite (Context.RewritePath) is in the RawUrl property.

12.  Always use the three argument flavor of RewritePath.

Experiment 1:

The first experiment is a fully loaded request to a file “a.aspx” in the web server’s root folder. The server is running on port 82 instead of 80 to highlight the difference between Host and Authority properties.

Request: http://localhost:82/a.aspx/path/info?query=arg#fragment

Conclusions from Experiment 1:

1.      Path = FilePath + PathInfo

2.      There’s no trace of the fragment in any of the properties. Perhaps it is being consumed by the .NET Framework in some way.

3.      Authority = Host + Port

4.      Don’t assume the last segment is the executing file since PathInfo is parsed after it.

5.      The MSDN documentation for FilePath falsely suggests that it includes scheme and host fields.

Experiment 2:

The second experiment aims a similar request at a file “b.aspx” which immediately does a server transfer to “a.aspx”.

Request: http://localhost:82/b.aspx/path/info?query=arg#fragment

Transfer: Server.Transfer("a.aspx?st_query=st_arg#st_fragment")

Conclusions from Experiment 2:

1.      PathInfo can not be included in the argument to Server.Transfer.

2.      The PhysicalPath property does corresponds to the FilePath property and NOT the CurrentExecutionFilePath. Use MapPath on the CurrentExecutionFilePath to find out where the actual page you’re running is located.

3.      The query string and fragment in the argument to Server.Transfer are ignored in this case (but not in all cases, see Experiment 4).

4.      The ONLY impact of a server transfer to a.aspx is in the CurrentExecutionFilePath property. In all other ways the request still looks like the original to b.aspx.

Experiment 3:

The third experiment uses an IHttpModule to do a Context.RewritePath of a similar initial request. The rewrite attempts to alter the PathInfo and Query properties of the request.

Request: http://localhost:82/c.aspx/path/info?query=arg#fragment

Rewrite: Context.RewritePath("a.aspx", "/rw_path/rw_info", "rw_query=rw_arg")

Conclusions from Experiment 3:

1.      PathInfo can not be included in the argument to Server.Transfer. An exception is thrown if it is.

2.      The RewritePath PathInfo replaces the original query’s except for in the RawUrl property.

3.      The ONLY evidence of a rewrite is in the RawUrl property.

Experiment 3a:

A modification of the third experiment does a Rewrite without PathInfo or QueryString overrides to see what is preserved from the original request.

Request: http://localhost:82/g.aspx/path/info?query=arg#fragment

Rewrite: Context.RewritePath("a.aspx")

Conclusions from Experiment 3a:

1.      PathInfo must be explicitly transferred from the original query in a rewrite or it will be lost.

2.      Query arguments from the original query are preserved in a rewrite.

3.      In general, always use the three argument flavor or RewritePath and think carefully about what should happen to PathInfo and Query arguments.

Experiment 4:

The fourth experiment is a composition of two and three. The original query is rewritten by an IHttpModule to a page that does a server transfer to the page that finally responds to the request.

Request: http://localhost:82/d.aspx/path/info?query=arg#fragment

Rewrite: Context.RewritePath("b.aspx" "/rw_path/rw_info", "rw_query=rw_arg")

Transfer: Server.Transfer("a.aspx?st_query=st_arg#st_fragment")

Conclusions from Experiment 4:

1.      In this case the server transfer Query arguments and Fragment were transferred to the final request. Compare this to the behavior when just a server transfer is done in which there is no effect from supplying Query arguments or Fragment with the server transfer request. This suggests strongly that you NEVER supply Query arguments or Fragment in a Server.Transfer.

Experiment 5:

The last experiment is similar to Experiment 4 except it is run in an application folder two levels removed from the root folder and each step drops down an additional folder. The original request for f.aspx is rewritten into a request for rewrite/b.aspx, which does a server transfer to transfer/a.aspx. As usual, we attempt to inject alternate PathInfo, Query, and Fragment where possible.

Request: http://localhost:82/QEs/ASP.NET%20Web%20Application/f.aspx/path/info?query=arg#fragment

Rewrite: Context.RewritePath("rewrite/b.aspx", "/rw_path/rw_info", "rw_query=rw_arg")

Transfer: Server.Transfer("transfer/a.aspx?st_query=st_arg#st_fragment")

No surprises here.