I am trying to create a path in a GKE ingress like this: /organizations/''/entity/''/download.
NOTE: The '' above represents a wildcard (*)
The values after organizations/ and after entity/ are dynamic so I have to use two wildcards, but this is not working, the first wildcard after the /organizations/* is taking all the requests.
I want to apply a different timeout only on this specific request, therefore I need to configure it just like this, if there is /test instead of /download at the end, it shouldn't take place.
I can't be the only one to have the same situation, and I am struggling to find anything on internet with the same issue?
Any workaround?
The only supported wildcard character for the path field of an Ingress is the * character. The * character must follow a forward slash (/) and must be the last character in the pattern. For example, /, /foo/, and /foo/bar/* are valid patterns, but , /foo/bar, and /foo/*/bar are not.
Source (From GKE Ingress docs): https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#multiple_backend_services
Related
Over here, I couldn't understand why third example was a no match. If my wildcard is *.foo.com then why it can't match match Host header with value as "foo.com".
I tried to Google for "single DNS label" but really couldn't understand.
Basically, *.foo.com means you need to have <something>.foo.com. So, only foo.com is not matched. For simplicity you can think that wildcard * need to be replaced and cannot be omitted, you have to have something in the place of * for matching this.
Is there any documentation on the limitations on zookeeper node names? I can't find anything in official documentation regarding it. In particular, I want to know:
What characters are allowed?
Can I use any character from UTF-8 (like japanese characters)?
What is the maximum limit of characters/bytes (if any) for node name?
For 1, 2: Any unicode character can be used in a path subject to the following constraints:
The null character (\u0000) cannot be part of a path name. (This causes problems with the C binding.)
The following characters can't be used because they don't display well, or render in confusing ways: \u0001 - \u001F and \u007F - \u009F.
The following characters are not allowed: \ud800 - uF8FF, \uFFF0 - uFFFF.
The . character can be used as part of another name, but . and .. cannot alone be used to indicate a node along a path, because ZooKeeper doesn't use relative paths. The following would be invalid: /a/b/./c or /a/b/../c.
The token zookeeper is reserved.
PS: The source code: PathUtils.validatePath()
For 3: In fact, there is no limit on the length of name in ZK itself, but is is recommended not using too large name (e.g., ZK store entire data in memory for efficiency)
I am using Exchange Server 2013 and have many transport rules set up to filter out emails from most countries outside of the US.
We recently received an email from a military email, ending in .mil
The email was blocked by my transport rules but does not match any of the extensions I have listed. Except for possibly one! I have an extension to block '.il$'. So this should block ALL emails that end with ".il". However, if the transport rules use true regular expression rules, the "." would be a wildchar and match any and every character including a "." itself. Is this the cause of my issue? I do not have a .mil email account to test with or I could check myself. I have added a character escape to my transport rule, making it '\.il$' hoping that it will fix this.
I read everything I can find about the regex rules for Exchange's Transport Rules, and I cannot find anything that mentions you must escape the dot. Maybe this is just a rare issue and they didn't foresee it occurring?
One of the documents I have read: https://technet.microsoft.com/en-us/library/aa997187(v=exchg.141).aspx
Long story short: YES, the dot(.) must be escaped with a \. Otherwise it is a single wildchar that matches any character [A-Z a-z 0-9 . , /] etc. just like in regular expression. I assume that Microsoft is using every rule from regular expression for the transport rules but do not quote me on that.
This cannot be found in any documentation that I have researched, it also seems that every example that I have looked at on the web has been doing it wrong as well. Examples that I see are always ".com$" will block all emails from a sender ending in .com. This is true because the dot can also be a dot. But this will also block any emails that end in "ecom" for example, which may be an issue if they ever decide to release such extension.
Sorry for answering my own question, but I want this to be here for future reference since it can't seem to be found anywhere else.
What patterns are valid in kubernetes for the names of containers and ports?
I had underscores in the names of ports and containers and got an error. Replacing the underscores with hyphens worked.
Container names and port names must conform to the RFC 1123 definition of a DNS label.
Names must be no longer than 63 characters, must start and end with a lowercase letter or number, and may contain lowercase letters, numbers, and hyphens.
Expressed as a regular expression:
[a-z0-9]([-a-z0-9]*[a-z0-9])?
Here's the applicable code in GitHub for checking container names, checking port names, and defining acceptable names.
Just to have a quick reference this answer isn't valid for the port.name validation and why errors are popping up with longer than 15 char names the latest k8s specs: The container[0].port[0].name must be 15 characters or less as seen by the latest port.name validation code.
I have a regular express. It work to port name.
Expressed as a regular expression:
^(?!^[0-9]*$)^([a-z0-9]([a-z0-9]|-(?!-)){0,14}(?<!-)$)
How do Wikipedia (or MediaWiki in general) encode page titles in URIs? It's not normal URI encoding, since spaces are replaced with underscores and double quotes are not encoded and things like that.
http://en.wikipedia.org/wiki/Wikipedia:Naming_conventions_%28technical_restrictions%29 - here you've got some kind of description of what their engine enforces on article names.
They should have something like this in their LocalSettings.php:
$wgArticlePath = '/wiki/$1';
and proper server URI rewrites configuration - they seem to be using Apache (HTTP header), so it's probably mod_rewrite. http://www.mediawiki.org/wiki/Manual:Short_URL
You can also refer to the index.php file for an article on Wikipedia like this: http://en.wikipedia.org/w/index.php?title=Foo%20bar and get redirected by the engine to http://en.wikipedia.org/wiki/Foo_bar. Behind the scenes mod_rewrite translates it into /index.php?title=Foo_bar. For the MediaWiki engine it's the same as if you visited http://en.wikipedia.org/w/index.php?title=Foo_bar - this page doesn't redirect you.
The process is quite complex and isn't exactly pretty. You need to look at the Title class found in includes/Title.php. You should start with the newFromText method, but the bulk of the logic is in the secureAndSplit method.
Note that (as ever with MediaWiki) the code is not decoupled in the slightest. If you want to replicate it, you'll need to extract the logic rather than simply re-using the class.
The logic looks something like this:
Decode character references (e.g. é)
Convert spaces to underscores
Check whether the title is a reference to a namespace or interwiki
Remove hash fragments (e.g. Apple#Name
Remove forbidden characters
Forbid subdirectory links (e.g. ../directory/page)
Forbid triple tilde sequences (~~~) (for some reason)
Limit the size to 255 bytes
Capitalise the first letter
Furthermore, I believe I'm right in saying that quotation marks don't need to be encoded by the original user -- browsers can handle them transparently.
I hope that helps!