Is this link valid?
eng
I know the browsers treat it as expected and I know the empty link would be ok too - but is it ok to specify just the parameters?
I am curious because question mark ("?") is only a convention by most HTTP servers (AFAIK), though I admit it is a prevailing one.
So, to recap:
will all browsers interpret this correctly?
is this in RFC?
can I expect some trouble using this?
UPDATE: the intended action on click is to redirect to the same page, but with different GET parameters ("lang=en" in above example).
Yes, it is.
You can find it in RFC 1808 - Relative Uniform Resource Locators:
Within an object with a well-defined base URL of
Base: <URL:http://a/b/c/d;p?q#f>
the relative URLs would be resolved as follows:
5.1. Normal Examples
?y = <URL:http://a/b/c/d;p?y>
RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax restates the same, and adds more details, including the grammar:
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty #; zero characters
Now, that is not to say all browsers implement it according to the standard, but it looks like this should be safe.
Yes - and it will hit the current url with parameters what you are passing.
It is very convenient to use in situations where you want to make sure you do not cross current page/form boundary and keep on hitting same ActionMethod or whatever is listening with different parameters.
Related
Say I have this header set on mywebsite.com:
Content-Security-Policy: script-src self https://*.example.com
I know it will allow https://foo.example.com and https://bar.example.com, but will it allow https://example.com alone?
Looking at the spec....
Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host or any of its subdomains (and any of its subdomains' subdomains, and so on))
...it seems as it should allow plain https://example.com. However, I've found several different sites (site 1, site 2, site 3, site 4) that all say that https://example.com isn't included. Which is it?
*.example.com for a CSP header doesn’t also match example.com, per the current CSP spec.
That text cited from the (old) CSP spec is wrong (now fixed). The other sources cited are right.
But that https://www.w3.org/TR/CSP/#source-expression section cited, which defines what a CSP source expression is, isn’t actually stating the relevant normative requirements.
Instead the section of the CSP spec that does actually normatively define the relevant requirements is the Does url match expression in origin with redirect count algorithm, in a substep at https://www.w3.org/TR/CSP/#ref-for-grammardef-host-part-2 which reads:
If the first character of expression’s host-part is an U+002A ASTERISK character (*):
Let remaining be the result of removing the leading "*" from expression.
If remaining (including the leading U+002E FULL STOP character (.)) is not an ASCII case-insensitive match for the rightmost
characters of url’s host, then return "Does Not Match".
The including the leading U+002E FULL STOP character (.) part of the requirement indicates the remaining part after the asterisk is removed includes the leading full stop, and so the rightmost characters of url’s host must also start with a dot in order to match that.
In other words, if you start with *.example.com and walk through that part of the algorithm, you start by removing the * to get .example.com as the remaining part, and then you match the rightmost characters of url's host against that, including the leading full stop.
So https://foo.example.com matches, because the rightmost characters of its host part match .example.com, but https://example.com doesn’t match, because the rightmost characters of its host part don’t match .example.com (because it lacks the included full stop).
2017-10-13 update
A while back I reported the problem with the CSP spec and it’s now been fixed.
The relevant part of the CSP spec now reads:
Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host’s subdomains (and any of its subdomains' subdomains, and so on))
Notice that the part which had read “matches any resource on the host or any of its subdomains” now just reads “matches any resource on the host’s subdomains”.
According to Mozilla's docs you should include 'self' as well as *.example.com in the CSP header if you want to include the base domain.
I can see that the Lighthouse CLI accepts a --blocked-url-patterns argument, but I can't find any definition of what constitutes a valid pattern, only that * is supported.
Is * literally the only supported pattern-ish character?
In this Google Lighthouse test file blockedUrlPatterns is an array of string with various patterns.
blockedUrlPatterns: ['http://*.evil.com', '.jpg', '.woff2'],
I realise this is coming in a little (two years) late, but for anyone else who wants to pass block patterns using the CLI you need to pass each pattern as its own param:
lighthouse https://example.com --blocked-url-patterns='http://*.evil.com' --blocked-url-patterns='*.jpg'
This will create the array required by Lighthouse - which you can see in the report produced if you search for blockedUrlPatterns
"blockedUrlPatterns":["http://*.evil.com","*.jpg"]
Is a URI written like Method 1 likely to cause problems on certain browsers vs Method 2? If so, on which ones? Can someone point to a source?
Method 1
test.dev/mypage?attributes[]=1&attributes[]=2&attributes[]=3
Method 2
test.dev/mypage?attributes%5B%5D=1&attributes%5B%5D=2&attributes%5B%5D=3
See the W3C's specification of URIs:
https://www.w3.org/Addressing/URL/uri-spec.html
None of those characters []=& are listed as reserved or unsafe, so either method should be fine.
I'm wondering where I can find a list of what every variable is in the Search Engine settings.
When you input a Search Engine into the settings, there are a number of variables attached, for example:
%s - The search query you're running
inputEncoding - The input encoding (i.e. UTF-8)
RLZ - ???
baseURL - ???
assistedQueryStats - ???
Google Chrome takes advantage of OpenSearch, "a collection of simple formats for the sharing of search results", as their specification for search query handling. The specification can be found here. But this only applies to any terms that are not prefixed with "google:". Because "google:" prefixed variables are subject to change, it is best to, at this time, reference directly to the source code of the URL management, which can be found here. The source code is also subject to change.
"google:" prefixed search variables can be found here.
All other search variables can be found here.
What is the "official" url I should use if I want to indicate just a resource that fails as soon as possible?
I don't want to use www.example.com since its an actual site that accepts and responds requests and I don't want something that takes forever and fails from a timeout (like typing using a random, private IP address can lead to).
I thought about writing an invalid address or just some random text but I figured it wouldn't look as nice and clear as "www.example.com" is.
If you want an invalid IP, trying using 0.0.0.0.
The first octet of an IP cannot be 0, so 0.0.0.0 to 0.255.255.255 will be invalid.
For more info, see this question: what is a good invalid IP address to use for unit tests?
https://www.rfc-editor.org/rfc/rfc5735:
192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses within this block do not legitimately appear on the public Internet and can be used without any coordination with IANA or an Internet registry. See[RFC1166].
Use .invalid, as per RFC 6761:
The domain "invalid." and any names falling within ".invalid." are special [...] Users MAY assume that queries for "invalid" names will always return NXDOMAIN responses.
So a request for https://foo.invalid/bar will always fail, assuming well-behaved DNS.
Related question: What is a guaranteed-unresolvable (but valid) URL?
if it's in a browser then about: is fairly useless - but it would be better if your service returned the correct HTTP status code - e.g. 200 = good, 404 = not found, etc.
http://en.wikipedia.org/wiki/List_of_HTTP_status_codes