I have a problem downloading particular file types by WebClient. So there are no problems with usual types - mp3, doc and others, but when I rename file extension to config it returns me:
InnerException = {System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
when I'm trying to access this file in browser (http://localhost:3182/Silverlight.config) - it's a usual xml file within - server returns me following error page:
Server Error in '/' Application.
This type of page is not served.
Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension '.config' may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /Silverlight.config
So I suppose this hapens because of some server configuration, which blocks files of unknown type.
downloading code is simple:
WebClient webClient = new WebClient();
webClient.OpenReadCompleted += new OpenReadCompletedEventHandler(webClient_OpenReadCompleted);
webClient.OpenReadAsync(new Uri("../Silverlight.config", UriKind.RelativeOrAbsolute));
completted eventhandler omitted for simplicity.
I'm not sure this is possible.
The .config extension is handled by the ASP.NET engine, for security reasons (sensitive data like connection strings need to be kept safe and hidden from unauthorized viewers).
This means that visitors cannot view your web.config file's content by simply entering "www.example.com/web.config" into their browser's adress bar.
EDIT : actually you can but I don't recommand it. If you really need to do it, you have to remove the mapping between the .config extension and ASP.NET ISAPI filter in IIS.
Related
In a TYPO3 9.5.3 demo installation I see multiple errors in the log looking this:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1518472189: The requested page does not exist
... and attempts to access sites (which don't exist) like this:
typo3_src-9.5.3:
Requested URL: http://demo.domain/ultxswkov.html
typo3_src-9.5.1:
Requested URL: http://demo.domain/hpwymspohv.html
Requested URL: http://demo.domain/txlkcgnaet.html
Requested URL: http://demo.domain/contact.php
Requested URL: http://demo.domain/kontakt.html
Requested URL: http://demo.domain/kontakt.htm
Requested URL: http://demo.domain/kontakt
Requested URL: http://demo.domain/contact-us.html
Requested URL: http://demo.domain/contacts.htm
Requested URL: http://demo.domain/contacts.html
...
In all my v.8 installations I never had such log errors. I assume somebody tries to access thoses sites? (For this specific domain I don't have a ssl certificate yet) What's the best practice to do now?
It seems that error 404 was not logged in TYPO3 8.x into sys_log. Atleast with default configuration. You can check the apache error log to see what happend in the past (with TYPO3 8.x). You should see many similar 404 errors there.
Every website in the internet has evil bots as visitors, so its nothing special with TYPO3 9.x.
The question "no additional security precaution needed?" is hard to answer. As long as your installation is secure, there is no problem.
Security Guidelines: https://docs.typo3.org/typo3cms/CoreApiReference/Security/Index.html
TYPO3 v9.5.0 - Error message: Requested page does not exist /robots.txt
I have a TYPO3 9.5.0LTS and use the bootstrap package theme. It seems to be all working ... but quite often I get such error messages:
Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1518472189: The requested page does not exist | TYPO3\CMS\Core\Error\Http\PageNotFoundException thrown in file /is/www/typo3_src-9.5.0/typo3/sysext/frontend/Classes/Controller/ErrorController.php in line 82. Requested URL: domain/robots.txt
What causes this and how to prevent this? Or how do I create a robots.txt in v.9.5 ?
In TYPO3 9.5 you can add a robots.txt in your Sites module.
Sites -> Choose your site -> Static Routes -> Create new.
Static Route Name: select "robots.txt"
Route Type: select "Static Text"
Static Text: Select "robots.txt Example Content"
Save. Should be fixed now.
This will work for all TYPO3 versions. For TYPO3 V9.x use the solution by Thomas Löffler.
Your server configuration (apache? .htaccess?) will hand over any request to a source that is no file and no directory and no symbolic link to the index.php file which is TYPO3.
In your case, you do not have a file robots.txt. So TYPO3 wants to handle it, but has no resource with that name. This creates a 404 error in TYPO3.
To prevent this, jst create the robots.txt file on your webserver in the DOCUMENT_ROOT folder
So what is a robots.txt file anyway.
This is a method to tell search engines how to behave on your server. It contains recomendations to the search engines' crawlers, when to stop crawling (like typo3_src folder). It is requested by the crawlers automatically and regularly.
When running GWTTestCase that call an external Restful service with GWT (Using Restlet-GWT) the app throws the error below.
Error:
Jan 05, 2015 1:24:41 PM com.gargoylesoftware.htmlunit.javascript.background.JavaScriptJobManagerImpl runSingleJob
SEVERE: Job run failed with unexpected RuntimeException: Wrapped java.lang.RuntimeException: No permitted "Access-Control-Allow-Origin" header.
net.sourceforge.htmlunit.corejs.javascript.WrappedException: Wrapped java.lang.RuntimeException: No permitted "Access-Control-Allow-Origin" header.
at net.sourceforge.htmlunit.corejs.javascript.Context.throwAsScriptRuntimeEx(Context.java:1889)
at com.gargoylesoftware.htmlunit.javascript.host.xml.XMLHttpRequest.doSend(XMLHttpRequest.java:681)
at com.gargoylesoftware.htmlunit.javascript.host.xml.XMLHttpRequest.access$000(XMLHttpRequest.java:94)
at com.gargoylesoftware.htmlunit.javascript.host.xml.XMLHttpRequest$1.run(XMLHttpRequest.java:603)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:602)
at net.sourceforge.htmlunit.corejs.javascript.ContextFactory.call(ContextFactory.java:507)
at com.gargoylesoftware.htmlunit.javascript.background.JavascriptXMLHttpRequestJob.run(JavascriptXMLHttpRequestJob.java:36)
at com.gargoylesoftware.htmlunit.javascript.background.JavaScriptJobManagerImpl.runSingleJob(JavaScriptJobManagerImpl.java:328)
at com.gargoylesoftware.htmlunit.javascript.background.DefaultJavaScriptExecutor.run(DefaultJavaScriptExecutor.java:162)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: No permitted "Access-Control-Allow-Origin" header.
... 9 more
From my research this seems to be an issue that HTMLUnit would not allow to access Cross-domain, is there a work around with this?
You can add the support of CORS to your application.
A support has been provided in 2.3 release of the Restlet framework (cf http://restlet.com/technical-resources/restlet-framework/guide/2.3/introduction/whats-new/2.3).
If you are using the 2.2 release, and because we won't add this feature to 2.2, you can add the required classes in your own code manually (cf https://github.com/restlet/restlet-framework-java/blob/2.3/modules/org.restlet/src/org/restlet/service/CorsService.java, https://github.com/restlet/restlet-framework-java/blob/2.3/modules/org.restlet/src/org/restlet/engine/application/CorsFilter.java, and https://github.com/restlet/restlet-framework-java/blob/2.3/modules/org.restlet/src/org/restlet/engine/application/CorsResponseHelper.java).
I was stumped by this very same error response but I am not able to refactor the Restlet framework into my client & server codebases.
A couple of tips for handling diagnosis of the problem.
use a proxy or inspect dev tool to record the exact headers within the request and response for both the OPTIONS and GET/POST pairs.
OPTIONS request header "Origin" must match response header "Access-Control-Allow-Origin" exactly. No wildcards. Perhaps write your response to just echo the request like:
response.addHeader("Access-control-allow-origin", request.getHeader("Origin"));
Your request header names must be fully enumerated within the OPTIONS "Access-control-request-headers" header value AND match the "Access-control-Allow-Headers" response header.
Note: that a mismatch in #3 will trigger the same error message as a mismatch in #2.
I have developed a REST Web service to get resources, I am able to access it through Java/Spring Template and even the xml response is coming if I type the URI on browser.
But when I invoke the same URI using XMLHttpRequest in Java script I am getting the below error.
"XMLHttpRequest cannot load URI(actual uri with server name ..etc) . Origin file:// is not allowed by Access-Control-Allow-Origin."
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101.
My JS code is as below.
xmlHttp = new XMLHttpRequest();
xmlHttp.open( "GET", "http://localhost:8080/rest/apps", false );
xmlHttp.send( null );
Please let me know what would be the problem and help me to resolve this.
Regards,
Sreedhar
here Origin is the local file system, that you're loading the HTML page, that load call via a file:/// . the request is from the same origin. If you're trying to load from somewhere else then you will not get the Error.
Check For this answer
I'm troubleshooting an existing webservice. It previously worked just fine, but now SOAP-based requests to the postgreSQL database result in an "unknown error: Error Fetching http headers" error.
In looking up this problem, I come across the following tip:
When you get errors like: "Fatal error: Uncaught SoapFault exception:
[HTTP] Error Fetching http headers in" after a few (time intensive)
SOAP-Calls, check your webserver-config.
Sometimes the webservers "KeepAlive"-Setting tends to result in this
error. For SOAP-Environments I recommend you to disable KeepAlive.
Hint: It might be tricky to create a dedicated vhost for your
SOAP-Gateways and disable keepalive just for this vhost because for
normal webpages Keepalive is a nice speed-boost.
I haven't been able to figure out exactly how you disable KeepAlive or where this parameter would be set. I've tried grep -i "keepalive" /usr/share/tomcat5/conf/*, result negative.
Perhaps due to the variability of server environments this is a question for my sysadmin, but I do have root privileges.
Thanks for your help, stack!
In your Tomcat's server.xml file, set the maxKeepAliveRequests attribute to 1 on your HTTP connectors to effectively disable keep alive.
For more information:
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Standard_Implementation