We are currently moving an EE6 / JSF application from a deployment path someserver.com/app to its own subdomain app.someserver.com.
Most things are working smoothly, but we have had unexpected troubles with how the web layer handles the now basically nonexistent context-root.
One thing we found and fixed early was that a cookie we set had its path shortened from "/app" to "", and thus was only readable per folder on the server, not for the entire application.
We have now found a similar problem with hyperlinks that we generate in JSF:
Go to home page
This was previously rendered as href="/app" and worked fine, but now with href="" the link is understandably no longer active. I want it to say href=""/".
Is there an elegant solution for that?
Keep in mind that we also have links of the form
Go to projects page
, so simply replacing the empty context path with "/" is not good enough.
Am I missing something obvious? I saw an explanation here (which matches what we experience), but no elaboration on possible solutions.
Turns out I wasn't thinking clearly. I was so focused on fixing the string that #{request.contextPath} produces, that I missed that I basically used it wrong the entire time.
The simplest solution is to just use
...
(with a trailing slash) to get to the root of the application, and never use href="#{request.contextPath}" without a slash at all.
This solves both cases. If the application is deployed to "some_folder", the link becomes "some_folder/". And if the application is deployed to the server root, then the link becomes "/".
Hope this helps someone who stumbled into the same trap.
I'm trying the Branch.io API and I think I'm getting a weird problem because I'm not able to create my links properly: I can use the link for starting the app without parameter: this link http://4t3i.app.link/KDSYTMnSZs.
It works perfectly but as soon as I try to put some parameter following the doc for appending query parameters, it returns a File Not Found Webpage.
I tried:
https://4t3i.app.link/a/?&jobId=saucisse
https://4t3i.app.link/a?%24deeplink_path=article%2Fjan%2F123&%24fallback_url=https%3A%2F%2Fgoogle.com&channel=facebook&feature=affiliate&user_id=4562&name=Alex (that's the example they give)
I have the feeling I'm really missing something but no idea what. Is that so easy to add parameters: just a/ and then appending parameters??
Alex from Branch.io here:
We recently made a major back-end change to accommodate some new technical limitations that Apple imposed with iOS 9.3.1, and unfortunately it looks like we didn't fully update all our docs yet!
Your links are correct, but the /a is no longer necessary. So they would be:
https://4t3i.app.link?&jobId=saucisse
https://4t3i.app.link?%24deeplink_path=article%2Fjan%2F123&%24fallback_url=https%3A%2F%2Fgoogle.com&channel=facebook&feature=affiliate&user_id=4562&name=Alex
When you open these, you'll be able to see the link clicks coming through on this dashboard page
Thanks for noticing this. I'll make sure we get the documentation changedto reflect the new system.
Edit: also note that those examples above create new links with the specified parameters. If you simply want to append an additional parameter to an existing link, you'd do this: http://4t3i.app.link/KDSYTMnSZs?jobId=saucisse
We're (me, a colleague and an outsourced dev) building an iOS webDav navigation App which we believe is having trouble validating a URL.
We're accessing a webdav server via the app. One of servers which is https://webdav.microdigit.org.uk/test/ works perfectly.
However our main server which is https://vpn.westbuckland.devon.sch.uk/webdav/ doesn't work.
It seems to be due to the extra dot in the URL but we're not sure.
This is our current expression:
NSString *myregex = #"\\bhttps?://[a-zA-Z0-9\\-.]+(?::(\\d+))?(?:(?:/[a-zA-Z0-9\\-._?,'+\\&%$=~*!():#\\\\]*)+)?";
It just seems odd that the app will connect to a standard length URL such as https://vpn.something.com/ or even starting from a subfolder such as https://vpn.something.com/webdav/
You can then go one more and add another "dot" to the URL such as https://vpn.something.org.uk/webdav
However when you go one further it will connect to https://vpn.something.edu.org.uk/webdav/ but when you start trying to load a file or navigate the file structure, it reports a 404 in the debugger as if the files are not found.
Is it the extra dot in the URL? It seems to be the only thing we can think of. Our outsource dev has been pretty good so far in debugging most of our code (which was a purchased fully licensed base) but we're now reaching the end of the road. If anyone believes it is the regex expression. What would someone recommend we use instead?
I've got an article in Main.
I want to link to it from another Web, call it Acme.
I've tried
Main.MyLink
%Main%MyLink
but can't get it to work.
What do I do now?
The general syntax for that is
web.topic
so you should be fine with
Main.MyLink
if you want to link to a topic MyLink in a web named Main. If your web Acme (or your whole wiki) has disabled auto-linking in the preference settings, you need to use the square brackets notation, e.g.
[[Main.MyLink]]
or
[[Main.MyLink][my link]]
Quite not sure why I see this error.
I navigate to my Login View like so http://test.staging.com/mywebsite/Login
My Login view was just redone using MVC but I have seen this same error message going to an aspx page as well...
If I use http I get the error message The specified request cannot be executed from current Application Pool.
If I use https://test.staging.com/mywebsite/Login, I'm good.
If I don't specify a protocol, test.staging.com/mywebsite/Login, I get the error as well
Is there an error happening under the covers and my custom error page can't be shown like discussed here?
What are some other causes of this error?
That usually means your custom errors are configured to run as a different AppPool.
You can read more at MSDN. (See section "Using Custom Errors from Another Application Pool").
There are two ways to correct this behavior. The first is possibly not one that you are interested in because it would require you to change your current architecture and run both sites in the same application pool (such as share the same worker process memory space). To do this, simply move the /errors virtual directory to run in the same application pool as the site for which it serves the custom error.
The second way is to make use of a registry key provided by IIS 6.0. This registry key makes sure IIS 6.0 does not check the metadata during the execution of the custom error and therefore allowing this to work.
See the article for information on the registry key fix.
It may also mean that you are using something along the lines of Server.Transfer to a page that is in a different AppPool.
It could be because you're using different versions of ASP.NET for one or many apps in the pool.
Make sure all apps in the pool use the same version of ASP (e.g. ASP 2.0.50727)
If you just added a new app, try changing the app momentarily to a different version of ASP, then back to same version. I experienced an issue where the displayed version was correct, but under the hood, a different version was used!
Check your event log, under Application, to get more details about the error.
The message would be caused by your page server-side redirecting to a page served by another application pool. Such as for example, in your link, the error page.
I know this is an old thread, but I stumbled upon it and found a different solution. Here's what worked for me: Make sure your application handles .asmx files correctly
From IIS:
Right Click on your project > Properties > Configuration
If necessary, add the .asmx file extension that maps to the aspnet_isapi.dll
Limit to: "GET,HEAD,POST,DEBUG" and restart.
Because I can't comment on vcsjones's answer, I'll add it down here. The DWORD value IgnoreAppPoolForCustomErrors needs to be set under HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\ Parameters vs HKLM\SYSTEM\CurrentControlSet\Services\W3SVC referenced in that technet article. Set it to 1 and do an iisreset and you're good to go.
Source Blog Post
In my particular case, I received this error while trying to serve a content (non ASP.NET) website while it was an Application. Right-Clicking the virtual folder and removing the application fixed it for me.
In my case the application used the application pool that didn't exist. I have no idea how it's happened.