Does making an image like
<img src="/images/thing.png"/>
just go through the physical directory of the local server, or does it do the equivalent of making a request to itself like
<img src="http://thesite.com/images/thing.png"/>
???
No.
A relative url is a simple way of writing an url (relative to the current url of the current document).
At the end your browser has an url, and has to run an HTTP request (if the protocol of this url is http) to retrieve the targeted document.
Note that the server is doing nothing, all the job is made by your browser (which rebuild the absolute url from the realtive url format -- with a starting / or not-- and the current document url).
So talking about 'browsing itself' makes no sense, the server can present a lot of different urls, some targeting other servers, some targeting the same server. At the end the browser reads the url and sends a request (and a relative url will quite certainly reach the same server but that's not even sure, several physical servers could be used to manage the same domain, some other actors between your browser and the final server may decide that for that url another system has to be contacted).
Related
I am new in web development / SEO and stucked so hard on next moment:
We got sitemap file for helping SE robots index our pages correctly.
Sitemap could contain only URLs from current sitemap directory. For example: http://www.example.com/sitemap.xml can contain only links, whose exist in same catalog. But how data transfer protocols (http/https) relate to my finite directory, if it is just a way for transfer data? I have not two different folders with sources on my web server for http and https, lol. And indexing should not changing with protocol changes in URL. Same question i got for www subdomen. I know what a problem in my missunderstanding in web basics xD
Clients (such as search engine indexing bots and browsers) make HTTP requests to servers, which provide a response.
A URL is how a specific resource is located. It will specify the scheme/protocol, hostname, and path (and optionally a few other things).
A URL might specify HTTP or HTTPS (the latter adding an encryption layer).
The hostname portion of a URL might include www in the name or it might not.
When the server receives the request it will run some code to determine how to respond to it. A common and simple approach for that code is to match the path portion of the URL to part of the directory structure of the file system of the computer running the HTTP server software. It may, or may not, use different directories as the root for this depending on the hostname and protocol.
This means that you might have an HTTP server providing both HTTP and HTTPS and mapping www.example.com and example.com onto the same directory resulting in (at least) four different URLs all mapping onto any given file.
Best practise is to pick one of those as the canonical URL (with preference given to HTTPS and various arguments for with or without the www (which mostly revolve around convenience and how cookies for the primary hostname will be handled on other subdomains).
When writing absolute URLs (e.g. in sitemaps, emails and business cards), use the canonical URL.
It is generally recommended that the server be configured to issue 301 Redirects from the non-canonical URLs to the canonical equivalent.
Essentially what my use case is, a 3rd party server only support POST on a specific integration url. but I want a browser to hit it from a normal html link (I have no control over either systems code, I can only configure the destination url for the link)
To solve or this I have written a web hosted app (done in Mirth Connect - but the server tech in theory shouldn't matter). The objective of my app is to cat the GET and convert it to a POST
My systems logic:
My web server receives an HTTP GET from a browser, grabs the query strings.
The server then performs an HTTP POST on a 3rd party server, and grabs the html result
The server then returns the original html and delivers it as the result to the original http request from the browser
This works great, the issue comes in with content hosted on the 3rd party server that is referenced with a relative path (css, js, images, etc).
Because I have "tricked" the browser into thinking it received the html from my system, it looks on my server for the content (which will all 404).
Without having to handle the fetching of all the content myself, is there a way to tell a browser to redirect all further queries to the 3rd party server?
I tried making my HTTP GET return a status 301 or 302 with the location being the base address of the 3rd party server, but this obviously tells the browser to redirect completely
Figured it out.
I just had to intercept the html and inject a BASE tag .
I served a react page under 127.0.0.1/react/ sub directary with my gateway. It can be viewed by explorer with 127.0.0.1/react/. But if I input 127.0.0.1/react it returns my vue page served under 127.0.0.1 which failed to match any routes.
There is another example https://www.curseforge.com/minecraft/mc-mods.
https://www.curseforge.com/minecraft/mc-mods is okay while https://www.curseforge.com/minecraft/mc-mods/ returns 404 not found. What's the difference?
Ordinary users might treat them as same url, they would expect both of them can access the page. So how should I make them both accessable?
The server can return whatever it wants for any path, and doesn't need to follow any particular standard conventions. However, most servers do follow some norms:
/react/ usually ends up fetching the index file (usually index.html unless configured otherwise) from the react folder under the web root. This is returned to the client transparent... the client isn't redirected.
/react This is a request for a file named react under the main root. However, in the absence of such file, and the presence of a folder, it's common to redirect the client to /react/.
How you do this depends entirely on your server configuration. You didn't tell us the server, so we can't point you in the right direction.
Let's say you have a resource, could be an image, could be jQuery from a cdn. This resource is hosted at some 3rd party url, like https://example-cdn.com/resource.ext. Let's also assume it is cacheable (whatever that means--let me know if that is a non-trivial detail).
When https://website-a.com requests the resource (let's assume it was included in the html directly), it takes some time to load, but then the browser caches it for faster load next time.
Now, https://website-b.com is also including that resource in its html, using the exact same url (https://example-cdn.com/resource.ext).
My question is this: will the browser reach for the cached resource (because it was already fetched while loading https://website-a.com), or is there some reason that it would not be able to find it in the cache and have to load it over the network all over again?
Edit: This stackexchange answer seems to contain some related information. Can anyone verify that this answer is correct in all its assertions about caching? https://webmasters.stackexchange.com/a/84685
Yes, the resource will be cached.
This follows from the semantics of HTTP and URLs. A URL is a Universal Resource Location: it provides the location of the resource, in a form that can be used anywhere, and which always indicates the same resource: in <a> elements of different web sites, on business cards, on advertising posters. An HTTP client (a web browser) knows that a URL one web site has refers to the same resource if used on a different web site, and so it is safe to reuse a cached copy.
The exception to this is when a URL is a relative URL (your example uses absolute URLs). To make use of a relative URL the client must resolve the URL, using some context, to produce an absolute URL. Different web sites have different contexts and thus resolve to different absolute URLs. It is the absolute URL that the client must use to fetch resources and which is used as the key in its cache.
Not 100% sure if this is the right SE site to ask this, so feel free to move/warn me.
If I have a site www.mysite.com with a form on it and define its action as "http://www.mysite.com/handlepost" instead of "/handlepost", does it still get parsed as a local address by apache? That is, will apache figure out that I'm trying to send my form data to the same server the form resides on and do an automatic local post, or will the data be forced to make a round trip, going online, looking up the domain and actually being sent as an outside request?
Apache does not look at this information. It's your browser which does this job.
On the Apache side the job is only outputing content (html in this case), apache does not care about the way you write your url in this content.
On the browser side the page is analysed and GET requests (images,etc) are sent automatically to all collected url. The browser SHOULD know that relative url /foo are in fact http://currentsite/foo - or it's a really dump browser -. It is his job. And then it's his job to push the request to the right server (and to known if he should make a new DNS request, build a new HTTP connection, reuse an existing opened connection, build several connections -- usually max 3 conn per DNS--, etc). Apache does nothing in this part of the job.
So why absolute url are bad? Not because of the job the browser should have to do handling it (which is in fact nothing, his job is transforming relative url to absolute ones); It's because if your web application use only relative url the admin of the web server will have far more possibilities on proxying your application. For example:
he will be able to server your web application on several different DNS domains
(and then make the browser think he's talking to several servers, parallelizing static files downloads)
he could as use use this multi-domain to set up the application for different costumers
he could build an HTTPS access for external network access and an HTTP (without the S) access on a local name for the local network
And if your application is building the absolute url these tasks will become really harder.
dont use absolute URL's . As i feel it will do a round trip in your case as you have used round trip for the action part. so better use releative URL's