What are the differences between these two prefixes in terms of HttpListener or any other?
http://+:8080/
http://*:8080/
http://*:8080/: Receive all HTTP requests on port 8080 that are not already being handled by some other HttpListener.
http://+:8080/: Receive all HTTP requests on port 8080 even if they're already handled by another HttpListener.
In addition to #Paulpro's great answer, the link posted by #rownage (see this answer) provides some more information about the difference:
Strong wildcard (Plus Sign +)
When the host element of a UrlPrefix consists of a single plus sign
(+), the UrlPrefix matches all possible host names in the context of
its scheme, port and relativeURI elements, and falls into the strong
wildcard category.
A strong wildcard is useful when an application needs to serve
requests addressed to one or more relativeURIs, regardless of how
those requests arrive on the machine or what site they specify in
their Host headers. Use of a strong wildcard in this situation avoids
the need to specify an exhaustive list of host and/or IP-addresses.
Weak wildcard (Asterisk *)
When an asterisk (*) appears as the host
element, then the UrlPrefix falls into the weak wildcard category.
This kind of UrlPrefix matches any host name associated with the
specified scheme, port and relativeURI that has not already been
matched by a strong-wildcard, explicit, or IP-bound weak-wildcard
UrlPrefix.
This host specification can be used as a default catch-all in some
circumstances, or can be used to specify a large section of URL
namespace without having to use many UrlPrefixes.
Related
I'm currently configuring an Artemis ActiveMQ Broker and need to change the default ''wildcard-addresses''. So I found the ''wildcard-addresses'' tag, but I didn't find the information I need, so I have two questions:
I want to set routing-enabled to true, but just for the tag ''any-words'' and disable the ''single-word'' tag (or just want to know if this is even possible).
I didn't find the answer in the official documentation, so I'm wondering if someone found a good reference which explains the different tags for the ''wildcard-addresses'' configuration, which is in the style of the ''Configuration Reference'', but includes a section about ''wildcard-addresses''.
What I've found so far but does not satisfy me:
Wildcard-syntax
Routing Messages with wildcards
Configuration reference
Thanks in advance,
Alex
There is no way to disable certain match types (i.e. single word or any words), and it's not clear why one would want to.
The wildcard-addresses block is for enabling/disabling wild-card routing and for customizing the wild-card syntax.
Here's the basics (as described in the documentation):
A wildcard expression contains words delimited by the character defined by delimiter (i.e. . by default).
The character defined by any-words (i.e. # by default) means "match any sequence of zero or more words."
The character defined by single-word (i.e. * by default) means "match a single word."
When we make a SNMPv3 connection, following are the parameters mainly.
SNMPV3UserName
SNMPV3ContextName
SNMPV3SecurityLevel
SNMPV3AuthProtocol
SNMPV3AuthPassword
SNMPV3PrivacyControl
SNMPV3PrivacyPassword
I want to understand, if is it necessary to specify "SNMPV3ContextName" when connecting. I SNMP RFC Doc and other links I did not find any clear mention.
I have one application which asks for context name if not input by user. I doubt that it should not ask for Context name input as it seems like optional parameter.
RFC I reffered : https://www.rfc-editor.org/rfc/rfc5343
tl;dr: Probably not.
RFC 5343 says:
The contextName is a character string (following the SnmpAdminString textual convention of the SNMP-FRAMEWORK-MIB [RFC3411])
and RFC 3411 defines SnmpAdminString as an OCTET STRING (SIZE (0..255)).
So, it can be empty. I can't find anything to constrain this more, so an empty string is permitted. Per these RFCs (and also RFC 3412) it seems to be a way to add multiple contexts on top of the contextEngineID, if your engine needs this disambiguating functionality (to treat it as multiple engines, in a sense).
However, as with anything SNMP, some implementations may impose their own constraints, or just flat-out not follow the spec properly. So you should consult the documentation for the technology that you're using.
Some of web api endpoints have strings as input parameters and some times I have to pass special characters like /,\,( and ). But, it is not allowing special characters because those has special functionalities. Is there any way solve this problem.
Is there any way solve this problem.
No.
(Please) Stop Using Unsafe Characters in URLs. URLs are by definition machine readable. There are rules to follow about what can and cannot be part of a URL.
Although technically using unsafe characters is supposed to be possible through encoding, all bets are off that all browsers, web servers, and firewalls will treat them as "plain text" when encoded instead of assigning them special meaning. Some may just reject the URL entirely, considering it SPAM or attempted hacking.
I have a page where a user can add an IP address to a whitelist, whose format is verified if it is a valid IP.
I'd like to add functionality so that regex's can also be input. I would like to verify that the regex matches a valid IP address (ie. the regex entered by the user is a subset of the regex that is specified in the code).
IP_Regex: ^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$
Example: A user must input a string matching the specifications of IP_Regex (such as 10.111.111.111) or a subset of it (such as 12(?>\.\d{1,3}){3})
I'm not sure how to go about this. Most posts seem to just cite math theory but don't mention how to go about this when programming.
I don't think it is dangerous to allow your users to input regexes, so you don't have to be 100% accurate.
Therefore I would randomly generate some slightly invalid ips and make sure the regexes fail on those.
I am looking to match all email addresses from a specific domain.
Any email coming from example.com or foo.example.com should match, everything else should be rejected. To do this, I could do some basic string matching to check if the given string ends with, or contains, example.com which would work fine but it also means that something like fooexample.com will pass.
Hence, based on the above requirements, I started working on a pattern that would pass the domain and its sub-domain. I was able to come up with the following regex pattern:
`/\b[A-Z0-9._%+-]+#[A-Z0-9.-]+\.example.com\b/i`
This only matched subdomains, but I have seen the pattern at "How to match all email addresses at a specific domain using regex?" which handles the main domain.
Is there a way to combine these two into something that works for any address from example.com.
How about
/\b(?:(?![_.-])(?!.*[_.-]{2})[a-z0-9_.-]+(?<![_.-]))#(?:(?!-)(?!.*--)[a-z0-9-]+(?<!-)\.)*example\.com\b/i
This one would also match 'tagged' and 'tagged-subdomain' mails like a+b#example.com and a+b#i.example.com
(([A-Za-z0-9]+_+)|([A-Za-z0-9]+\-+)|([A-Za-z0-9]+\.+)|([A-Za-z0-9]+\++))*[A-Za-z0-9]+#(?:(?!-)(?!.*--)[a-z0-9-]+(?<!-)\.)*example\.com\b
Hope it helps you
I'd recommend reading "Stop Validating Email Addresses With Your Complex Regex".
From that point, I'd look for:
/#.*\bexample\.com/
For instance:
%w[foo#example.com foo#barexample.com foo#subdomain.example.com].grep(/#.*\bexample\.com/)
=> ["foo#example.com", "foo#subdomain.example.com"]
It's too easy to end up with a regex that is a maintenance nightmare, and that doesn't accomplish what you need. I highly recommend keeping it simple.