I have a browser-based InfoPath 2010 form. I'm getting an error opening the form in one environment. It works in at least three other environments. The error is:
The form template failed to load... Type: XmlException, Exception Message: For security reasons DTD is prohibited in this XML document. To enable DTD processing set the ProhibitDtd property on XmlReaderSettings to false and pass the settings into XmlReader.Create method.
I have seen this question posted around the Web, but the answers are vague and varied and are centered around products besides InfoPath. We also have other forms working in the environment where this form is failing, so it's something related to this particular form in this particular environment.
Problem solved. The error message was misleading, but turns out one of the data connections had a URL pointing to the wrong SharePoint farm. It was supposed to be pointing to the local form library. Cross platform calls tend not to work.
Basically make sure that the domain name in the connection file is matching the domain name where you're publishing your form.
For example, if your InfoPath form is located in:
https://extranet.MySiteName.com/The-Rest-Of-Your-Domain-Name
then make sure that all the domains (in this example extranet.MySiteName.com/)
in your data connection file match. The connection file line may look similar to this:
<udc:Query>
https://extranet.MySiteName.com/_vti_bin/My-WCF-Services/My-Data-ServiceName.svc/
</udc:Query>
Related
I am currently migrating from Tridion R5.3 to Tridion 2011. I am having issues with serving some pages through the presentation server. For reference all of my web pages are classic ASP and I am running them on IIS7.5.
I have have a page located at http://www.example.com/widget/index.asp. When I first access the page I get a The page cannot be displayed because an internal server error has occurred., if I then refresh the page it loads fine, if I refresh the page a third time it comes up with the error. The page works every other request.
I have enabled Failed Request Tracing on my website and I am getting the error
ASP_LOG_ERROR
LineNumber: 87
ErrorCode: 800706be
Description:
Note there is no description.
The code being called is
85: Dim objTranslationPageLink
86: Set objTranslationPageLink = Server.createObject("cd_link.PageLink")
87: strTranslatedPageLink = objTranslationPageLink.GetLinkAsString("tcm:0-12-1", "tcm:12-123456-64", "", "", "TranslationFound", False)
88: Set objTranslationPageLink = Nothing
It looks like there is no problems creating the cd_link.PageLink object, just when calling the GetLinkAsString(...) function.
I use the cd_link.PageLink object in lot of other pages with no problems but it seems with pages that use this specific piece of code experience the problems.
I was thinking it could be something to do with caching pages however I turned off caching of ASP pages (IIS7 > ASP > Services > Caching Properties) and still had the problem.
Any ideas?
edit1
The code worked fine on Windows Server 2003 IIS6. I am trying to make it work on Windows Server 2008 IIS7.
edit2
It appears that the page is creating a lot of cd_link.ComponentLink and cd_link.PageLink objects. I have a test page in which I create 10 ComponentLink objects I get the error (every other page) but if I reduce this to 5 ComponentLink objects it works every time.
edit3
My cd_core.xxxx.xx.xx.log has the following errors
2012-11-02 11:55:34,027 ERROR XMLConfigurationReader - Error while validating file 'cd_link_conf.xml' with schema 'schemas/cd_link_conf.xsd'. cvc-complex-type.3.2.2: Attribute 'DefaultRootLocation' is not allowed to appear in element 'Publications'.
edit4
Thanks for bearing with me. The problem I was having with my cd_link_config is fixed and doesn't appear to have been be related. I now have no errors in my any of the four log files (cd_core, cd_deployer, cd_monitor, cd_transport) but the original issue persists.
Looks like you are running the CD Link windows service and the following hotfix might help to resolve your issue. I have not tried this hotfix but the description says Page link fails on second attempt of accessing the page, so that means it might work sproadically depending on the logger memory resources.
Anyway worth looking at this hotfix : CD_2011.1.0.78355
Description: The Linking windows service was not correctly cleaning up a logger memory resource on certain windows platforms
It is a long time since I worked with Classic ASP and SDL Tridion, but double check the following
Is the linking service running on the server?
Check your cd_licenses.xml file is in place
Validate that you have a correct cd_link_conf.xml and cd_storage_conf.xml (these changed from 5.3 I believe)
Look in the Application and Tridion event logs for clues
The Tridion linking log files
That error code seems to imply that the Linking DLL is not registered properly.
That is all I can think of for now.
I didn't realise that 2011 actually schema-validates the config files, but in any case, now the error is clear. I'd suggest doing the validation yourself in an XML editor such as XML Spy. That should point out exactly what's wrong with the configuration file.
To routinely check your configurations, you may find it interesting to script it as described here.
I found in the error logs of my website requests made to URLs containing invalid characters. The URLs that are requested are made of pieces of code, e.g:
/Templat<div class="right-se
*The URLs are always a mix of pieces of code. Different parts from different places in the same page. Liket the example above, which the first part is a path to the CSS file and the second is a HTML tag.
I have been analyzing all the errors found to try to find a pattern, but no luck. They happen in different pages, of different types.
The only two pattern I seem to find is that all the URLs or most of the start with '/Templates' or a piece of that text '/T' and that all the errors are in IE7 and IE8
This is the error shown in the logs:
Class and function: Global.asax.Application_Error
Exception type:
Message: RawUrl: /T <div id=
Referrer path and query: /aboutus
User web browser: IE. Version: 8.0.
A potentially dangerous Request.Path value was detected from the client (<).
Stack trace: at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
I have not been able to reproduce the error in the test environment or production, and don't know really where to start looking at my code.
The website is made in ASP .NET running in IIS7 with .NET 4.0
Thanks
ASP .Net does a request validation for preventing different "hacking" attacks. When an input looks like that, it raises these errors.
Many crawlers scan websites, some might be asked to do this (your company paid for) other simply to find vulnerabilities and exploit them. The requested URLs might not look with something you have in the sitemap.
Sometimes I get 400 Bad Request error for different websites written on ASP.NET.
The only solution I know is to clean up cookies for that site. Seems like that the cause of problem is _utmz and _utma cookies, which belong to Google Analytics. The problem is occurs in common cases in Mozilla FireFox, sometimes on Ghrome and Safari and never in IE. This error occurs accidentally.
What I found:
From Stefan on the ASP.Net team:
http://forums.asp.net/p/1431148/3221542.aspx
In current versions of ASP.NET Urls
containing characters like the colon
character will be rejected as a
potential security threat. The
historical reason for this is that the
underlying NTFS file system supports
alternate resource streams that can be
accessed with names like
"yourfile.txt:hiddendata.txt".
Blocking the colon character from Urls
prevents poorly written applications
from accidentally working with
alternate resource streams.
There is also a limitation in current
versions of ASP.NET that incoming Urls
need to map to the NTFS file system
for purposes of determining managed
configuration data.
In ASP.NET 4 these limitations can be
optionally removed. However these
changes are in the Beta 2 version of
ASP.NET 4 - they are not in Beta 1. We
tried out the Url listed earlier in
this forum post and confirmed that
with our internal builds of ASP.NET 4
you can use that style of Url and
process it without any 400 error.
Is is a problem with ASP.NET runtime, cookie managment process of FireFox or Google Analytics code? What problem solutions do you know?
The issue is with the way that firefox handles special characters in cookies. It doesn't have anything to do with asp.net, you will have the error whatever language you are using.
The issue seems to occur most often with Google Analytics campaign sources. You should simply try to keep the values in these to alpha characters.
I have personally had to fix issues where people used an apostrophe and an mDash in their query strings. As a result I tell people to just avoid hyphens and apostrophes all together. If you aren't the one including them, you can't be sure they didn't copy a special character the browser can't handle.
This forum has a suggestion for clearing the bad cookies on the 400 page so that they can access the site properly.
There is already another question with the same problem on stackoverflow.
You need to make sure that you are not including any special characters before you set the campaign sources etc. Sources that are created dynamically through CMS newsletters etc. can include bad characters if they are not formatted aggressively. We have had trouble with people pasting MSOffice characters into titles and links which break cookies and stop the page from being served.
There is no solution to the problem other than making sure that you aren't sending bad data to GA and causing cookies to be corrupted.
Is there a way to share the session between ASP3 And ASP.NET?
Thanks
Despite all of Microsoft's best efforts to make ASP and ASP.NET coexist effortlessly, one area remains a stumbling block... session state. Fortunately the advantages of ASP.NET's upgraded session state management far outweigh the inconvenience of not being able to pass "Classic" session information to .NET. Unfortunately there is no simple solution; the most I can offer is an easy to implement workaround.
In trying to find a suitable resolution, I've come across two good options that are worth mentioning. The first involves parsing the session information out to hidden form fields on a "Classic" intermediate page and then submitting the page to a .NET intermediate page that loads the form fields into the session state. This is a good, simple solution, however it doesn't work both ways. In .NET you cannot specify the page that you submit to. Each page has to PostBack to itself.
The second option is probably closer to an actual solution than to a workaround. Billy Yuen at Microsoft has developed an effective solution. The code is elegant, the integration appears to be seamless, but I couldn't get it to work on my system (remember I said that there was no simple solution, not that there was no solution at all). If this solution works for you, great! You won't need my code and you'll be happily passing session information from "Classic" to .NET like it's going out of vogue, thanks for stopping by.
Ok, if you're still reading let me briefly describe the workaround I've created. It requires a database, but it is not important which type of database (though the code is written for SQL Server). When a page (source page) wants to redirect to another page (destination page) that uses a different version of ASP, it calls an intermediate page. The source intermediate page takes each session variable and adds it to the database along with a Globally Unique ID (GUID). Since "Classic" and .NET use different SessionID formats it is not possible to use SessionID, hence the use of a GUID. The source intermediate page then passes the GUID to the destination intermediate page through a Querystring variable. The destination intermediate page retrieves the session information from the database, cleans up after itself, and then redirects to the destination page. It's similar to the first workaround, but supports transferring state in both directions.
Code Usage
Installation
Run the SQL Query in "ASPSessionState.sql" on the database which will hold the temporary Session information.
Copy the .asp and .aspx.* (SessionTransfer.aspx and SessionTransfer.aspx.cs) files to a folder on your website.
Update connection object information in the "SessionTransfer.asp" and "SessionTransfer.aspx.cs" files. It is located in three places in each file (sorry about not consolidating the connection info).
Compile the aspx files.
The .asp and .aspx.* files must all reside in the same folder to work.
Usage
For use in a Hyperlink (Anchor Tag) or a Response.Redirect, set the destination URL to be one of the following:
From a ASP "Classic" page:
SessionTransfer.asp?dir=2aspx&url=<asp_dotnet_url>
From an ASP.NET page:
SessionTransfer.aspx?dir=2asp&url=<asp_classic_url>
The code will transfer the Session information and Redirect the user to the url specified by or .
Download
You can download the code from here: session_transfer.zip (4.6 KB).
Could take a look at NSession it allows sharing session state between Classic ASP and ASP.Net using State server. Pretty easy to setup just configure App to use State Server for session and register a couple of dll files.
I've noticed a lot of Microsoft sites have the *.MSPX extension. While I'm very familiar with ASP.NET, I've not seen this extension before.
Does anyone know what this identifies?
A few internet searches led me to http://www.microsoft.com/backstage/bkst_column_46.mspx, but it was a dead link. Fortunately, it was archived on the Wayback Machine and you can read it here:
http://web.archive.org/web/20040803120105/http://www.microsoft.com/backstage/bkst_column_46.mspx
The .MSPX extension is part of the "Microsoft Network Project," which according to the article above, is designed to give Microsoft's sites a consistent look-and-feel worldwide, as well as keep the design of the site seperate from the content. Here's the gist of the article:
The presentation framework includes a custom Web handler built in ASP.NET. Pages that use the presentation framework have the .mspx filename extension, which is registered in Microsoft Internet Information Services (IIS) on the Web servers. When one of the Microsoft.com Web servers receives a request for an .mspx page, this custom Web handler intercepts that call and passes it to the framework for processing.
The framework first checks to see whether the result is cached. If it is, the page is rendered immediately. If the page is not cached, the handler looks up the URL for that page in the table of contents provided by the site owner (see below) to determine where the XML content for the page is stored. The framework then checks to see if the XML is cached, and either returns the cached content or retrieves the XML from the data store identified in the table of contents file.
Within the file that holds the content for the page, XML tags identify the content template to be used. The framework retrieves the appropriate template and uses a series of XSLTs to assemble the page, including the masthead, the footer, and the primary navigational column, finally rendering the content within the content pane.
I think it's an XML based template system that outputs HTML. I think it's internal to MS only.
Well, a little googling found this:
The presentation framework includes a
custom Web handler built in ASP.NET.
Pages that use the presentation
framework have the .mspx filename
extension, which is registered in
Microsoft Internet Information
Services (IIS) on the Web servers.
When one of the Microsoft.com Web
servers receives a request for an
.mspx page, this custom Web handler
intercepts that call and passes it to
the framework for processing."
I'd like to find out more info though.
I love you guys, i was asking myself also many times, why MS uses .mspx and what it is at all?! :)
That time i couldn´t find any informations quickly and assumed it would just be something on top of asp.net or maybe not even that, because you should be able to assign the same asp.net cgi dll to .mspx also easy too ;)
But, surely, it can be anything.. also an "special" CGI itself (completely beside ASP.NET), which processes that request with much better / much more cache-use, easier editing and so on..
The end of the story was, that i came accross the view, that maybe it´s not important to know, what .mspx exactly is :)