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?
Related
I'm working on a rather large legacy web app with the following stack: nginx, Django, React with React Router.
My problem is that any URL that I load gets a # appended to one before end if the last char is a /.
So https://dev.local/feed/ becomes https://dev.local/feed/#/,
and https://dev.local/create/?fid=user8:13/ becomes https://dev.local/create/?fid=user8:13#/.
I've investigated everything on the front end side. I'm using browserRouter, not hashRouter. I only have one router in my front end. I suspect this is coming from the back end, but not ruling out the front end. Edit: tried completely commenting out the router - the problem persists.
My question is how do I generally approach debug something like this? Browser debug tools - console, network, etc are not showing any redirects or URL rewrites. What would work here?
The issue disappeared after I ripped out a large node module with a lot of subdependancies (old version of spectacle). The list of subdependencies is quite extensive, and it's hard to pinpoint what solved the problem. Nothing obvious could be seen, like multiple version of react-router or history modules.
I'm making a website in Erlang, but I'm having troubles. I installed Chicagoboss and the server starts, but I have a problem. They say to go to this page localhost:8001/pages/index when i go to this page I get an error:
No routes matched the requested URL. (Don't worry, this message will not appear in production.)
I did not do anything, I coded the file in src/controllers/main.erl. What am I doing wrong?
I've never used ChicagoBoss, but this question is extremely basic and you should read carefully tutorial before asking. Take a look how the requested URL is dispatched:
host:port/yourcontroller/youraction
will invoke function like
youraction('GET', []) ->
{output, "Hello World!"}.
from file src/controller/PROJECT_yourcontroller_controller.erl. This sample works out of the box. In general case look at PROJECT/priv/PROJECT.routes to define rules to bind URL patterns to their controllers actions.
We've written a webservice dll with Delphi XE2 and it is running in our IIS7 server, accessible with the url http://server/webservice.dll/soap
To be able to debug the service, I've created a webservice.exe project, which can be run in the WebAppDebugger of Delphi. The problem now arrises that the webservice running in the debugger is accessible with the url http://localhost/webservice.webservice/soap
Our client application has the last part of the url "webservice.dll/soap" hardcoded (security reasons) so i cannot change that when testing with our client application, the server-address part "http://server/" is configurable in the client.
So, my question: How can i register the debug service in my webappdebugger to use an url like my production dll?
I've found the solution myself ;-)
In the initialization of the debugform there was the following line:
TWebAppSockObjectFactory.Create('Webservice');
changing this to:
TWebAppSockObjectFactory.Create('dll');
made the overall address change to http://localhost/Webservice.dll/
This did leave a small problem that the debugger project had to be renamed to Webservice.exe in stead of WebserverDebug.exe as it was called, but moving it to subfolder made this rename possible.
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.
For web development on localhost I'm using domains with .loc extension at the end of a domain name.
For example: if I work on a site roses.com, the local development domain would be roses.loc
(defined in hosts file and IIS as a host-header in binding)
My preferred browser (the main browser I use for development is Chrome) but unfortunately
it does not recognize a domain name with .loc extension as http://rose.loc - it throws me onto a google search page each time I would type in rose.loc (without http://) in the beginning..
Have you experienced this in a similar way ? Is there some solution to that ?
Because during intensive development testing with clearing browser cache and restarting the browser for various reasons, it's getting pretty annoying to be thrown at a google search page instead of the development page where I expect to notice some changes, each time I forget to type in http:// before the url (and Chrome is the one who hides it by default, anyway..)
Google Chrome is pretty "smart" with this. It uses a list of known-good TLDs and assumes everything else is just a search term that happens to end in a dot followed with some characters.
99% of the time that's perfectly fine. It's "only" us developers and a few people with strange network setups that have to suffer for the good of the majority ;-)
You can try using .local as your TLD, as that's a defined domain for referencing local domain names (at least it's used in some mDNS systems).
The issue has been entered as #30636 in the Chromium bug tracker. One workaround that often (but not always) seems to work is to append / to your hostname. So try roses.loc/.
I've created a search engine with a keyword of 'l' (my local TLD is .l). The URL for the search engine is http://%s.l. Then, I simply type "l mysite" in the address bar and it takes me to mysite.l.
Here is a workaround I came up with for this bug: http://code.google.com/p/chromium/issues/detail?id=30636#c38
I have Chromium installed on Linux Mint, and have a few localhost websites here. (I use Firefox for all of my work, so I have just discovered something here with Chromium.) My local sites are called morse and a.z. I had to enter http://morse/ and a.z/ respectively to get these sites to load the first time. They produced quick links on the new tab's otherwise blank page.
After closing Chromium, I reopened it and I could enter just morse/ and a.z to visit these sites. Since I've never seriously used this browser, I have not tailored any settings in it. (I did not use the quick link icons, but instead typed in the address bar.)
My findings confirm the localhost example.TLD/ entry does work when entered for the first time.
About Chromium: I am using Version 106.0.5249.119 (Official Build) for Linux Mint (64-bit).