I see there is way i can get a specific custom section with given name.
var nameSections = WebAssembly.Module.customSections(module, "sec_name");
Is there any way I can get all the custom sections in a given WebAssembly module?
The JavaScript interface at this time does not offer that. The customSection function was discussed and approved here. There is currently an opened issue to address the question you asked here. Generally this issue status at this time is that providing such an API would bring too much complexities (not so much about the sections as a list, but about the content of each). That makes sense to me, because the WebAssembly standard is currently in very active development (many post-MVP features are in progress).
That said, it seems that you are left off to parse the binary by yourself. The binary format is documented here. Basically, after you parse the magic number and the version there is a list of sections: 1 byte ID, one u32 (LEB128 format with allowed trailing zeroes) for the section's byte content length and then are the bytes of the section's content (with that length). After this header and the content bytes, is the next section, if any, till the end.
The custom sections have an id of 0. The content of these sections starts with a name and after it are the section "user" bytes. This name is a vector of bytes. Each vector has a length (again u32) followed by that number of bytes that must be the UTF-8 encoded string.
So the pseudo-code is something like this:
parse the magic
parse the version
loop till there are bytes
read the section id
read the section u32 length
if id = 0 then
read the name u32 length
skip the name bytes
use the user bytes till the end of the section
jump to the end of the section
The codelab example for using gcloud translate via python only translates one string:
sample_text = "Hello world!"
target_language_code = "tr"
response = client.translate_text(
contents=[sample_text],
target_language_code=target_language_code,
parent=parent,
)
for translation in response.translations:
print(translation.translated_text)
But since it puts sample_text in a list and iterates over the response, I take it one can submit a longer list. Is this true and can I count on the items in the response corresponding to the order of items in contents? This must be the case but I can't find a clear answer in the docs.
translate_text contents is a Sequence[str] but must be less than 30k (codepoints).
For longer than 30k, use batch_translate_text
APIs Explorer provides an explanation of the request and response types for the translateText method. This allows you to call the underlying REST API method and it generates a 'form' for you in which content is an array of string (as expected).
The TranslateTextResponse describes translations as having the same length as contents.
There's no obvious other way to map entries in contents with translations so these must be in the same order, translations[foo] being the translation of contents[foo].
You can prove this to yourself by:
making the call with multiple known translations
including one word not in the source language (i.e. notknowninenglish in English) to confirm the translation result.
I am trying to do an XSL transform on an xml structure in a bpel assignment statement. There is a syntax problem, but I am having trouble finding official documentation. There are examples all over the internet but I have not found a clear explanation. Here is my best shot. What do the last two parameters do? Why is eclipse saying the first argument must be a literal, even though test3.xsl is a string?
<bpel:assign validate="yes" name="Assign">
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("test3.xsl", $personalInfoServiceOutput.parameters), "middle", $positionSkillManagementInput]]>
</bpel:from>
<bpel:to variable="positionSkillManagementInput"></bpel:to>
</bpel:copy>
</bpel:assign>
The signature of doXSLTransform looks as follows:
object bpel:doXslTransform(string, node-set, (string, object)*)
The first parameter is the name of the XSLT script, the second parameter is an XPath identifying the source document (e.g. a variable, part, nodeset, node). The third and the fourth parameter is a key-value pair, the string is the key and the object is the value. Those pairs are mapped into the script's parameter context so that you can access these values by their name in the script. There can be any number of these pairs.
The best resource to look up such things is the WS-BPEL 2.0 specification, doXSLTransform is described in Sect. 8.4
When I use the following code :
<bpel:copy keepSrcElementName="no">
<bpel:from>
<![CDATA[bpel:doXslTransform("parseSample.xsl", $output.payload)]]>
</bpel:from>
<bpel:to variable="output"></bpel:to>
</bpel:copy>
I also get the error, that first argument must be literal string.
But, when I deploy my service (with error) to wso2 bps, it works fine.
You can try with this.
I faced the same issue. Agree with NGoyal. Shows error in BPEL but works when deployed.
Are there restricted character patterns within Azure TableStorage RowKeys? I've not been able to find any documented via numerous searches. However, I'm getting behavior that implies such in some performance testing.
I've got some odd behavior with RowKeys consisting on random characters (the test driver does prevent the restricted characters (/ \ # ?) plus blocking single quotes from occurring in the RowKey). The result is I've got a RowKey that will insert fine into the table, but cannot be queried (the result is InvalidInput). For example:
RowKey: 9}5O0J=5Z,4,D,{!IKPE,~M]%54+9G0ZQ&G34!G+
Attempting to query by this RowKwy (equality) will result in an error (both within our app, using Azure Storage Explorer, and Cloud Storage Studio 2). I took a look at the request being sent via Fiddler:
GET /foo()?$filter=RowKey%20eq%20'9%7D5O0J=5Z,4,D,%7B!IKPE,~M%5D%54+9G0ZQ&G34!G+' HTTP/1.1
It appears the %54 in the RowKey is not escaped in the filter. Interestingly, I get similar behavior for batch requests to table storage with URIs in the batch XML that include this RowKey. I've also seen similar behavior for RowKeys with embedded double quotes, though I have not isolated that pattern yet.
Has anyone co me across this behavior? I can easily restrict additional characters from occurring in RowKeys, but would really like to know the 'rules'.
The following characters are not allowed in PartitionKey and RowKey fields:
The forward slash (/) character
The backslash (\) character
The number sign (#) character
The question mark (?) character
Further Reading: Azure Docs > Understanding the Table service data model
public static readonly Regex DisallowedCharsInTableKeys = new Regex(#"[\\\\#%+/?\u0000-\u001F\u007F-\u009F]");
Detection of Invalid Table Partition and Row Keys:
bool invalidKey = DisallowedCharsInTableKeys.IsMatch(tableKey);
Sanitizing the Invalid Partition or Row Key:
string sanitizedKey = DisallowedCharsInTableKeys.Replace(tableKey, disallowedCharReplacement);
At this stage you may also want to prefix the sanitized key (Partition Key or Row Key) with the hash of the original key to avoid false collisions of different invalid keys having the same sanitized value.
Do not use the string.GetHashCode() though since it may produce different hash code for the same string and shall not be used to identify uniqueness and shall not be persisted.
I use SHA256: https://msdn.microsoft.com/en-us/library/s02tk69a(v=vs.110).aspx
to create the byte array hash of the invalid key, convert the byte array to hex string and prefix the sanitized table key with that.
Also see related MSDN Documentation:
https://msdn.microsoft.com/en-us/library/azure/dd179338.aspx
Related Section from the link:
Characters Disallowed in Key Fields
The following characters are not allowed in values for the PartitionKey and RowKey properties:
The forward slash (/) character
The backslash (\) character
The number sign (#) character
The question mark (?) character
Control characters from U+0000 to U+001F, including:
The horizontal tab (\t) character
The linefeed (\n) character
The carriage return (\r) character
Control characters from U+007F to U+009F
Note that in addition to the mentioned chars in the MSDN article, I also added the % char to the pattern since I saw in a few places where people mention it being problematic. I guess some of this also depends on the language and the tech you are using to access the table storage.
If you detect additional problematic chars in your case, then you can add those to the regex pattern, nothing else needs to change.
I just found out (the hard way) that the '+' sign is allowed, but not possible to query in PartitionKey.
I found that in addition to the characters listed in Igorek's answer, these also can cause problems (e.g. inserts will fail):
|
[]
{}
<>
$^&
Tested with the Azure Node.js SDK.
I transform the key using this function:
private static string EncodeKey(string key)
{
return HttpUtility.UrlEncode(key);
}
This needs to be done for the insert and for the retrieve of course.
Can subdomains (domain names) have underscore _ in them?
Most answers given here are false. It is perfectly legal to have
an underscore in a domain name. Let me quote the standard, RFC
2181, section 11, "Name syntax":
The DNS itself places only one restriction on the particular labels
that can be used to identify resource records. That one
restriction relates to the length of the label and the full
name. [...] Implementations of the DNS protocols must not place any
restrictions on the labels that can be used. In particular, DNS
servers must not refuse to serve a zone because it contains labels
that might not be acceptable to some DNS client programs.
See also the original DNS specification, RFC 1034, section 3.5
"Preferred name syntax" but read it carefully.
Domains with underscores are very common in the wild. Check _jabber._tcp.gmail.com or _sip._udp.apnic.net.
Other RFC mentioned here deal with different things. The original
question was for domain names. If the question is for host
names (or for URLs, which include a host name), then this is
different, the relevant standard is RFC 1123, section 2.1 "Host
Names and Numbers" which limits host names to
letters-digits-hyphen.
A note on terminology, in furtherance to Bortzmeyer's answer
One should be clear about definitions. As used here:
domain name is the identifier of a resource in a DNS database
label is the part of a domain name in between dots
hostname is a special type of domain name which identifies Internet hosts
The hostname is subject to the restrictions of RFC 952 and the slight relaxation of RFC 1123
RFC 2181 makes clear that there is a difference between a domain name and a hostname:
...[the fact that] any binary label can have an MX record does not imply that any binary name can be used as the host part of an e-mail address...
So underscores in hostnames are a no-no, underscores in domain names are a-ok.
In practice, one may well see hostnames with underscores. As the Robustness Principle says: "Be conservative in what you send, liberal in what you accept".
A note on encoding
In the 21st century, it turns out that hostnames as well as domain names may be internationalized! This means resorting to encodings in case of labels that contain characters that are outside the allowed set.
In particular, it allows one to encode the _ in hostnames (Update 2017-07: This is doubtful, see comments. The _ still cannot be used in hostnames. Indeed, it cannot even be used in internationalized labels.)
The first RFC for internationalization was RFC 3490 of March 2003, "Internationalizing Domain Names in Applications (IDNA)". Today, we have:
RFC 5890 "IDNA: Definitions and Document Framework"
RFC 5891 "IDNA: Protocol"
RFC 5892 "The Unicode Code Points and IDNA"
RFC 5893 "Right-to-Left Scripts for IDNA"
RFC 5894 "IDNA: Background, Explanation, and Rationale"
RFC 5895 "Mapping Characters for IDNA 2008"
You may also want to check the Wikipedia Entry
RFC 5890 introduces the term LDH (Letter-Digit-Hypen) label for labels used in hostnames and says:
This is the classical label form used, albeit with some additional restrictions, in hostnames (RFC 952). Its syntax is identical to that described as the "preferred name syntax" in Section 3.5 of RFC 1034 as modified by RFC 1123. Briefly, it is a string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets.
Going back to simpler times, this Internet draft is an early proposal for hostname internationalization. Hostnames with international characters may be encoded using, for example, 'RACE' encoding.
The author of the 'RACE encoding' proposal notes:
According to RFC 1035, host parts must be case-insensitive, start and end with a letter or digit, and contain only letters, digits, and the hyphen character ("-"). This, of course, excludes any internationalized characters, as well as many other characters in the ASCII character repertoire. Further, domain name parts must be 63 octets or shorter in
length.... All post-converted name parts that contain internationalized characters begin with the string "bq--". (...) The string "bq--" was chosen because it is extremely unlikely
to exist in host parts before this specification was produced.
There is one additional thing you may need to know: If the host or subdomain part of the url contain an underscore, IE9 (have not tested other versions) cannot write cookies.
So be careful about that. :-)
Clarifying bortzmeyer and David Tonhofer, domain name and subdomain name labels can contain leading underscores, but nowhere else.
As David Tonhofer wrote, labels are the in-between-the-periods parts and should follow the LDH rule except when specifying service labels and port labels to differentiate them from regular labels. Then they must occur at the beginning of the label which should be the "Short Names" from the Service Name and Port Number Registry, the port number with no leading 0s, or the protocol (ie. tcp, udp). These service labels are further limited to 15 characters.
RFC2782 specifies prefixing
service record subdomains with underscores.
RFC6698 specifies prefixing
port numbers with underscores in TLSA certificate records.
Contrary to David Tonhofer's answer, IDN does not allows for encoding underscore ('_' U+005F LOW LINE) or any other invalid ASCII character.
From RFC5890
[..] two new subsets of LDH labels are created by the
introduction of IDNA. These are called Reserved LDH labels (R-LDH
labels) and Non-Reserved LDH labels (NR-LDH labels). Reserved LDH
labels, known as "tagged domain names" in some other contexts, have
the property that they contain "--" in the third and fourth
characters but which otherwise conform to LDH label rules.
Punycode encodes all ASCII codepoints as ASCII directly, including underscore. The resulting R-LDH would not conform the the LDH label rules. For example, Σ_.com would be encoded as xn--_-zmb.com which violates the rules. There may be a homographic codepoint which looks like an underscore that can be coded legally (perhaps '＿' U+FF3F fullwidth low line), but these kinds of codepoints would be categorized as DISALLOWED by RFC5892 under 2.3 IgnorableProperties as a Noncharacter_Code_Point.
RACE (the other proposed IDN encoding scheme) was not accepted as a standard by IETF and should not be used.
Recently the CAB-forum (*) decided that
All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019. https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/
This means that you are no longer allowed to use underscores in domains that will have a ssl/tls certificate.
(*) The Certification Authority Browser Forum (CA/Browser Forum) is a voluntary gathering of leading Certificate Issuers (as defined in Section 2.1(a)(1) and (2) below) and vendors of Internet browser software and other applications that use certificates (Certificate Consumers, as defined in Section 2.1(a)(3) below).
I followed the link to RFC1034 and read most of it and was surprised to see this:
The labels must follow the rules for ARPANET host names. They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen. There are also some
restrictions on the length. Labels must be 63 characters or less.
For clarification, a domain names are made up of labels which are separated by dots ".". This spec must be outdated because it doesn't mention the use of underscores. I can understand the confusion if anybody stumbles over this spec without knowing it is obsolete. It is obsolete, isn't it?
I followed the link to RFC2181 and read some of it. Especially where it pertains to the issue of what is an authoritative, or canonical, name and the issue of what makes a valid DNS label.
As posted earlier it states there's only a length restriction then to sum it up it reads:
(about names and valid labels)
These are already adequately specified, however the specifications seem to be sometimes ignored. We seek to reinforce the existing specifications.
Kind of leaves me wondering if "a length only restriction" is "adequate". Are we going to start seeing domain names like ##$%!! soon? Isn't the internet screwed up enough?
Here my 2 cents from Java world:
From a Spark Scala console, with Java 8:
scala> new java.net.URI("spark://spark_master").getHost
res10: String = null
scala> new java.net.URI("spark://spark-master").getHost
res11: String = spark-master
scala> new java.net.URI("spark://spark_master.google.fr").getHost
res12: String = null
scala> new java.net.URI("spark://spark.master.google.fr").getHost
res13: String = spark.master.google.fr
scala> new java.net.URI("spark://spark-master.google.fr:3434").getHost
res14: String = spark-master.google.fr
scala> new java.net.URI("spark://spark-master.goo_gle.fr:3434").getHost
res15: String = null
It's definitely a bad idea ^^
Individual TLD's can place their own rules & restrictions on domains names as they see fit, such as to accomodate local languages.
For example, according to the CIRA, Canada's .ca domain names are allowed:
Letters a through z, and the following accented characters: é ë ê è â à æ ô œ ù û ü ç î ï ÿ. Note that Domain Names are not case sensitive. This means there will be no distinction made between upper case letters and lower case letters (A = a);
The numbers 0123456789, and
The hyphen character ("-) (although it cannot be used to start or end a Domain Name).
The maximum length is 63 characters, except each accented character reduces that limit by 4 characters.
(Source)
Incidentally, this allows for around 4 Quadragintillion domain name possibilities (not counting sub-domains) for dot-ca domains.
Regardless of the host name vs domain name discussion, it is definately a very bad idea to use underscores in the host part of a url. It will cause you grief. It may well work in a browser, but in one case I ran into recently an app refused to make a tls connection with a perfectly valid wildcard certificate for *.s3. amazonaws.com because the wildcard host name part had an underscore in it and would not validate. I believe the underlying library used openssl.
As of 2023, there are websites appearing on Google search whose subdomains contain underscores, like https://my_sarisari_store.typepad.com
No, you can't use underscore in subdomain but hypen (dash). i.e my-subdomain.agahost.com is acceptable and my_subdomain.agahost.com would not be acceptable.
Just created local project (with vagrant) and it was working perfectly when accessed over ip address. Then I added some_name.test to hosts file and tried accessing it that way, but I was getting "bad request - 400" all the time. Wasted hours until I figured out that just changing domain name to some-name.test solves the problem. So at least locally on Mac OS it's not working.