var web = new HtmlWeb();
HtmlDocument doc;
doc = web.Load("https://facebook.com");
Using HTML Agility Pack, it works fine on Google and other sites, but not Facebook or Twitter. On those sites it gives error: "Additional information: '"utf-8"' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method."
I guess these websites are blocking the requests. I searched this error, but none of the solutions were on point. Is there a solution or workaround?
Related
I'm attempting to use BlockBlobClient in a browser page to upload a file using a server-supplied sastoken / URL, similar to this C# code:
var blob = new CloudBlockBlob(new Uri(assetUploadUrl));
blob.UploadFromFile(FilePath, null, new BlobRequestOptions {RetryPolicy = new ExponentialRetry()});
Although the docs suggest BlockBlobClient is available in #azure/storage-blob and should be able to upload browser data from an input[type=file] element using uploadBrowserData, I can find no reference to BlockBlobClient in the browser library source. I looked into modifying the browserify export scripts but I can't find any references in the main package source either. Also the example code suggests that using #azure/storage-blog gives you a BlobServiceClient by default:
const { BlobServiceClient } = require("#azure/storage-blob");
Is BlockBlobClient actually available in the JavaScript client library?
Okay I've figured this out, I need to use the Azure Storage client library for JavaScript, there's even a sample of doing exactly what I need to do. Now I just need to figure out how to bundle npm package files for use in Razor pages.
Using data URI in links (<a href="data:) is not supported in IE and Microsoft Edge (Data URI link <a href="data: doesn't work in Microsoft Edge).
I'm trying to use Modernizr to detect data URI in links support.
Modernizr.datauri is not quite what I'm looking for, as it does not tell anything about support data URI in links, e.g. for Microsoft Edge it returns object {over32kb: true}
How can I detect using Modernizr if data URI in links is supported in browser?
I had the same need for feature detection but I am not using Modernizr. My use case is that I'm generating a pdf on the client side with the makePDF library and was not able to open the PDFs using data URIs in IE or Edge. Unfortuantely, all the feature detection scripts I could find were testing for support of data URIs for images (which is supported by MS browsers) so I had to write my own. Here's the code (thanks to BoltClock's comment above for the idea):
checkDataURISupport(function (checkResult) {
if (checkResult) {
alert('Files in data URIs are supported.');
} else {
alert('Files in data URIs are NOT supported.');
}
})
function checkDataURISupport(callback) {
try {
var request = new XMLHttpRequest();
request.onload = function reqListener() {
callback(true);
};
request.onerror = function reqListener() {
callback(false);
};
request.open('GET', 'data:application/pdf;base64,cw==');
request.send();
} catch (ex) {
callback(false);
}
}
checkDataURISupport()
I tested in in IE 11, Edge 25, Firefox 46, and Chrome 49.
As a side note, another SO answer (https://stackoverflow.com/a/26003382/634650) suggested using:
supportsDataUri = 'download' in document.createElement('a');
This works in IE but not Edge.
Update
The SO answer above also includes a link to a SO answer referencing a Modernizr issue about feature detection for data URI in iframe support. Opening a data URI in an iframe is basically the same thing as opening one in a new windows and the Microsoft browsers which do not support data URIs in iframes don't support opening them in new windows. Additionally, the test for the iframe support mentioned in those locations is synchronous so I would recommend using it instead of my async solution.
It is weird that even Microsoft Edge is not supporting the data URI. Older versions of IE only allows base64 encoded images of up to 32KB. I had come across a reference link lately which relates to the similar issue you have mentioned with Moderinzr.
Does modernizr check for data uri's?#294
It appears they have added a patch for the issue. It is a data URI test.
This post has the similar answer regarding the issue. I hope these fixes should work throughout.
Webforms Page Code behind
XSettings.InstallRedistributionLicense("REDACTED");
var theDoc = new Doc();
theDoc.HtmlOptions.Engine = EngineType.Gecko;
theDoc.Rect.Inset(72, 144);
theDoc.Page = theDoc.AddPage();
int theID = theDoc.AddImageUrl("http://www.woot.com/");
while (true)
{
theDoc.FrameRect(); // add a black border
if (!theDoc.Chainable(theID))
break;
theDoc.Page = theDoc.AddPage();
theID = theDoc.AddImageToChain(theID);
}
for (int i = 1; i <= theDoc.PageCount; i++)
{
theDoc.PageNumber = i;
theDoc.Flatten();
}
Response.Buffer = false;
Response.AddHeader("Content-Disposition", "inline; filename=\"rept.pdf\"");
Response.ContentType = "application/pdf";
theDoc.Save(Response.OutputStream);
Response.Flush();
should work pretty well.. but get
Failed to add HTML: RPC to Gecko engine process failed.Remote process terminated unexpectedly.
Running Full trust
have in bin folder
XULRunner Folder and everything from C:\Program Files (x86)\WebSupergoo\ABCpdf .NET 9.0\ABCGecko
ABCGecko.dll
ABCpdf.dll
ABCpdf9-32.dll
Package / Publish Web All files in this project folder
You are not allowed to run external processes from within your Windows Azure Website as this would pose a risk in the shared infrastructure.
See this post by a MSFT employee or that post where the same employee talks about other restrictions concerned with native APIs.
You can verify that the problem is related to the externally launched Gecko by not adding the HTML image to the document. For me the creation of the PDF progressed further but failed because of the missing license.
It looks like you would have to find a fully managed/.NET HTML rendering engine (if converting a website to PDF is your use-case) or hope that reserved-mode web sites gain the right to execute native/external processes.
There are full ABCpdf Azure deployment guides here:
http://www.websupergoo.com/support-azure-abcpdf.htm
I'm new to Windows phone 7 application development. I'm currently developing an app in which I wish to do a HTML request and display the result obtained in Web browser. For example, Suppose I give the below URI
"http://m.imdb.com/find?q="+search_string (where search_string is a variable)
I want to take the result obtained from this and display it on the web browser. I've been searching regarding this for past 1 day... Didn't get any fruitful results. So please redirect me either to a suitable tutorial page or please give a sample code?
WebBrowserTask wbt = new WebBrowserTask();
wbt.URL = "http://m.imdb.com/find?q="+search_string
wbt.Show();
this will allow you to launch the url in the browser.
WebBrowserTask
In CRM 4.0 we could place dynamic content (aspx) in the ISV-folder in CRM, creating separate applications but with security and relative URLs to CRM, so for example a custom 360 view of account could be linked in an iframe using a relative URL along the lines of
/ISV/CrmMvcApp/Account.aspx/Overview?id=....
In CRM 2011 usage of the ISV folder is deprecated and Microsoft has some guidelines on how to transition into doing this in supported manner (MSDN gg309571: Upgrade Code in the ISV folder to Microsoft Dynamics CRM 2011). They say:
For scenarios that will not be satisfied by the Web resources feature, create your Web application in its own application pool with its own web.config.
The way I am reading this (coupled with the guidelines on supported/unsupported) is that we need a separate web site in IIS with its own binding as you are not allowed to add virtual directories etc. under the standard CRM app. This is unfortunate and does not allow relative paths/URLs in customizations and sitemap. This is troublesome especially when exporting and importing solutions from DEV, TEST and/or PROD.
Are my assumptions wrong?
Can we somehow have relative paths?
Have anyone else found a pragmatic and easy approach to having external content without doing the sitemap and customization changes for each environment?
EDIT: Confirmed with other sources that my understanding of the guidelines are correct, as this is also listed in the list of unsupported changes. Virtual folders and web apps are to be kept totally separated from the default CRM web site.
Creating an Internet Information Services (IIS) application inside the Microsoft Dynamics CRM website for any VDir and specifically within the ISV folder is not supported.
MSDN gg328350: Unsupported Customizations
If you primarily need to access CRM data/records, take a look at using a jScript web resources. You can do "most" CRUD operations using the REST OData services. If you use JQuery to parse the JSON it's very productive.
I have found a solution much like the javascript redirect, without the need for client execution and only configuring the environment details (servername, port) once. Additional logic can easily be added.
The solution creates a dependency into the customizations, but not an environment one like and can be used for unmanaged and managed solutions.
The solution was to place a file Redirect.aspx in the ISV folder. The code does not in any way interact with CRM and falls within the supported guidelines, however the solution is not future proof as the ISV folder is deprecated by Microsoft.
Redirect.aspxwill automatically pass along any parameter passed, so will work with or without the entity identifiers and so on.
Usage:
Place the file in the ISV folder on the CRM app server
Change the server name and port to match the current environment (must be done for each environment)
In customizations, for example for an iframe, use the following as a source:
/ISV/Redirect.aspx?redirect=http://SERVERREPLACE/CustomMvcApp/SomeControllerAction
Here is the content of Redirect.aspx
<%# Page Language="C#" %>
<html>
<script runat="server">
protected override void OnLoad(EventArgs e)
{
// must be customized for each environment
const string ServerBaseName = "appserver1:60001";
const string UrlParameterName = "redirect";
const string ReplacePattern = "SERVERREPLACE";
var parameterUrl = Request.Params[UrlParameterName].Replace(ReplacePattern, ServerBaseName);
var queryStringBuilder = new StringBuilder();
foreach (var key in Request.QueryString.AllKeys)
{
if (key == UrlParameterName)
{
continue;
}
queryStringBuilder.Append(!(queryStringBuilder.Length > 0) ? "?" : "&");
queryStringBuilder.Append(key + "=" + Request.QueryString[key]);
}
var completeRedirectString = parameterUrl + queryStringBuilder;
Response.Redirect(completeRedirectString);
}
</script>
<head>
<title>Redirecting</title>
</head>
</html>
Not quite "relative urls" as per your question, but a solution I use is to store "stub" or "root" urls in a config entity and read those records in JScript at runtime to determine the fully qualified destination for your custom links.