Anti-sample Of The Day - Msxml3.XMLHTTP

http://www.quirksmode.org/js/xmlhttp.html

We have been reviewing different frameworks to see how they use MSXML progids - different versions of MSXML parser and XMLHTTP.
Look at this one:

Msxml3.XMLHTTP

Shame, the sample comes from PPKs highly credited web site http://www.quirksmode.org/js/xmlhttp.html
and if you google a bit you will see how this incorrect version is spread wide (copy-pase development ?).

This is MS XmlTeam suggestion using-the-right-version-of-msxml-in-internet-explorer(from 2006!).
After quick mailing with MS Team thay had confirmed there is no Msxml3.XMLHTTP ;-)

WARNING: Request.ApplicationPath and Forms Authentication

In previous post I have made some remarks about using Request.ApplicationPath concatenation with app. running in the root.

Another risc with this approach is related to "cookieless Form based autentication". In this case URLs contain auth. token as part of the URI path. However Request.ApplicationPath does not contain this token segment.

Thus using this "fixed: version of concat:

HyperLink2.NavigateUrl = Request.ApplicationPath.Length > 1 ? Request.ApplicationPath + "/foobar.txt" : "/foobar.txt";
is also incorrect, and will produce link without the auth. token.

loadXml MAY involve network activities

Argument that MSXML.loadXML cannot be async, because it is loading string and does not involve networking activity (which only can be async) is a bit wrong:

loadXML with string

<!DOCTYPE page [
<!ENTITY ent1 "internal">
<!ENTITY ent2 SYSTEM "test2.xml">
]>
<root>
<e1>&ent1;</e1>
<e2>&ent2;</e2>
</root>


will cause request to URL test2.xml (resolved against URI of the current page).
So Yes there is network activity with loading strings !.

Anyway even this scenario seems to behave synchronously (loadXml is blocking) even with async=true ;-)

"More on XML entities", and "Damned Defaults" are comming soon.... keep in touch

Anti-Sample Of The Day - Request.ApplicationPath +"/mypath"

Imagine the following 3 alternatives of setting link URI:

<asp:HyperLink ID="HyperLink1" runat="server" NavigateUrl="~/foobar.txt" Text="asp:HyperLink ~foobar.txt"/><br/>
<asp:HyperLink ID="HyperLink2" runat="server" NavigateUrl="" Text="HyperLink2.NavigateUrl = Request.ApplicationPath + '/foobar.txt';"/><br/>
<a href="<%=Request.ApplicationPath+"/foobar.txt"%>">Request.ApplicationPath+"/foobar.txt"</a>
<script runat="server">
protected void Page_Load(object sender, EventArgs e)
{
HyperLink2.NavigateUrl = Request.ApplicationPath + "/foobar.txt";
}
</script>


Run under /sample application (seems fine):
href=
1."../../../../foobar.txt"
2."/sample/foobar.txt"
3."/sample/foobar.txt"

Run under / (breaks links 2,3):
1."foobar.txt"
2."//foobar.txt"
3."//foobar.txt"



Source: MSDN, search for ApplicationPath samples. Or one is located directly under ApplicationPath docs:
http://msdn.microsoft.com/en-us/library/system.web.httprequest.applicationpath.aspx
with small excuse in Remarks section

Use this property to construct a URL relative to the application root from a page or Web user control that is not in the root directory.

BTW: In "equivalent Servlet API" getContextPath()" they have made decision elminating this sort of concat mistake:

The path starts with a "/" character but does not end with a "/" character. For servlets in the default (root) context, this method returns "".

Prove Me Wrong, please - First line of HTTP request

There is no reliable way to retrieve EXACT form of URI specified in the first line of HTTP request.
This applies to Servlet API (need for Cross-Container solution working at Tomcat, WebSphere 6.0.2,6.1,7.x , and others), as well as to ASP.NET Runtime (2+) on IIS 5.1 (and maybe others not tested) with standard modules in action.


Sniff:
GET /UriHandler.aspx/[%5d HTTP/1.1

Exected result:
/UriHandler.aspx/[%5d


Mission: tell me THE MAGIC API to achieve this.

Also wanted: description and comparative tables describing IIS and ASP.NET URL normalization with IIS 5,6,7, with/without URLScan and other URL related HTTP.sys and other settings. I mean complete IIS URL handling stack for all IIS versions ;-)

Anti-sample Of The Day - Cast, Null reference, If Too Late

Unbelievable what we can find on the net :-(

public void Init(HttpApplication context){
context.BeginRequest += delegate(Object sender, EventArgs ea) {
HttpApplication ha = sender as HttpApplication;
String absoluteUrl = ha.Context.Request.Url.ToString( ).ToLower( );
if (ha != null) {


Sample is called "Real World HttpModule Examples", subtitle of the web site is "... Home for AJAX, Silverlight, and .NET Technology, Architecture, and Elegance" Date of publishing 2007.
More bad news, author is MVP [ASP.NET] ;-(
http://www.netfxharmonics.com/2007/08/Real-World-HttpModule-Examples.aspx

loadXML,load(uri),load(dom) sync or async ?

This post is to clarify some of my statements presented in webreflection blog comments (do not want to waste your space Andrea).

"Official Documentation" (more cookbook than API specification)

• boolValue = oXMLDOMDocument.loadXML(bstrXML);
  
• boolValue = oXMLDOMDocument.load(xmlSource);
  
• oXMLDOMDocument.async
  

Question: is it guaranteed by "specification" that dom.loadXML is blocking regardless on dom.async property ? Do I have to write dom.async=false to perform intentional synchronous load of xml string ?

(not)Final Note

Since I have failed to "clearly" decrypt the documentation wording to come up with presentable argument I provide tests: Experiments show that current implementation of MSXML (all tested versions) show:

• async=false - load(uri) - IS BLOCKING
  
• async=true - load(uri) - IS NONBLOCKING
  
• async=true - load(dom) - IS BLOCKING (logical ?, documented ?)
  
• async=true - loadXML(string) - IS BLOCKING (logical ?, documented ?)
  

Usage of onreadystatechange is available in both async, and sync modes.
Would you write different code for load(uri) and load(dom/stream) ?
I do not.


For intentionaly synchronous code I will write async=false before any load (loadXml/load(dom)/load(uri))
and will continue processing after load exits (even if "runtime behavior" shows async=false as unnecesary for loadXml/load(dom)).


For intentionaly asynchronous code I will write async=true before any load (loadXml/load(dom)/load(uri))
(even if it's default) and will use readystatechange, and will not rely on load blocking (even if "runtime behavior" show that loadXml/load(dom) blocks).

Argument that loading string cannot be asynchronous is naive, anything can be made asynchronous even i++ if component designer decides to be and language + runtime features alow that ;-)