I am implementing an app using vue (my first one =) ). vite is my development environment tool. The problem is;
resources are mapped with relative paths; "./
If I load the app via /, here no problem.
If I try to load the app via /app then the resources asked from the root path again and expectedly the proxy does not forward the requests to server and expectedly a resource loading failure.
I would like to make my app load resource relatively. since these are two different parts in the network, I do not want to map all assets depending on my proxy's routing config.
Related
I'm new to Next.js and am trying to get my head around client side and server side routing and what files need to be made available to download when Next.js is configured to use server-side rendering.
When I do a production build of a Next.js project, a .next directory is created (details here). When I call next start and then load a page that uses SSR (by defining getServerSideProps()) then I can see in the developer console that the page that I load downloads resources that are prefixed _next (e.g. <script src="/_next/static/chunks/main-3123a443c688934f.js" defer=""></script>).
Can someone confirm whether the .next directory contents (.next/server/**, .next/static/**) are just made available on the server by being renamed to _next?
I tried creating a new page in a file called _next.js as an experiment. The project builds correctly (no errors reported and there are build artifacts created with the same naming convention as the other pages). However, when I try to load that page, I get a 404.
Are there restrictions on what constitutes a validly named page in Next.js? If so, what are they and where is this defined.
How does the Next.js server know what is a static resource that should just be given to the client and what is a page for which Next.js should render an output? Is it simply an algorithm like "if the path starts _next/ then return what is requested, otherwise render?"
How does Next.js know to distinguish between resources that are in the public directory and pages? e.g. if there's a collision between the name of a page and a resource in the public folder, how does the server know what to return to the user?
This question is related to this SO question, but the recommended solution in the comments to use Meteor.absoluteUrl() doesn't seem to be working as expected. I want to be able to deploy multiple meteor applications to the same server and use nginx as a reverse proxy to each application.
Because each application is segregated none of the applications are going to be accessible from the ROOT_URL, but Meteor is only using the ROOT_URL to reference back for the assets it needs to load a meteor app.
I tried appending to the address using Meteor.absoluteUrl() in the server's startup, the client's startup function, and outside of the client's startup function. It had no affect in any of these places.
For example. I have nginx listening at /site1 for server_name: example.com and a reverse proxy to port 3001 to my meteor application.
When going to the site it initially loads fine but the browser dev tool shows Meteor is trying to find the javascript and css files at https://example.com when it should be looking from a base url of https://example.com/site1
Meteor.absoluteUrl("site1",{ssl:true}) was set in Meteor.startup() to try and force that as the correct path. As you can see, I am only appending to ROOT_URL with no leading / as described in the Meteor documentation.
I'm using meteor up to deploy and here's how the mup.json environment settings look:
"env": {
"ROOT_URL": "https://example.com",
"PORT": 3001,
"MONGO_URL": "mongodb://user:password#localhost:27017/db"
}
Any clarification about this this should work is greatly appreciated.
Using sub-domains suggested by apendua seems to be the easiest way to accommodate multiple Meteor applications on the same server behind nginx (if you that option available to you).
Register a sub-domain for each application (i.e. app1.domain.com, app2.domain.com, etc.)
Add an nginx server configuration for each sub-domain, setting the server_name property to your sub-domain address.
Add a default location for that server and set your proxy_pass to http://127.0.0.1:port where port is the port number you set in your environment configuration when you deployed your Meteor application (in my case I set this in my mup.json).
The root url for public assets under a meteor app is actually at /public. Each of your apps has a different base directory for the app. Assuming that you have an overall structure that looks like:
app1/ - nginx maps to https://example1.com/
client/
lib/
public/
server/
app2/ - nginx maps to https://example2.com/
client/
lib/
public/
server/
etc...
Then each app's public assets will just be under Meteor.absoluteUrl() which will serve files from app/public. Meteor.absoluteUrl()+"app1" has no meaning.
I have inherited an .NET app that is hosted on IIS. Previously it would have been its own site within IIS. Now in my Dev environment I have to run it under Default WebSite (in Production it will still run as its own site.
So in Dev I was having problems loading scripts and css files - so I right click Default Web Site in Dev and Add Application - call the new App - MyApp and point to the physical location on disk.
So previously style sheets would have been loaded:
href="/css/folder/mystylesheet.css"
and js files:
src="/jslib/jquery-1.9.1.js"
which worked fine when the application is hosted as its own site within IIS and which still needs to happen in Production (just not in my dev) So in dev I need to change the css and js as below:
href="~/css/folder/mystylesheet.css" (note ~ added)
src="./jslib/jquery-1.9.1.js" (note . added)
and now the js and css files for MyApp under Default website are loaded. However is there something simple I can do in IIS or webconfig to switch this behaviour on/off easily in Dev/Production rather than editing all the places where scripts and css files are loaded - as I know at some point a file will get checked into Production with the path incorrect
The other problem is there is numerous links throughout the site that are all relative so were /Link/Page.aspx which now break in MyApp hosted under Default Website
EDIT
Looking at the answer below from this question
In ASP.NET, many times you will need to use a tilde (~) to get the application's root directory, so your paths would look like ~/stylesheets/main.css
When you specify a path that starts with / you are indicating the server root so if you have you site in a virtual directory, it will not be taken into account, but if the site is hosted as the default site, the path will qualify:
Example: server named foo.net with site hosted in a virtual directory named app /stylesheet will translate to foo.net/stylesheet not foo.net/app/stylesheet
All my paths start with / (i.e going to server root) - what I need to figure out is there something I could add to web.config that for Dev would let me specify The Virtual Application MyApp needs to be taken into account (just for Dev - this could then be removed in Web Transform for Production web.config file
The short answer is no, there is not one single place where you can deal with the site's location. That's because there are many possible outcomes that you might want, including:
site served from IIS root folder and accessed at root of domain (or not)
site served from IIS subfolder and accessed at same path (or not)
IIS rewrite rules (inbound and outbound), which adds layers of mapping between public and private paths
sites mapping to subdomains, DNS wildcard mapping (where requests are distinguished by hostname), etc
sites mapping to child applications, inheriting or not inheriting rewrite rules (and other configuration)
all of the above
At the same time, there are many places where you interface with paths:
internal physical paths, usually for disk access, and usually requiring mapping of virtual path
internal virtual paths
internal ASP.NET paths, like virtual paths except that they can be app-relative (using ~), which IIS doesn't always recognize
public-facing paths
all of the above can be relative or absolute
So yeah, it's a mess.
For your case, the simplest thing is probably to make the development environment mirror the production environment. Unless you're moving the live site, delegating all the path references to a configuration-aware function is probably more trouble than it's worth.
The ~ is added to make the path relative to root directory. One suggestion is to move the folder up a few levels.or down a few levels to make sure your project is in the correct directory. Hope this works
Existing ASP.NET (MVC and webforms hybrid) website displays translated content. The language is based on a cookie that stores the user's preference. There is no change in the URL when the user changes the setting. The content is reloaded in the preferred language. For SEO, the locale should be included in the URL ( support.google.com/webmasters/answer/182192?hl=en).
I've tried the following:
1) Use URL Rewrite Module: (http://www.iis.net/learn/extensions/url-rewrite-module/setting-http-request-headers-and-iis-server-variables)
Issues:
- All hyperlinks and redirects still point to the old URL without the locale.
- Complex outbound rules required based on the folder structure and usage (mixture of absolute paths and relative paths e.g. ../, ~/, /).
- Also need to disable static compression as per documentation
- Performance considerations due to large size of Html.
- Postback results in runtime exceptions due to issue in the relative path rewrite.
- Paths defined in script files (ajax loading etc) are a huge challenge
- Base tag does not work as expected, because the Rewrite Module seems to append ../ (http://www.iis.net/learn/extensions/url-rewrite-module/url-rewriting-for-aspnet-web-forms#Using_tilda)
2) IIS 7.5 Virtual Directory: Create Virtual Directory for each language and point it to the root. i.e. www.example.com is the root and www.example.com/fr-ca/ is a virtual directory mapped back to the root
Issues:
- Runtime exception in config file saying that the virtual directory needs to be converted to application
- Converting it to application gives 500.19 error due to duplicate entries in the web config (since the virtual directory is pointing back to the root)
- I tried moving the root to another subdirectory (i.e. have a physical directory for each language) to avoid web config conflicts, but that is resulting in some sort of "kernel" error. Also, this would mean changing the physical structure of the application, and also address routing issues
3) Using sub-domains:
I have also considered using sub-domains and hosting the application independently for each language, but this has a lot of drawbacks, including having to address scalability, single sign on, cookies, domain specific stuff like analytics etc.
So what is the least painful way to include a language sub-directory in the URL, and make all links relative to that sub-directory?
Note: The site contains a mixture of absolute paths and relative paths e.g. (../, ~/, /) sometimes used in conjunction with ResolveClientUrl, ResolveUrl
In the end, we went with option 2, with the below steps:
Create a new folder, deploy a copy of the application to the new folder. The new folder should be in a different directory from the root application.
Create a new virtual application* (not virtual directory) under the root application; 1 for each new language, pointing to the new folder. (If the need arises in the future, any of the virtual applications can point a different folder customized for that specific language)
In the new folder, remove the modules and handlers sections in the system.webServer section of the web.config file (they will be inherited from the parent web.config)
If you are using SQL session state, you will need to specify a custom Application Name in the web.config, and modify TempGetAppID stored procedure so that the Application Name is the same across all the virtual applications. See the following (http://blogs.msdn.com/b/toddca/archive/2007/01/25/sharing-asp-net-session-state-across-applications.aspx)
Hopefully, all the links are resolved on the server side using Url.Content (MVC) or ResolveUrl (webforms). If not, they need to be fixed. Any paths specified in javascript would not automatically resolve to the virtual application either (they would still be resolved to root application)
Test the heck out of it. Each and every link. (A tool like ScreamingFrog may help to make sure that no 404s are returned, methinks. But it wouldn't solve HTTP POST)
Note that depending on custom error handling, and any existing URL rewrite rules, the steps maybe different.
Summary: option 1 (URL Rewrite) is totally impractical. Option 2 (sub-directory) is the most practical solution, however it is not quite as straightforward as it should've been.
My problem: I have a program in Flex3 that accesses a server. The program itself is on a server and accessed through a web browser. The point is that I don't want to hardcode in the swf file the IP of the server to access, since it changes and for various other reasons...
How can I do that? Can I put a file in the same directory and what then?
To access a config file on the same server as the SWF, you should be able to use an HTTPService or URLLoader with a relative URL rather than absolute. You can get fancier (changing ports) by accessing the url field of your base Application and creating a new absolute URL from that.
If the SWF is hosted separately from the HTML, you can use BrowserManager url to build your config url instead.
See this article: Externalizing Service Configuration using BlazeDS and LCDS
It will also work for HTTPService with some minor modifications.