Just a quick reminder to myself, so that I can forget about it...
Fiddler can act as a man-in-the-middle and decrypt SSL traffic, but then System.Net.Security rightfully complains about an invalid remote certificate ("The remote certificate is invalid according to the validation procedure."). This results in a System.Net.WebException "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.".
To prevent this from happening:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
Just be sure to not include this in production code :-)
Two weeks ago, an ex-colleague asked me to take a look at a problem that he and his team had encountered. They tried using a System.Uri with URL-encoded slashes, but those slashes kept ending up unencoded in the resulting URI:
Uri uri = new Uri("http://somesite/media/http%3A%2F%2Fsomesite%2Fimage.gif");
Console.WriteLine(uri.AbsoluteUri);
// Output: http://somesite/media/http%3A//somesite%2Fimage.gif
That's a totally different URL, which the target server refuses to process.
I was sure that they must have overlooked something, and that there would be some way to tell the Uri constructor to leave all encoded characters as-is. But no, it does not seem possible; dots and slashes are always decoded. I find that quite surprising, so if anyone can point me to an official solution, I'd be much obliged.
In the mean time, a reflection-based hack, courtesy of Reflector and the .NET Reference Source:
static class UriHacks
{
// System.UriSyntaxFlags is internal, so let's duplicate the flag privately
private const int UnEscapeDotsAndSlashes = 0x2000000;
public static void LeaveDotsAndSlashesEscaped(this Uri uri)
{
if (uri == null)
{
throw new ArgumentNullException("uri");
}
FieldInfo fieldInfo = uri.GetType().GetField("m_Syntax", BindingFlags.Instance | BindingFlags.NonPublic);
if (fieldInfo == null)
{
throw new MissingFieldException("'m_Syntax' field not found");
}
object uriParser = fieldInfo.GetValue(uri);
fieldInfo = typeof(UriParser).GetField("m_Flags", BindingFlags.Instance | BindingFlags.NonPublic);
if (fieldInfo == null)
{
throw new MissingFieldException("'m_Flags' field not found");
}
object uriSyntaxFlags = fieldInfo.GetValue(uriParser);
// Clear the flag that we don't want
uriSyntaxFlags = (int)uriSyntaxFlags & ~UnEscapeDotsAndSlashes;
fieldInfo.SetValue(uriParser, uriSyntaxFlags);
}
}
Triggered by Brent Strange's recent Defect of the day, I remembered a few similarly Zen-like ones from a product I worked on years ago:
Looking for information about IRIs, I ended up at W3C's Internationalized Resource Identifiers page. Funnily enough (if you're a Unicode geek, that is...), this page deals with i18N topics but has an encoding issue:
(I've notified W3C's web-human about the fact that the page is served as UTF-8, but contains Latin-1 characters.Updated on 2008-04-29: The page has been fixed.)
When I was enjoying my sabbatical last year, I'd set up my LinkedIn profile to read "Principal Sabbatical Enjoyer at home".
Ever since, I've been receiving notifications from LinkedIn, telling me to get back in touch with colleagues from home:
