Case Insensative Compare - by Bob177

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


3
0
Sign in
to vote
ID 433836 Comments
Status Closed Workarounds
Type Suggestion Repros 1
Opened 4/20/2009 12:55:44 PM
Access Restriction Public

Description

System.Windows.Browser.HtmlDocument.QueryString returns a case sensitive implementation of IDictionary.  It should either default to case-insensitive or have that option built in, most developers would not want that strick a standard for a URL.

If the url was "...\mypage.html?callid=1" the code in the if block wouldn't get run

string callId;
if (System.Windows.Browser.HtmlPage.Document.QueryString.TryGetValue("callId", out callId))
{
....
}



Sign in to post a comment.
Posted by GearWorld on 1/5/2012 at 11:22 AM
However I'm very disapointed about this as the developpers would like at least to have this option as to not being forced to know the exact case of the string. Using the ContainsKey this isn't practicle. Another constructor would be very handy with the StringComparer.InvariantCultureIgnoreCase
Posted by Microsoft on 4/28/2009 at 2:59 PM
Thank you for your feedback. It is very valued. We have looked at this recommendation and decided not to fix it.

Our reasoning is as follows:
Silverlight's treatment of these identifiers is consistent with recommendations in the HTTP 1.1 specification: http://www.ietf.org/rfc/rfc2616.txt (Section 3.2.3 on URI Comparison) and language in the Architectural Principles of the World Wide Web: http://www.w3.org/2001/tag/2002/0828-archdoc#pr-uri-case. In the common use cases, the app developer will know precisely what the parameter name is, so our decision does not enforce an undue burden on them.

Thank you,
Silverlight Product Team
Posted by Microsoft on 4/21/2009 at 6:04 AM
Thanks for reporting this issue. We are escalating this suggestion to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team