I want to reserve a port for IISExpress 10 to serve a simple website to my LAN, but how do I properly use this?
add urlacl [url=]string
[[user=]string
{[[listen={yes|no}] [delegate={yes|no}]] | [sddl=]string}```
(I cut some of this ↓)
[url=] string
Specifies the fully qualified URL.
[listen={yes|no}]
Specifies one of the following values:
yes: Allows the user to register URLs. This is the default value.
no: Denies the user from registering URLs.
[delegate={yes|no}]
Specifies one of the following values:
yes: Allows the user to delegate URLs.
no: Denies the user from delegating URLs. This is the default value.
[sddl=] string
Specifies the SDDL string that describes the DACL.
So what do the url,listen,delegate, and sddl params do, and how do I use them?
Good examples are on Microsoft's site:
https://learn.microsoft.com/en-us/windows/win32/http/add-urlacl
You might get "Parameter is incorrect" which caused me some consternation.
Note that url must be a proper uri, http://+:8000 is not because its missing trailing slash, but http://+:8000/ is valid because of the trailing slash). Also http://+:8000/MyUri is valid
Related
Why does http:// contain two slashes—is that just a standard for a URL, or does it have any logical meaning? And why does file:/// contain three slashes, as in file:///C:/a.html?
The authority component of a URI has to be preceded by //:
The authority component is preceded by a double slash ("//") […]
This is also why not all URIs contain the double slash: because not all URIs have an authority component (e.g., URIs using the mailto scheme, the xmpp scheme, etc.).
If you wonder why the double slash instead of something else (or nothing) was chosen for (HTTP) URIs, see Tim Berners-Lee’s FAQ Why the //, #, etc? → What is the history of the //?
tl;dr: He copied the filename syntax which Apollo used.
By the way, he regrets that choice:
I have to say that now I regret that the syntax is so clumsy. I would like http://www.example.com/foo/bar/baz to be just written http:com/example/foo/bar/baz where the client would figure out that www.example.com existed and was the server to contact. But it is too late now.
As mentioned in this superuser post:
The complete syntax is file://host/path.
If the host is localhost, it can be omitted, resulting in
file:///path.
In other words, referring to files in your computer is just like referring to files in localhost.
I'm implementing a login system using OpenID.
The doc says :
Subject Identifier
An identifier for a set of attributes. It MUST be a URI. The subject identifier corresponds to the end-user identifier in the authentication portion of the messages. In other words, the subject of the identity attributes in the attribute exchange part of the message is the same as the end-user in the authentication part. The subject identifier is not included in the attribute exchange.
URI are quite larges in definition, it can be http://, but also gopher://.
I'm sure gopher is not a valid URI protocol, but then, excluding http(s), what else is allowed as a subject identifier from the OpenID protocol ?
You're quoting the wrong spec. The openid specification, section 7.2 says:
7.2. Normalization
The end user's input MUST be normalized into an Identifier, as follows:
If the user's input starts with the "xri://" prefix, it MUST be stripped off, so that XRIs are used in the canonical form.
If the first character of the resulting string is an XRI Global Context Symbol ("=", "#", "+", "$", "!") or "(", as defined in Section 2.2.1 of [XRI_Syntax_2.0], then the input SHOULD be treated as an XRI.
Otherwise, the input SHOULD be treated as an http URL; if it does not include a "http" or "https" scheme, the Identifier MUST be prefixed with the string "http://". If the URL contains a fragment part, it MUST be stripped off together with the fragment delimiter character "#". See Section 11.5.2 for more information.
URL Identifiers MUST then be further normalized by both following redirects when retrieving their content and finally applying the rules in Section 6 of [RFC3986] to the final destination URL. This final URL MUST be noted by the Relying Party as the Claimed Identifier and be used when requesting authentication.
From the third point we can infer that the identifier must be either a http(s) URL or an XRI.
In order to maintain the current set of Urls in a project, I have to be able to use the # (pound sign) in the Url. For some reason the pound sign does not appear to work normally in this project for UrlMappings.groovy.
Is there a special escape-sequence that must be used when placing # signs in UrlMappings.groovy?
Am I missing some reason why one cannot use pound signs at all?
In the following URL Mapping example, the browser goes to the correct page, but the pageName variable is null:
"/test/${urlName}#/overview"(controller:'test', action:'overview') {
pageName = "overview"
}
I thought everything after # in the url would be treated on the client side of the browsers where it tries to find a and scroll to that location.
If you dump the request containing the pound char, do you even see the data behind #?
I used a Named URL mapping and it works fine, no need to escape the "#" sign:
name test: "/#abc" (controller: 'test', action:'homepage')
EDIT: My above answer is wrong. In fact, it falls to a special case when homepage is the default action of the view.
Netbrain is right, the path after "#" will never be sent to server. In stead, I found that it's possible using "%23" instead of "#". Please take a look at here.
For example, instead of /test#/abc we should use /test%23/abc as URL mapping (both at client side & server side).
I was recently asked to add some Woopra JavaScript to a website and noticed that the URL started with a double slash (i.e. omitted the scheme). I've never seen this before, so I went trying to find out more about it, but the only thing I could really find was an item on the Woopra FAQ:
The Woopra JavaScript in the Setup does not include http in the URL call for the script. This is correct. The JavaScript has been optimized to run very fast and efficiently on your site.
However, some validation and site testing/debugging services and tools do not recognize the code as correct. It is correct and valid. If the warnings annoy you, just add the http to the script’s URL. It will not impact the script.
(For clarification, the URL is "//static.woopra.com/js/woopra.v2.js"—the colon is omitted in addition to the "http".)
Is there any more information about this practice? If this is indeed valid, there must be a spec that talks about it, and I'd very much like to see it.
Thanks in advance for satisfying my curiousity!
This is a valid URL. It's called a "network-path reference" as defined in RFC 3986. When you don't specify a scheme/protocol, it will fall back to the current scheme. So if you are viewing a page via https:// all network path references will also use https.
For an example, here's a link to the RFC 3986 document again but with a network path reference. If you were viewing this page over https (although it looks like you can't use https with StackOverflow) the link will reflect your current URI scheme, unlike the first link.
See RFC 3986, section 3:
The generic URI syntax consists of a
hierarchical sequence of components
referred to as the scheme, authority,
path, query, and fragment.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment
]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The scheme and path components are
required, though the path may be
empty (no characters).
I use bit.ly to shorten my urls.
My problem - paramters are not passed.
Let me explain I use http://bit.ly/MYiPhoneApps which redirects (let's say) to http://iphone.pp-p.net/default.aspx
Now when I try http://bit.ly/MYiPhoneApps?param=xx this param is not added to the resulting url.
I know I could create an extra "short url" including a paramter - so http://bit.ly/WithParam would result in http://www.mysite.com/somepath/apage.aspx?Par1=yy and so forth.
But what I want is to have a short URL directing to a page - and then I want to add a parameter to this shortened url - which shoul (of course) land at my page.
Is this a shortcome of bit.ly (and others are maybe able to do it) - or does "parameter forwarding" not work with 301 redirections?
Manfred
There's no technical reason why it couldn't be done. The service would simply have to look at what parameters it is being sent, and then rewrite the target URL accordingly.
The problem is that it's not necessarily well defined how to do that.
Suppose you have the url http://example.com/default.aspx?foo=bar, and it has the short url http://foo.com/ABCD. What should happen if you try to access http://foo.com/ABCD?foo=baz? Should it replace the value, so you get foo=baz? Should it append it to make foo=bar&foo=baz? If we include both, which order should they be in?
The system cannot know which parameters are safe to override and which are not, because sometimes, you DO want both of them in the URL, and it may matter what order things are added in.
You could argue "Well, just don't allow this for URLs where parameters are already present", but there's also the issue that it's going to complicate the process a lot more. Without this, you just lookup a key in a database and send a redirect header. Now, you need to also analyze the URL to check for parameters, and append part of the URL you were called by. That requires more system resources per redirect, which may become a big problem if your service is used very frequently - you'll need more server power to handle the same amount of redirects. I don't think that tradeoff is considered to be "worth it".
As mentioned in comments by rinogo and Jurgen
In Clickmeter
Destination URL : www.yoursite.com?myparam1={id1}&myparam2={id2}
Tracking link : www.go.clickmeter.com/38w2?id1=123&id2=abc
After click : www.yoursite.com?myparam1=123&myparam2=abc
In TinyUrl
Destination URL : http://x.com?a=1
Shorten URL : https://tiny url.com/y6gh7ovk
Shorten URL + param : https://tiny url.com/y6gh7ovk?a=2
Resultant URL : http://x.com/?a=1&a=2
Added space to post tinyurl
URL shortening associates a unique key based on a full URL (parameters and all), so it is not possible to pass parameters to a shortening service.
Typically
http://iphone.pp-p.net/default.aspx?param=10
must produce a different key to
http://iphone.pp-p.net/default.aspx?param=22
'Parameter forwarding' is simply not possible in these kinds of redirects, as parameters are not valid parts of a shortened URL is most (if not all) services.