HEAD
A public key authentication scheme for HTTP transactions, specifying a minimal HTTP extension for mutual authentication, message origin authentication, message sequence integrity, content integrity, and content ciphering.
This document is a draft specification which may undergo minor changes, both normative and presentational.
This specification describes a public key authentication scheme for HTTP transactions. It provides a minimal HTTP extension for mutual authentication and message origin authentication. It offers integrity protection of a defined set of HTTP message headers, message sequence integrity, content integrity, and content ciphering.
This scheme is designed to fit into the generic authentication framework of RFC2616 [HTTP], as exploited in RFC2617 [HTTP-Authentication].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]
"Peer" refers generically to either of the two principals acting as requester and responder in an HTTP message exchange. Formally, a peer is a logical entity that can invoke its associated private key for the purpose of that exchange. Note that user-agents and/or servers may act as (or for) a multitude of logically distinct peers, and are thus not themselves considered necessarily equivalent to those peers.
"Message" refers generically to an HTTP message, be it a request or a response.
"requester" refers to the peer sending a request message and receiving a response message.
"responder" refers to the peer receiving a request message and sending a response message.
"Encryption" is used in relation to asymmetric key operations, whereas the term "cipher" is used in relation to symmetric key operations.
The identifier for this scheme is "httpsec/1.0
". This literal features in protocol headers and in
various protocol computations.
The identifier for the Content-Encoding defined for message-body
ciphering is "x-httpsec/1.0-cipher
".
This specification describes a concrete syntax for a public key authentication scheme for HTTP transactions. It provides a minimal HTTP extension for mutual authentication and message origin authentication, via the integrity protection of a defined set of HTTP message headers. It offers message sequence integrity, forward secrecy, and optionally content integrity and content ciphering.
It is intended for application in situations where credential-based schemes are inappropriate for architectural reasons or are considered too weak, and also where message-layer and/or application-layer security requirements are not fulfilled by transport-layer or network-layer security protocols. It is not intended as a substitute for lower- or higher-layer security protocols, and indeed may be found to usefully coexist with these.
This scheme uses public keys for the mutual authentication of peers. More precisely, it allows one peer to authenticate a message that purports to originate from another peer.
As with all public key authentication schemes, acceptance of the authenticity of a peer is equivalent to establishing that the peer possesses the private key paired with a certain public key. The authentication model is thus predicated on the assumption that the authenticator can correctly associate a public key with the peer it is authenticating. Accordingly, a candidate purporting to be such a peer is considered authentic if it can demonstrate its ability to invoke the associated private key. This document does not address the process by which a public key is associated (correctly or not) with a peer. The protocol is intended to be able to integrate with any number of such mechanisms, from "leap of faith" type schemes such as employed by SSH, to trust-based schemes such as PKI style certification.
A peer has an associated identifier. This acts as a logical reference to the peer's public key. These peer identifiers are literals that are purposefully opaque in this specification. The combination of an identifier and the public key associated with it is the "authenticated peer" from the perspective of an other peer that authenticates it.
In some use-cases, the public key of one peer is considered to be known (or retrievable in a trusted manner) by a second peer that requires it in order to authenticate the first peer. The first peer's identifier is thus a reference that the second peer may use to retrieve the appropriate public key, for instance from a trusted local store. In other use-cases, for example those that require a bootstrapping capability, public keys are exchanged within the protocol itself.
This protocol enables, and depends on, the establishment of a shared-secret arrangement between the requester and the responder. The protocol has two distinct stages; "initialization" and "continuation". Initialization establishes a shared-secret between the requester and responder via a request/response transaction between the two. It is within this initialization transaction that the public keys of the peers are employed for mutual authentication.
Subsequent continuation transactions carry conventional message payloads. They reference the shared secret established by the initialization stage, and depend on both peers' knowledge of it for their security features. No temporal constraint is placed on the validity of the shared-secret arrangement, which may be chosen independently by either peer to be anything from very short lived to essentially permanent. (The initialization stage could in fact be effected by another process entirely outside of this specification.)
The responder is first authenticated in the initialization stage by the use of digital signatures. The requester is authenticated in each continuation transaction by the use of message authentication codes. This asymmetry allows the requester to authenticate the responder before sending it any data, while keeping all public-key and other key-exchange operations within the single initialization transaction. This mitigates the state-management requirements and ensures that computationally expensive operations are avoided in subsequent continuation messages, of which there may be an arbitrary number.
The requester begins the initialization stage by sending a request containing its initialize parameters. The responder returns with a response containing its initialize parameters. Both these messages contain the peer's identifier, ephemeral Diffie-Hellman key, and optionally their authentication public key. See Initialization Request and Initialization Response for the form these messages take.
This initialization transaction establishes an authenticated shared-secret arrangement between both peers, indexed by a token chosen by the responder. Forward secrecy is ensured by the ephemeral Diffie-Hellman shared-secret exchange. Both peers identically derive temporary message authentication keys and cipher keys from the shared-secret, to be employed in the protection of subsequent continuation messages.
Whereas the protocol mandates certain conditions under which these temporary keys must be discarded, either peer may choose to discard them according to rules of their own, for instance based on elapsed time since last usage.
Continuation requests carry a token to reference a previously initialized shared-secret arrangement. All continuation messages carry message authentication codes to determine message origin authenticity, partial sequence integrity, and optionally entity-body integrity. Continuation messages may employ optional message body ciphering at the discretion of the sending peer. In all other respects, continuation messages are conventional HTTP messages. See Continuation Request and Continuation Response for the form these messages take.
The responder may at any stage prompt initialization (or re-initialization) by returning a challenge response. See Challenge Response for the form this message takes.
All protocol parameters are carried in existing HTTP message headers. The Authorization
request header
[HTTP][ Section 14.8] carries the requester's protocol parameters. The WWW-Authenticate
response
header [HTTP][ Section 14.47] carries the responder's
responder's parameters. These are the headers implied wherever reference is made in this document to the passing of
protocol parameters by the respective peers.
The HTTP header definitions in this specification use the augmented Backus-Naur form of [HTTP] [Section 2.1], and use these common terminators:
base64 = *(4base64-char) [base64-terminal] base64-char = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" | "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | "+" | "/" base64-terminal = (2base64-char "==") | (3base64-char "=") decimal = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
Definitions of individual header directives are given in the Protocol Directives section.
Messages containing an initialize
directive assert that the sending peer is providing initialization
parameters. Successful initialization requires an initialization
request and an associated initialization response.
The Authorization
header [HTTP][ 14.8] in protocol initialization
requests has the following form:
"Authorization: httpsec/1.0 initialize, " 1#( id | dh | [certificate] | url | group | nonce ) id = "id=" <URI> dh = "dh=" base64 certificate = "certificate=" <URI> url = "url=" <URI> group = "group=" <string-no-whitespace> nonce = "nonce=" base64
Example message:
HEAD http://alice.example.com/foobar.txt HTTP/1.1 Authorization: httpsec/1.0 initialize id=bob.example.com dh=clW9y2X5Vy+5+Ncv5lAI3W9y2X5Vgfe4y+5+Ncv5l... certificate=http://bob.example.com/my-cert url=http://alice.example.com/foobar.txt group=rfc3526#14 nonce=7iqgkzgfdIe0HN35r6met2579yxetyerty7MZW...
(For legibility, the example's protocol header is extended over multiple lines, as per [HTTP][4.2]. Additionally, the values of some directives are lengthy and have therefore been abbreviated; their terminating ellipsis "..." would NOT appear in the actual value.)
An initialization request has a HEAD method [HTTP][ Section 9.4], unless it carries a certificate payload in the message entity-body (see certificate section) in which case it has a POST method [HTTP][ Section 9.5].
Its Request-URI [HTTP][ Section 5.1.2] is typically be that of a protected resource hosted by the responder and ultimately desired by the requester, but this is not normative.
The WWW-Authenticate
header [HTTP][ 14.47] in protocol initialization
responses has the following form:
"WWW-Authenticate: httpsec/1.0 initialize, " 1#( id | dh | [certificate] | token | auth | signature ) token = "token=" <string-no-whitespace> id = "id=" <URI> dh = "dh=" base64 certificate = "certificate=" <URI> auth = "auth=" base64 signature = "signature=" base64
Example message:
HTTP/1.1 401 Authorization Required Expires: Thu, 11 Aug 2005 18:20:42 GMT Cache-Control: no-transform WWW-Authenticate: httpsec/1.0 initialize id=alice.example.com dh=+NcclW9y2I3W9X5Vy+5v5lAy4X56y+Ncrwrtv5lqe... certificate=http://alice.example.com/my-cert token=mCa5tx1vKBY auth=vpCNmx7MZ7iqgkzIe0HWwfyrOMeqwg0TdbpwefI... signature=2pX3SNgzWkV3w0W9y2X5V23hhy+5b8DQmo...
(For legibility, the example's protocol header is extended over multiple lines, as per [HTTP][4.2]. Additionally, the values of some directives are lengthy and have therefore been abbreviated; their terminating ellipsis "..." would NOT appear in the actual value.)
Messages containing a continue
directive assert that the message is protected by security features that
derive from a previously initialized shared-secret arrangement. A continuation transaction constitutes a continuation request and an associated continuation response.
A continuation message MUST pass Message Validation or be immediately discarded by the peer that receives it.
The Authorization
header [HTTP][ 14.8] in protocol continuation
requests has the following form:
"Authorization: httpsec/1.0 continue, " 1#( token | url | count | mac | [digest] ) token = "token=" <string-no-whitespace> url = "url=" <URI> count = "count=" 1*decimal mac = "mac=" base64 digest = "digest=" base64
Example message:
GET http://alice.example.com/foobar.txt HTTP/1.1 Authorization: httpsec/1.0 continue token=mCa5tx1vKBY url=http://alice.example.com/foobar.txt count=1 mac=zhHPRbxqf3KSMQpjCnpDQmyBnoqiNDMQLjRtMjxUcM=
(For legibility, the example's protocol header is extended over multiple lines, as per [HTTP][4.2].)
The WWW-Authenticate
header [HTTP][ 14.47] in protocol continuation
responses has the following form:
"WWW-Authenticate: httpsec/1.0 continue, " 1#( count | mac | [digest] ) count = "count=" 1*decimal mac = "mac=" base64 digest = "digest=" base64
Example message:
HTTP/1.1 200 OK
Date: Thu, 11 Aug 2005 18:20:48 GMT
Expires: Thu, 11 Aug 2005 18:20:48 GMT
Content-Type: text/plain;charset=ISO-8859-1
Content-Length: 1234
Cache-Control: no-transform
Content-Encoding: x-httpsec/1.0-cipher
WWW-Authenticate: httpsec/1.0 continue
count=2
mac=VplDHX3SNgzWkLKgZkjZ+I5wvImOHAMptVSc/Abttps=
digest=V3w0W9y2X5Vy+5+Ncv5lAI3rb8qMlGzrOh9zjHXRHbk=
<entity-body ciphertext bytes>
(For legibility, the example's protocol header is extended over multiple lines, as per [HTTP][4.2].)
The challenge response is an assertion by the responder that the requested resource is protected by HTTPsec. It is an invitation, made by responder to requester, to make a subsequent initialization request.
In the handling of a Challenge Response, the requester SHOULD employ a method of limiting the extent of potential deadlock from a repeated series of challenge, for instance limiting them to an arbitrary number such as 3.
The WWW-Authenticate
header [HTTP][ 14.47] for challenge responses has
the following form:
"WWW-Authenticate: httpsec/1.0 challenge, " 1#( id | [certificate] ) id = "id=" <URI> certificate = "certificate=" <URI>
Example message:
HTTP/1.1 401 Unauthorized WWW-Authenticate: httpsec/1.0 challenge id=alice.example.com certificate=http://alice.example.com/my-cert
(For legibility, the example's protocol header is extended over multiple lines, as per [HTTP][4.2].)
This section details the conditions which regulate how requests and responses are matched, and which HTTP status codes [HTTP][ Section 10] are set by the responder.
401 Unauthorized
" [HTTP][ 10.4.2] status. The requester may
subsequently send an initialization request.401 Unauthorized
"
[HTTP][ 10.4.2] status.400 Bad Request
" [HTTP][ 10.4.1]
status.401 Unauthorized
" [HTTP][ 10.4.2].401 Unauthorized
" [HTTP][ 10.4.2] status. The requester may subsequently send an initialization request.All protocol parameters feature as directives in initialization messages and continuation messages. These directives are detailed in this section.
The id
directive in an initialization request is the
requester's Peer Identifier. From the responder's perspective, this acts
as a logical reference to the requester's public-key.
The id
directive in an initialization response or a
challenge response is the responder's Peer Identifier. From the requester's perspective, this acts as a logical reference to the responder's
public-key.
The dh
directive in an initialization request and an
initialization response provides the sending peer's ephemeral
Diffie-Hellman public key.
This directive is calculated as follows:
dh = g ^ dh-private MOD p
where the following apply:
g
is the generator of the Diffie-Hellman group. The latter is chosen by the requester and identified
by the group
directive in the initialization request.p
is the prime modulus of the Diffie-Hellman group.private-dh
is a random integer in the range: 2...q-2
where q
is the
subgroup order of the Diffie-Hellman group. Note that q =
(p-1)/2
for all the MUST IMPLEMENT groups.The value of private-dh
is chosen by the sending peer from a source of cryptographic-quality
randomness, and is treated as strictly private. It SHOULD be generated anew for each new initialization, in which case
it SHOULD be discarded immediately after the computation of the shared
secret. However if computational resources are limited it MAY be reused across multiple initializations, but this
will affect the effective extent of the protocol's claim to forward secrecy.
The optional certificate
directive in an initialization
request and an initialization response provides the sending
peer's certificate containing its (purported) authentication public key. The directive may also be employed for
informational purposes in a challenge response. In some use-cases a
peer's public key is prior-knowledge from the perspective of the other peer, and thus the certificate
directive is not required.
If employed, its value MUST be a valid URI as specified in [URI] Section 3.
Certificates provided by the certificate
directive MUST be in X509 [X509] certificate format to allow (if required) the use of a Public Key Infrastructure.
Implementations MAY support either or all of the following:
certificate=data:application/x-x509-user-cert;base64,MIGfMA0GCSqGSI...(the value is lengthy and has therefore been abbreviated; the terminating ellipsis "..." would NOT appear in an actual value)
certificate=http://alice.example.com/my-cert
this:entity-body
" to indicate that the X509 certificate is carried in the
message entity-body. For example
certificate=this:entity-body
In all cases, the Mine-Type of the certificate payload MUST be "application/x-x509-user-cert
".
Certificates in entity-bodies may optionally have the PEM specified header, footer and line breaks.
Note that in the first usage, the certificate payload itself features in the Initialization Transcript and its presence in the initialisation stage is thus authenticated by the signature. This may be considered favourable in some use-cases.
The url
directive in an initialization request and a
continuation request is the the absolute URL of that request. The
latter is duplicated in this directive because proxies are legitimately allowed to change the Request-Line in
transit.
The responder MUST confirm that the value of this directive is equivalent to the absolute URL implied by the
request's Request-Line
[HTTP] and Host
[HTTP] header. Equivalence conditions for URLs are given in [URI] Section 6.
The group
directive in an initialization request is
the identifier of a Diffie-Hellman modular exponential group, as chosen by the requester. It's value MUST NOT contain
whitespace.
Any or all of the following identifiers and their associated groups MAY be implemented:
"rfc3526#14" ; group #14 defined in [MODP] "rfc3526#15" ; group #15 defined in [MODP] "rfc3526#16" ; group #16 defined in [MODP] "rfc3526#17" ; group #17 defined in [MODP] "rfc3526#18" ; group #18 defined in [MODP]
Other identifiers may be also defined.
The nonce
directive in an initialization request
allows the requester to send a random value to the responder. This acts as an authentication challenge to the
responder, who is challenged to posses the correct private key in order to create a valid signature
directive in the initialization
response.
This value is a base64 encoded 256 bit cryptographic-quality random value, which MUST be generated afresh by the requester for each new initialization.
The auth
directive in an initialization response
allows the responder to send an encrypted random value to the requester. This acts as an authentication challenge to
the requester. The random value auth-secret
is encrypted in the requester's public key, yet features
unencrypted in the shared secret which must be identically known to both
parties for the authentication success of subsequent continuation
messages. The requester is thus challenged to posses the correct private key to decrypt the value of the
auth
directive.
The auth
directive is computed as follows:
auth = base64enc( ENC( public-key, auth-secret ) )
where the following apply:
base64enc()
is base64 encoding, bytes to string.ENC( k, pt )
is encryption according to the Encryption
Scheme in public key k
of plaintext pt
.public-key
is the public key associated
(subjectively, by the responder) with the requester.auth-secret
is 256 bit cryptographic-quality random value generated by the responder, which MUST be
generated afresh by the responder for each new initialization.The requester decrypts the auth
directive to retrieve the auth-secret
value as
follows:
auth-secret = DEC( private-key, base64dec( auth ) )
where the following apply:
base64dec()
is base64 decoding, string to bytes.DEC( k, ct )
is decryption according to the Encryption
Scheme with private key k
of ciphertext value ct
.private-key
is the requester's private key.auth-secret
is 256 bit random value.In an initialization response, the token
directive
is is an opaque reference to the newly initialized shared-secret arrangement. Its value is chosen by the responder, and
MUST be unique within the responder's record of valid tokens. It's value MUST NOT contain whitespace, but its length or
other characteristics are not otherwise constrained.
In a continuation Request the token
directive is
employed by the requester as a reference to a previously initialized shared-secret arrangement. From the perspective of
both the request's requester and its responder, the referenced arrangement implies the MAC keys to create or validate mac
directives, and implies the
cipher keys for message body
ciphering or deciphering.
The signature
directive in an initialization
response is used to verify the integrity of all the initialization directives and thus allows the requester to
authenticate the responder prior to making any continuation requests.
The signature
directive is computed by the responder as follows:
signature = base64enc( SIGN( private-key, init-transcript ) )
where the following apply:
base64enc()
is base64 encoding, bytes to string.SIGN(k,m)
is the signature over string m
using private key k
according to
the Signature Scheme.private-key
is the responder's authentication key private key.init-transcript
is a concatenation of all the initialization directives, computed according to the
Initialization Transcript section.The signature
directive is validated by the requester as follows:
VALIDATE( public-key, init-transcript, base64dec( signature ) )
where the following apply:
base64dec()
is base64 decoding, string to bytes.VALIDATE(k,m,s)
is the validation of a signature s
over a string m
using
public key k
, according to the Signature Scheme.signature
is the value of the received directive.public-key
is the public key associated (subjectively, by the requester) with the responder. Note
that this may or may not be equivalent the public key implied by the certificate
directive, depending on the trust mechanism employed by the requester.init-transcript
is a concatenation of all the initialization directives, computed according to the
Initialization Transcript section.The count
directive is a sequence counter for continuation messages. This directive allows the
detection of message replays and provides partial message sequence integrity. It is also required for the production of
unique initialization vectors for message body ciphering.
The value of the count
directive is a decimal number. In a request, it MUST be greater than zero and
less than (2^128 - 1). In a response, it MUST be greater than one and less than or equal to (2^128 - 1).
The following constraints apply to this directive in continuation messages containing identical token
directive values. Messages with identical or out-of-sequence count
directive values MUST be rejected by the receiving peer. Peers MUST validate the count
directive in each
received message to establish uniqueness and correct sequence. Each peer is required to maintain a local record of the
value of the count
directive employed in the last continuation message that it sent. The validity
constraints and logic for setting this directive differ slightly from the perspectives of the two peers:
count
value of N+1, where N is the count
value in the
associated request.count
value N MUST be strictly greater than the count
value
that the responder sent in its last response. The response MUST be given a count
value of N+1.If a first request receives no response, the count
directive in a second request that immediately
follows should increment by (at least) 2, to allow for the fact that the unreceived response was nevertheless sent by
the responder. In the case that the first request contained an "Expect: 100-continue
" header [HTTP][14.20] the increment should be (at least) 3, as such requests may elicit two distinct responses.
The mac
directive in a continuation request and a
continuation response is a keyed message authentication code computed
on the values of protocol directives and specific HTTP headers present in that continuation transaction. It employs a
MAC Key derived from the Shared
Secret.
To create a message authentication code for a message either prior to sending it or in order to validate it, the appropriate computation is made as follows:
Request: mac = base64enc( HMAC( request-mac-key, request-transcript ) ) Response: mac = base64enc( HMAC( response-mac-key, response-transcript ) )
where the following apply:
base64enc()
is base64 encoding, bytes to string.HMAC(k,d)
is the Hashed Message Authentication Code [HMAC]
using key k
applied to byte data d
, employed using the Hash Algorithm.request-mac-key
and response-mac-key
are as derived in the section MAC Keys.request-transcript
is computed according to the Continuation Request Transcript section.response-transcript
is computed according to the Continuation Response Transcript section.The message authentication codes are formulated so as to provide the following:
The sender of a message computes and provides the message authentication code for that message. To validate it, the
recipient of the message also computes its message authentication code and compares the received value with the
computed value. If (1) they are strictly equal, and (2) the digest
directive (if present) is confirmed to indeed equal the hash of the message entity-body, then the above authentication
characteristics are considered to be established. If not, the message MUST be rejected. This two stage process permits
computationally inexpensive invalidity checks to be performed before embarking on the potentially expensive process of
computing the digest
over an arbitrary length entity-body.
The the optional digest
directive in a continuation
request or a continuation response is a hash digest of the
message entity-body. It's role is to enable message entity-body authentication: its value is an input to the
computation of the mac
directive (via the appropriate message transcript).
This directive SHOULD be present in any continuation message for which it is feasible to calculate a hash digest of the
entity-body (including, trivially, all those with an empty entity-body).
The value of the digest
directive is a hash of the entity-body, computed using the Hash Algorithm. The hash MUST be computed on the entity-body as manifest
after all encodings declared in the Content-Encoding [HTTP][ 14.11] header (including the cipher
encoding with the identifier "x-httpsec/1.0-cipher
" defined in the Message Body Ciphering section) and before Transfer-Encoding [HTTP][ 14.41].
The absence of the digest
directive implies that the message entity-body is not authenticated. This may
be the case if the entity-body cannot be hashed for some reason by the message sender, for instance if it is a stream
of indeterminate length.
The value of the digest
directive MUST be base64 encoded. For empty message bodies, it is the following
constant (being the Base64 representation of the hash of zero bytes):
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
This specification impacts on certain other HTTP header field definitions, as detailed in this section.
The Content-Encoding header [HTTP][ 14.11] MAY contain the value
"x-httpsec/1.0-cipher
" in its enumeration of applied encodings, to indicate that the message entity body
is ciphered according to this specification - see the Message_Body_Ciphering section for details.
The Cache-Control
header [HTTP][ 14.9] MUST be present in every
initialization response and continuation response. It MUST contain at minimum the no-transform
directive [HTTP][ 14.9.5]. See the Cache Considerations section for
additional discussion.
The Expires header [HTTP][ 14.21] MUST be present in every
initialization response and continuation response. responses. Its value MUST be the system clock time, current at the time of the
preparation of the response's WWW-Authenticate: httpsec/1.0 continue
header. Whist the value of this
header appears in the computation of the mac directive, it has no explicit role in
message validation. See also the Cache Considerations section for additional discussion.
Wherever they are referred to in this specification, the cryptographic primitives defined in this section MUST be employed.
SHA-256 [SHA].
RSA [PKCS#1] asymmetric key encryption. The modulus of key MUST be 1024 bits or greater.
RSA Optimal Asymmetric Encryption Padding (RSAES-OAEP) [PKCS#1], using hash function SHA-1, mask generation function MGF1 (with SHA-1), and the empty-string for the "label" parameter.
Note: whereas SHA-256 is specified as the Hash Algorithm primitive for employment elsewhere in the protocol, the choice of the SHA-1 here is made for the following reasons:
RSA Probabilistic Signature Scheme (RSASSA-PSS) [PKCS#1], using hash function SHA-256, mask generation function MGF1 (with SHA-256), and salt length of 32 bytes.
Advanced Encryption Standard [AES], 256 bit key length.
Cipher Block Chaining mode [CBC], with PKCS#5 [PKCS#5 ] padding, applied to the Block Cipher.
The values of various HTTP headers [HTTP][ 4.2] other than the protocol headers also feature in protocol computations, notably the signature and message authentication codes. The values of these headers MUST first undergo the following canonicalization transformations, applied in strict order:
;
") and/or commas
(",
");
") any internal substring that consists only of semicolons
(";
") and/or commas (",
").For example, the (albeit unlikely) header field-value ";foo,, ; bar;; foo bar;
" becomes
"foo;bar;foobar
".
Note that this canonicalization is strictly a pre-processing step for the purpose of protocol computations only. It is not a constraint on the actual header field-values that may appear in a message.
The initialization transcript is an input to signature creation and validation, and shared secret computations. It is itself computed as follows:
init-transcript = "httpsec/1.0" || ":" || id || ":" || ; from request dh || ":" || ; from request certificate || ":" || ; from request url || ":" || ; from request group || ":" || ; from request nonce || ":" || ; from request id || ":" || ; from response dh || ":" || ; from response certificate || ":" || ; from response token || ":" || ; from response auth || ":" || ; from response Expires ; from response
where the following apply:
id
, dh
, certificate
, url
, group
,
token
, and auth
refer to the directives contained in the Initialization Messages. They are the directives' literal US-ASCII encoded values exactly as they
appear in those headers.Expires
is the value of [HTTP][ 4.2] header of that name, having
undergone canonicalization as detailed in the Header
Canonicalization section.The continuation request transcript is an input to mac directive creation and validation. It is itself computed as follows:
request-transcript = "httpsec/1.0" || ":" || token || ":" || count || ":" || url || ":" || digest || ":" || Method || ":" || Content-MD5 || ":" || Content-Encoding || ":" || Content-Range || ":" || Content-Type
where the following apply:
token
, count
, url
, and digest
refer to the protocol directives with those names. They are the directives' literal
US-ASCII encoded values exactly as they appear in those headers.Method
is the Method [HTTP][ 5.1.1] from the request's
Request-Line [HTTP][ 5.1].Content-MD5
, Content-Encoding
, Content-Range
, and
Content-Type
refer to [HTTP][ 4.2] headers. Their values MUST first
undergo canonicalization as detailed in the Header
Canonicalization section.The continuation response transcript is an input to mac directive creation and validation. It is itself computed as follows:
response-transcript = "httpsec/1.0" || ":" || token || ":" ; from request || count || ":" || url || ":" ; from request || digest || ":" || Method || ":" ; from request || Status-Code || ":" || Content-Location || ":" || Content-MD5 || ":" || ETag || ":" || Last-Modified || ":" || Expires || ":" || Content-Encoding || ":" || Content-Range || ":" || Content-Type
where the following apply:
token
, count
, url
, and digest
refer to the protocol directives with those names. They are the directives' literal
US-ASCII encoded values exactly as they appear in those headers.Method
is the Method [HTTP][ 5.1.1] from the request's
Request-Line [HTTP][ 5.1].Status-Code
is the three digit Status Code [HTTP][ 6.1.1] from the response's
Status-Line [HTTP][ 6.1].Content-Location
, Content-MD5
, ETag
, Last-Modified
,
Expires
, Content-Encoding
, Content-Range
, and Content-Type
refer
to [HTTP][ 4.2] headers. Their values MUST first
undergo canonicalization as detailed in the Header
Canonicalization section.The security of the protocol depends on the requester and responder establishing an (authenticated) shared secret. Continuation messages employ keys that are derived from this secret value.
The value shared-secret
is computed as follows:
shared-secret = H(H( dh-shared-secret || auth-secret || init-transcript ))
where the following apply:
dh-shared-secret
is calculated by the requester as follows:
dh-shared-secret = dh ^ dh-private MOD pwhere
dh
is from the
initialization response, dh-private
is the requester's private Diffie-Hellman value (see dh
) and p
is the prime modulus of the Diffie-Hellman group chosen
by the requester.
dh-shared-secret
is calculated by the responder as follows:
dh-shared-secret = dh ^ dh-private MOD pwhere
dh
is from the
initialization request, dh-private
is the responders's private Diffie-Hellman value (see dh
) and p
is the prime modulus of the Diffie-Hellman group
identified by the group
directive in the initialization request.
auth-secret
is the 256 bit random value generated by the responder. It is passed in encrypted form
to the requester via the auth
directive in the initialization response.init-transcript
is a concatenation of all the initialization directives, computed according to the
Initialization Transcript section.H(H())
is the Hash Algorithm iteratively applied
twice.From the Shared Secret, both peers derive identical MAC keys and Cipher Keys. Since the Shared Secret is static throughout the lifetime of a particular shared secret arrangement, the keys may be computed once from the shared-secret by each peer and stored for the lifetime of that arrangement. The shared-secret SHOULD be discarded immediately thereafter.
The MAC keys for computing mac directives are produced as follows:
request-mac-key = H(H( shared-secret || "request MAC key" )) response-mac-key = H(H( shared-secret || "response MAC key" ))
where the following apply:
shared-secret
is computed according to the Shared Secret
section.H(H())
is the Hash Algorithm iteratively applied
twice.The keys required for message body ciphering are computed as follows:
request-cipher-key = H(H( shared-secret || "request cipher key" )) response-cipher-key = H(H( shared-secret || "response cipher key" ))
where the following apply:
shared-secret
is computed according to the Shared Secret
section.H(H())
is the Hash Algorithm iteratively applied
twice.Message entity-body ciphering may be be applied to any continuation message, at the discretion of the sending peer.
If entity-body ciphering is applied, this MUST be indicated by the presence of the "x-httpsec/1.0-cipher
"
identifier in the enumeration of applied encodings declared by the Content-Encoding header. The order of operations is "cipher-then-authenticate", i.e. if used ciphering MUST
be applied before the digest computation.
The ciphering of messages whose entity-body is empty will cause the entity-body to become non-empty as an artifact of padding scheme specified in the Block Cipher Mode. This should be taken into consideration when preparing messages for which it is illegal to have an entity body, such as GET requests, HEAD requests, and HEAD responses.
It is important to note that message entity-body ciphering in the absence of message authentication provides no
detection of tampering during message transport. Entity-bodies are "ciphered but not authenticated" if they declare
"x-httpsec/1.0-cipher
" in the Content-Encoding header, but
have no digest
directive. This outcome SHOULD be restricted to
circumstances where it is unfeasible to compute the digest
hash, for
instance when the entity-body is a stream of indeterminate length.
Request entity-bodies are enciphered and deciphered as follows:
Encipher: <body-cipher> = ENCIPHER-MODE( request-cipher-key, IV, <body-plain> ) Decipher: <body-plain> = DECIPHER-MODE( request-cipher-key, IV, <body-cipher> ) where: IV = ENCIPHER( request-cipher-key, Bytes16( count ) )
Response entity-bodies are enciphered and deciphered as follows:
Encipher: <body-cipher> = ENCIPHER-MODE( response-cipher-key, IV, <body-plain> ) Decipher: <body-plain> = DECIPHER-MODE( response-cipher-key, IV, <body-cipher> ) where: IV = ENCIPHER( request-cipher-key, Bytes16( count ) )
The following are defined and apply to both requests and responses:
request-cipher-key
and response-cipher-key
are as derived in the section Cipher Keys.count
is the numerical value implied by the count
directive of the message being enciphered/deciphered.Bytes16(x)
is the value x
encoded with leading zeros in exactly 16 bytes, most
significant bits first, most significant byte first.ENCIPHER(k,b)
is the block enciphering function employing this specification's Block Cipher, using key k
, applied to input block b
.
Lengths are as follows: k
is 32 bytes, and b
is 16 bytes.ENCIPHER-MODE(k,iv,t)
is the chained enciphering function employing this specification's Block Cipher Mode, using key k
, initialization vector
iv
, applied to input text t
. Lengths are as follows: k
is 32 bytes,
n
is 16 bytes, t
is of arbitrary length.DECIPHER-MODE(k,iv,t)
is the chained deciphering function employing this specification's Block Cipher Mode, using key k
, initialization vector
iv
, applied to input text t
. Lengths are as follows: k
is 32 bytes,
n
is 16 bytes, t
is of arbitrary length.<body-plain>
is the plaintext bytes of the message entity-body, as manifest after all
encoding declared in the Content-Encoding [HTTP][ 14.11] header are applied.<body-cipher>
is the ciphertext bytes of the message entity-body, as manifest before
any encodings declared in the Transfer-Encoding [HTTP][ 14.41] header are applied.Validity conditions are given in this section for all protocol messages. Messages MUST satisfy all their respective conditions. The conditions are presented in suggested processing order determined by their increasing computational burden. The failure of any condition should immediately cause processing to terminate and the message to be discarded.
An initialization request message MUST meet all the following conditions to be considered valid by the responder that receives it:
url
directive satisfies its equivalence condition.dh
directive meets these conditions:
dh > 1
dh < p
dh ^ q MOD p = 1
p
and q
are from the Diffie-Hellman group indicated by the accompanying
group
directive.
certificate
directive, if present and if considered by
the responder, provides a public key that is valid according to the Public Key Algorithm specification, notably regarding minimum key size.certificate
directive, if present and if considered by
the responder, satisfies locally determined validation constraints, typically with respect to installed certification
authority root certificates.A initialization response message MUST meet all the following conditions to be considered valid by the requester that receives it:
dh
directive meets these conditions:
dh > 1
dh < p
dh ^ q MOD p = 1
p
and q
are from the Diffie-Hellman group indicated by the group
directive in the initialization
request.
certificate
directive, if present and if considered by
the requester, provides a public key that is valid according to the Public Key Algorithm specification, notably regarding minimum key size.certificate
directive, if present and if considered by
the requester, satisfies locally determined validation constraints, typically with respect to installed certification
authority root certificates.signature
directive value is valid. See signature
section for details of the validation procedure.A continuation request message MUST meet all the following conditions to be considered valid by the responder that receives it:
token
directive references an existing shared secret
arrangement.url
directive satisfies its equivalence condition.count
directive satisfies its uniqueness conditions.mac
directive's value equals the result of the re-computation
over the message, using the request MAC key
indexed by the
token
directive.digest
directive is present, its value equals the result
of hashing the entity-body according to this specification's Hash
Algorithm.A request that fails validation SHOULD cause the responder to flush all state associated with the shared secret
arrangement indexed by the token
directive, notably the MAC keys and Cipher keys.
A continuation response message MUST meet all the following conditions to be considered valid by the requester that receives it:
count
directive satisfies the sequence and uniqueness
conditions.mac
directive's value equals the result of the re-computation
over the message, using the response MAC key indexed by the token
stated in the associated request.digest
directive is present, its value equals the result
of hashing the entity-body according to this specification's Hash
Algorithm.A response that fails validation SHOULD cause the requester to flush all state associated with the shared secret
arrangement indexed by the token
directive in the associated request,
notably the MAC keys and Cipher keys.
Implementers should be aware of how authenticated transactions interact with proxy caches. The HTTP/1.1 [HTTP] [ 14.8] specifies that when a shared cache has received a request containing an Authorization header and a response from relaying that request, it MUST NOT return that response as a reply to any other request.
Note also that whereas the HTTP/1.1 specification presents three exceptions to this rule, none of these exceptions are applicable to the authentication scheme here described. This is a result of the per-message uniqueness constraints introduced by various protocol directives.
Consequently, to make the non-cacheability of messages explicit the Expires
response header [HTTP][ 14.21] MUST be set by the responder to the current system clock time, during the preparation of a response's
"WWW-Authenticate: httpsec/1.0 continue
" header directives. This is necessary for subsequent response validation, as the value of the Expires
response header features in the computation of mac
directives.
Also, the requirement that the no-transform
directive [HTTP][
14.9.5] MUST be set in a
mandatory Cache-Control response header [HTTP][ 14.9]
enforces specific modification constraints on transparent proxies that apply to certain headers - see [HTTP][ 13.5.2].
This entire specification discusses a secure authentication system that protects HTTP messages transmitted across an untrusted network.
Normative references:
Stephan Fowler
secarta.com
Ferroners' House
Shaftesbury Place
London EC2Y 8AA
T +44 20 7796 2527
F +44 20 7796 3539
Email: stephan.fowler@secarta.com


The story of my first trip begins with Incubus. Me and several of my closest friends traveled to Cedar Rapids IA to experience Incubus live in concert. We had made all the usual accomodations including a quad of shrooms to be taken after the concert. The ride down was long and painfully crowded but knowing what we had in store for us made the trip memorable none the less. Arriving at the concert venue we unloaded our gear and went to our hotel room which was directly connected to the arena. One of my older friends in the group decided he couldn't wait for the concert to be over and took his eighth of shrooms before the rest of us.
At the concert we met up with more friends who had rode up seperately, being non drug users they immediatly noticed the differece in our mutual friends antics. This however was immediately surpassed by the first notes of the concert. The show was incredible and the mutual feeling of everyone was one of sheer delight and happiness.  This outburst was soon followed by many hugs from him which were not overwhelmingly approved of on account of his sweaty stench.
Back at the room me and my two friends who have been padres since kindergarten prepared ourselves for the trip. There were alot of people in the room including ones who didn't approve of such actions so the ingestation was kept at a low profile. I caught my self questioning whether or not I should go through with this on account that we were in a hotel 12 stories up with heavy security outside. These thoughts however were soon removed and I gladly shared an eighth with my one of my friends, being a first timer and slightly nervous I thought it was best to just take half an eighth and see were that got me. Well it got me beyond what I thought was possible and more.
Having forgotten about hall security me and a couple others ventured into the halls of the luxurious hotel, and we ended up in the chairs which were next to the main elevators. There were people walking and talking everywhere and we delighted ourselves with conversing with some guys that were a couple rooms down from us. This was approx. 15 min. after taking the shrooms and I found myself staring at the celing light. It seemed to be getting closer and closer to me and I looked around to see if anyone else was noticing. Seeing that everyone was still in deep conversation I returned to the light. After about 10 minutes of staring at the large orbe on the ceiling I became aware of a bright light in my face and a man standing over me.
I quickly and quite rudly told the man to get the light out of my face and began swinging my hand at him trying to tell him to get away. After what seemed like ages the light turned off and the man walked away. Thinking nothing of the experiece I walked into a waiting elevator with a my friends and sat on the ground. As soon as the doors closed I was bombarded by what seemed like hundreds of questions and laughs. I quickly found out that it had been a Cedar Rapids police officer that had been shining a light in my face.
There was no way that he could have not know that there was something wrong with me. My pupils were the size of quarters and I was incoherantly muttering to him to get the light out of my face. When informed that I had had a close encounter with the law I began to freak out and I was sure that he had to be waiting for me where ever we were going so I told everyone that we needed to go back to the room as soon as possible and that I was not to leave there until the next moring. Its still hard to tell that part of the story and the fear of the moment will probably be with me forever.
After returning to the room and locking the door multiple times I began to feel at ease and became almost giddy at what was in store for me. Everyone that was along had found themselves back in the room and thats when everything started to click. All the conversations I had were so in depth and everything I said seemed to come out so easily. I felt that everything was correct and that the situation that I was in was exactly how I wanted to feel for the rest of my life. It was around this time, about an hour into the trip, that I made contact with what I refered to as Heidi. Heidi wasn't a person, well she was, but she wasn't in the room.
It was the name that was sewed into a purple bag that was sitting on the hotel room desk. My friend had bought it at a rummage sale a few weeks prior and brought it along to carry his stuff in.  For some reason I was completely obsessed with this configuration of colors and shapes. I couldn't take my eyes off of it for a good half hour and through out the night my eyes were averted to it at least 3 or 4 times every 10 minutes or so. It was the most amazing thing I have and probably ever will see. Aside from heidi the walls were teeming with what seemed to be slithering jungle vines. These were not a threat to me and when ever I became bored with my company I averted my attention to the ceiling to entertain my self.
It was about 4 hours into my trip when I began to feel that I was losing my high. But this feeling was soon interuppted by what felt like the peaking of my high. I was at my lowest low's and then I would be shot up to my highest highs. The diffrence between was massive but every up and down I enjoyed it more and more. About 5 hours in I was still tripping balls. It was about 2:30 in the moring and I thought it was safe enough for me to venture outside for some fresh air. Me and one of my friends to the long walk and ended up out in front of the hotel. The street was completely packed with cars and I thought this was strange being it so late at night so I turned to my friend to ask him about it.
I about screamed at what I saw. My buddies face had turned a deep jungle green color. I didn't know what to say so I turned around and all the traffic was gone. There was absolutly not a car to be seen. This obviously gave me a start but I was soon soothed by the simutanious blinking of all the stop lights. The colors red, yellow, and green were blinking everywhere all together in a harmony which seemed to be incredible music in absolute silence.
After enjoying the light display on the street we returned to the room. My friends face was back to normal and I was feeling that trip was coming to a close. The cracks on the steet from our room window seemed to stretch for miles into the rising sun and the guysfromnextdoorhad exited after an extremely insane outburst from one of my conpanions who had enough of their stories of fights, chicks, and beer. All of us being pot heads who avoid confrontation at all times simply agreed with our friend and told the invaders to leave before the situation got out of hand. I cheerily shut the door behind them and spent the last remaining moments of my trip watching the sun rise over the flat land of Iowa occasionaly sipping on my coffee and reading a news paper that I had found outside my door. It was a night that I would never forget and that I hope I have plenty more of in the future.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


magneticalc.VispyCanvas.VispyCanvas(scene.SceneCanvas)
class documentationmagneticalc.VispyCanvas
(View In Hierarchy)
VispyCanvas class.
| Class Variable | DefaultFontFace | Undocumented |
| Class Variable | DefaultFontSize | Undocumented |
| Class Variable | DebugVisuals | Undocumented |
| Class Variable | White | Undocumented |
| Class Variable | Black | Undocumented |
| Class Variable | ArrowHeadSizeMultiply | Undocumented |
| Class Variable | ArrowHeadSizeExponent | Undocumented |
| Class Variable | WirePointSize | Undocumented |
| Class Variable | WirePointSelectedSize | Undocumented |
| Class Variable | WirePointSelectedColor | Undocumented |
| Class Variable | ScaleFactorMin | Undocumented |
| Class Variable | ScaleFactorMax | Undocumented |
| Class Variable | MagnitudeLimit | Undocumented |
| Class Variable | MagnitudePrecision | Undocumented |
| Method | __init__ | Initialize VisPy canvas. |
| Instance Variable | gui | Undocumented |
| Instance Variable | view_main | Undocumented |
| Instance Variable | view_text | Undocumented |
| Instance Variable | visual_coordinate_system | Undocumented |
| Instance Variable | font_manager | Undocumented |
| Instance Variable | visual_perspective_info | Undocumented |
| Instance Variable | visual_field_labels | Undocumented |
| Instance Variable | visual_wire_segments | Undocumented |
| Instance Variable | visual_wire_points_selected | Undocumented |
| Instance Variable | visual_wire_points_sliced | Undocumented |
| Instance Variable | visual_field_points | Undocumented |
| Instance Variable | visual_field_arrow_lines | Undocumented |
| Instance Variable | visual_field_arrow_heads | Undocumented |
| Instance Variable | foreground | Undocumented |
| Instance Variable | background | Undocumented |
| Instance Variable | initializing | Undocumented |
| Instance Variable | visual_startup_info | Undocumented |
| Instance Variable | signals_blocked | Undocumented |
| Instance Variable | super_perspective_changed | Undocumented |
| Method | update_color_scheme | Updates the color scheme. |
| Instance Variable | bgcolor | Undocumented |
| Method | set_visible | Sets some visual's visibility. |
| Method | load_perspective | Loads perspective from configuration. |
| Method | on_perspective_changed | Handles a change of perspective. |
| Method | redraw_perspective_info | Re-draws the perspective info text. |
| Method | redraw | Re-draws the entire scene. |
| Method | redraw_wire_segments | Re-draws wire segments. |
| Method | redraw_wire_points_sliced | Re-draws sliced wire points. |
| Method | redraw_wire_points_selected | Re-draws selected wire base points. |
| Method | redraw_field_arrows | Re-draws field arrows. |
| Method | redraw_field_points | Re-draws field points. |
| Method | create_field_labels | Creates field labels. |
| Method | delete_field_labels | Deletes the field labels. |
| Method | redraw_field_labels | Re-draws field labels. |
| Method | save_image | Saves the currently displayed scene to PNG file. |
Sets some visual's visibility.
| Parameters | visual | Visual |
| is_visible | Visibility |


{% extends "06-base.html"%} {% block content %}
We're excited to have you audition for our band
This will redirect to a thank you page.
Please note, we're just puppies, so we haven't learned how to save your information yet!


If this is you, please, follow this link
[[hostUrl]]auth/resetPassword?key=[[user.apiKey]]
Within 1 hour!
https://github.com/mywebclass/mwc_plugin_welcome


We'll help you prepare your travel arrangements.
We hope you enjoy this website and consider spending some time at our fantastic resort!
"Travelling here was a true pleasure in it's own right!"


Classes
The following classes are available globally.
-
See morePromise
subclass that is initialized with other promises to complete.CombinePromise
firesfailure
then
orcomplete
after all of these promises are fullfilled/rejected. If one or more of the waiting promises are rejected, thisCombinedPromnise
is rejected. Promises can only be used with oneCombinedPromise
.Declaration
Swift
public class CombinePromise: Promise<[Any]>
-
Class that represents a promise/future. Once created a
See morePromise
object can be returned immediately and eithercomplete
then
orfailure
will be called later when an async tasks passes in a fullfillment value or rejection error.Declaration
Swift
public class Promise<Wrapped>: Promisable, ThenPromiseable


|
| enum | Application {
Application::None,
Application::Application,
Application::SystemApplet,
Application::LibraryApplet,
Application::OverlayApplet,
Application::SystemApplication
} |
| |
| enum | Memory {
Memory::Unmapped = 0x0,
Memory::Io = 0x1,
Memory::Normal = 0x2,
Memory::CodeStatic = 0x3,
Memory::CodeMutable = 0x4,
Memory::HeapMem = 0x5,
Memory::SharedMem = 0x6,
Memory::WeirdMappedMem = 0x7,
Memory::ModuleCodeStatic = 0x8,
Memory::ModuleCodeMutable = 0x9,
Memory::IPCBuffer0 = 0xa,
Memory::MappedMemory = 0xb,
Memory::ThreadLocal = 0xc,
Memory::TransferMemIsolated = 0xd,
Memory::TransferMem = 0xe,
Memory::ProcessMem = 0xf,
Memory::Reserved = 0x10,
Memory::IPCBuffer1 = 0x11,
Memory::IPCBuffer3 = 0x12,
Memory::KernelStack = 0x13,
Memory::CodeReadOnly = 0x14,
Memory::CodeWritable = 0x15
} |
| |
| enum | MemoryState {
MemoryState::Type = 0xff,
MemoryState::PermChangeAllowed = BIO_BITMASK(8),
MemoryState::ForceRwByDebugSyscalls = BIO_BITMASK(9),
MemoryState::IPCSendAllowedT0 = BIO_BITMASK(10),
MemoryState::IPCSendAllowedT3 = BIO_BITMASK(11),
MemoryState::IPCSendAllowedT1 = BIO_BITMASK(12),
MemoryState::ProcessPermChangeAllowed = BIO_BITMASK(14),
MemoryState::MapAllowed = BIO_BITMASK(15),
MemoryState::UnmapProcessCodeMemAllowed = BIO_BITMASK(16),
MemoryState::TransferMemAllowed = BIO_BITMASK(17),
MemoryState::QueryPAddrAllowed = BIO_BITMASK(18),
MemoryState::MapDeviceAllowed = BIO_BITMASK(19),
MemoryState::MapDeviceAlignedAllowed = BIO_BITMASK(20),
MemoryState::IPCBufferAllowed = BIO_BITMASK(21),
MemoryState::IsPoolAllocated = BIO_BITMASK(22),
MemoryState::IsRefCounted = IsPoolAllocated,
MemoryState::MapProcessAllowed = BIO_BITMASK(23),
MemoryState::AttrChangeAllowed = BIO_BITMASK(24),
MemoryState::CodeMemAllowed = BIO_BITMASK(25)
} |
| |
| enum | MemoryAttribute { MemoryAttribute::IsBorrowed = BIO_BITMASK(0),
MemoryAttribute::IsIPCMapped = BIO_BITMASK(1),
MemoryAttribute::IsDeviceMapped = BIO_BITMASK(2),
MemoryAttribute::IsUncached = BIO_BITMASK(3)
} |
| |
| enum | Permission {
Permission::NoPermission = 0,
Permission::Read = BIO_BITMASK(0),
Permission::Write = BIO_BITMASK(1),
Permission::Execute = BIO_BITMASK(2),
Permission::ReadWrite = (Read | Write),
Permission::ReadExecute = (Read | Execute),
Permission::DontCare = BIO_BITMASK(28)
} |
| |
| enum | CodeMapOperation { CodeMapOperation::MapOwner = 0,
CodeMapOperation::MapSlave = 1,
CodeMapOperation::UnmapOwner = 2,
CodeMapOperation::UnmapSlave = 3
} |
| |
| enum | LimitableResource {
LimitableResource::Memory = 0,
LimitableResource::Threads = 1,
LimitableResource::Events = 2,
LimitableResource::TransferMemories = 3,
LimitableResource::Sessions = 4
} |
| |
| enum | ProcessInfo { ProcessInfo::ProcessState = 0
} |
| |
| enum | ProcessState {
ProcessState::Created = 0,
ProcessState::DebugAttached = 1,
ProcessState::DebugDetached = 2,
ProcessState::Crashed = 3,
ProcessState::Running = 4,
ProcessState::Exiting = 5,
ProcessState::Exited = 6,
ProcessState::DebugSuspended = 7
} |
| |
| enum | DebugThreadParameter {
DebugThreadParameter::ActualPriority = 0,
DebugThreadParameter::State = 1,
DebugThreadParameter::IdealCore = 2,
DebugThreadParameter::CurrentCore = 3,
DebugThreadParameter::CoreMask = 4
} |
| |


Custom POI Search plug-in Python code sample¶
The Custom POI Search
search plug-in sample code uses the GEE
Python search module to query the Google Places database
(www.google.com) via the Google Places
API. It demonstrates
how to construct and query an external database based on a URL
search string, extract geometries from the result, associate
various styles with them, and return the response back to the
client.
You can find the two Python files for the POI Search
plug-in
in the following location:
/opt/google/gehttpd/wsgi-bin/search/plugin/custom_POI_search_app.py
/opt/google/gehttpd/wsgi-bin/search/plugin/custom_POI_search_handler.py
In this Python module, an implementation has been provided to access the Google Places database, format the results, and send the response in XML or JSON as per the requirement. Valid inputs are:
location=lat,lng
radius = 10(in miles)
key = <server key required to access the Google Places database>
Further information about obtaining a server key is documented at:


AFCON 2021 Qualifiers: President Akufo-Addo eulogizes Black Stars after South Africa humbling
President of Ghana Nana Akufo-Addo has lauded the performance of the Black Stars in their 2-0 victory over South Africa in the opening fixture of the 2021 Africa Cup of Nations.
The senior national team brought massive smiles to the faces of Ghanaians as they commenced the 2021 Africa Cup of Nations qualifiers with a comfortable 2-0 win over South Africa at the Cape Coast Stadium on Thursday evening.
The Black Stars had a brilliant start to the game where they enjoyed the lion share of possession. Thomas Partey opened the scoring with a beauty, firing from long range in the 35th minute.
The visitors didn’t coil in and forced their way through for an equalizer but the back of the net eluded them, even though they played much better until the break.
Ghana returned from the recess a much more stronger side and once again dominated play. Kudus Mohammed made his debut, one that he won’t forget anytime soon. He replaced Alfred Duncan in the 61st minute.
The youngster took his chance very well after a solo effort and wrote his name in gold with a beautiful curler in the 80th minute to win it for the Stars. First job done in the qualifiers.
President Akufo-Addo took to twitter to hail the team's display in the match.
?s=21
The Black Stars will face Sao Tome and Principe on Monday.


vanilla primes
Simple vanilla JavaScript application that finds first N prime numbers
Find
primes.
index
prime


{% extends 'base.html' %} {% load static %} {% block contenido %}
Peek other reviews made by the user on tripadvisor.com
Sentiment


September is beach season here in the Bay Area, and it looks like our release earlier this month got caught in a wash cycle. So, we’ve made a point release.
See below for details on the util-slf4j-api
dependency fix for the reason
why we decided to do a point release.
Finagle 18.9.1, Finatra 18.9.1, Scrooge 18.9.1, TwitterServer 18.9.1, and Util 18.9.1.
finagle-base-http: DefaultHeaderMap
now validates HTTP Header names and
values in add
and set
. addUnsafe
and setUnsafe
have been created to
allow adding and setting headers without validation. 3454f95d
finagle-core: Remove slow host detection from ThresholdFailureDetector
.
c05f5832
finagle-core: When Finagle would exhaust a retry budget with an exception that was
not a FailureFlags
, previously it would wrap that exception with a non-retryable
failure. This lead to surprising behavior for users. Those exceptions will no longer
be wrapped. 4ece3d2a
finagle-http: The finagle HTTP clients and servers now consider a Retry-After: 0
header to be a retryable nack. Servers will set this header when the response is
a retryable failure, and clients will interpret responses with this header as a
Failure.RetryableNackFailure. 3c3fedc6
No Changes


Head over to Extension Shortcut Settings to adjust your shortcut
TIP: CTRL+Enter, CMD+Enter, SHIFT+Enter open up selected in a new tab
If you have any issues with stuff missing, type "refresh metadata" in the navigator, hit enter, then refresh the page and try again.
Submit any issues on github :)


{% load text_filters %} {% load posts %} {% load comments %} {% if comment.author_id in muted_user_ids %} {% include "comments/types/muted.html" with comment=comment replies=replies %} {% else %}


{% extends "base.html" %} {% block outdated %} You are viewing an old or unreleased version. Click here to go to latest release. {% endblock %}


Pizza Hut
Please enter your name:
Please choose the size of pizza
size of pizza
small
orignal
Large
Please select your topping
Just cheese
icecream
aligator
wholefish
more pizza
Proceed to Checkout


Invalid username or password
You have been logout
Don't have account? Sign up
You already have account? Log in


nips nips2012 nips2012-245 nips2012-245-reference knowledge-graph by maker-knowledge-mining
Source: pdf
Author: Jaedeug Choi, Kee-eung Kim
Abstract: We present a nonparametric Bayesian approach to inverse reinforcement learning (IRL) for multiple reward functions. Most previous IRL algorithms assume that the behaviour data is obtained from an agent who is optimizing a single reward function, but this assumption is hard to guarantee in practice. Our approach is based on integrating the Dirichlet process mixture model into Bayesian IRL. We provide an efﬁcient Metropolis-Hastings sampling algorithm utilizing the gradient of the posterior to estimate the underlying reward functions, and demonstrate that our approach outperforms previous ones via experiments on a number of problem domains. 1
[1] Stuart Russell. Learning agents for uncertain environments (extended abstract). In Proceedings of COLT, 1998.
[2] Andrew Y. Ng and Stuart Russell. Algorithms for inverse reinforcement learning. In Proceedings of ICML, 2000.
[3] Gergely Neu and Csaba Szepesv´ ri. Apprenticeship learning using inverse reinforcement learning and a gradient methods. In Proceedings of UAI, 2007.
[4] Deepak Ramachandran and Eyal Amir. Bayesian inverse reinforcement learning. In Proceedings of IJCAI, 2007.
[5] Brian D. Ziebart, Andrew L. Maas, J. Andrew Bagnell, and Anind K. Dey. Maximum entropy inverse reinforcement learning. In Proceedings of AAAI, 2008.
[6] Brian D. Ziebart, Andrew L. Maas, Anind K. Dey, and J. Andrew Bagnell. Navigate like a cabbie: probabilistic reasoning from observed context-aware behavior. In Proceedings of the international conference on Ubiquitous computing, 2008.
[7] Zeynep Erkin, Matthew D. Bailey, Lisa M. Maillart, Andrew J. Schaefer, and Mark S. Roberts. Eliciting patients’ revealed preferences: An inverse Markov decision process approach. Decision Analysis, 7(4), 2010.
[8] Senthilkumar Chandramohan, Matthieu Geist, Fabrice Lefevre, and Olivier Pietquin. User simulation in dialogue systems using inverse reinforcement learning. In Proceedings of Interspeech, 2011.
[9] Christos Dimitrakakis and Constantin A. Rothkopf. Bayesian multitask inverse reinforcement learning. In Proceedings of the European Workshop on Reinforcement Learning, 2011.
[10] Monica Babes-Vroman, Vukosi Marivate, Kaushik Subramanian, and Michael Littman. Apprenticeship ¸ learning about multiple intentions. In Proceedings of ICML, 2011.
[11] Peter Dayan and Geoffrey E. Hinton. Using expectation-maximization for reinforcement learning. Neural Computation, 9(2), 1997.
[12] Jaedeug Choi and Kee-Eung Kim. MAP inference for Bayesian inverse reinforcement learning. In Proceedings of NIPS, 2011.
[13] Radford M. Neal. Markov chain sampling methods for Dirichlet process mixture models. Journal of Computational and Graphical Statistics, 9(2), 2000.
[14] Gareth O. Roberts and Jeffrey S. Rosenthal. Optimal scaling of discrete approximations to langevin diffusions. Journal of the Royal Statistical Society: Series B (Statistical Methodology), 60(1), 1998.
[15] Pieter Abbeel and Andrew Y. Ng. Apprenticeship learning via inverse reinforcement learning. In Proceedings of ICML, 2004.
[16] Abdeslam Boularias, Jens Kober, and Jan Peters. Relative entropy inverse reinforcement learning. In Proceedings of AISTATS, 2011. 9


This page does not exist yet.
You can contribute this page by forking the repository at: https://github.com/ronreiter/interactive-tutorials.
{% extends "base.html" %} {% block page_title %}Page not found{% endblock %} {% block content %}
You can contribute this page by forking the repository at: https://github.com/ronreiter/interactive-tutorials.


This is an Alpha release of Google Cloud Search. This feature is not covered by any SLA or deprecation policy and may be subject to backward-incompatible changes.
The object returned from gcloud.search
gives you complete access to store your documents and search your indexes.
To learn more about Search, see What is Google Cloud Search? If you are not a tester, this documentation is unavailable.


JavaScript is disabled on your browser.
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes
A
C
E
F
G
H
I
L
N
O
P
S
V
A
absent()
- Static method in class com.github.davidmoten.guavamini.
Optional
addAll(Collection<T>, Iterator<? extends T>)
- Static method in class com.github.davidmoten.guavamini.
Iterators
Adds all elements in
iterator
to
collection
.
C
checkArgument(boolean, String)
- Static method in class com.github.davidmoten.guavamini.
Preconditions
checkArgument(boolean)
- Static method in class com.github.davidmoten.guavamini.
Preconditions
checkNotNull(Object)
- Static method in class com.github.davidmoten.guavamini.
Preconditions
checkNotNull(Object, String)
- Static method in class com.github.davidmoten.guavamini.
Preconditions
Collections2
- Class in
com.github.davidmoten.guavamini
com.github.davidmoten.guavamini
- package com.github.davidmoten.guavamini
com.github.davidmoten.guavamini.annotations
- package com.github.davidmoten.guavamini.annotations
E
equal(Object, Object)
- Static method in class com.github.davidmoten.guavamini.
Objects
F
fromNullable(T)
- Static method in class com.github.davidmoten.guavamini.
Optional
G
get()
- Method in class com.github.davidmoten.guavamini.
Optional
H
hashCode(Object...)
- Static method in class com.github.davidmoten.guavamini.
Objects
I
isPresent()
- Method in class com.github.davidmoten.guavamini.
Optional
Iterators
- Class in
com.github.davidmoten.guavamini
L
Lists
- Class in
com.github.davidmoten.guavamini
N
newArrayList(E...)
- Static method in class com.github.davidmoten.guavamini.
Lists
newArrayList()
- Static method in class com.github.davidmoten.guavamini.
Lists
newArrayList(Iterable<? extends E>)
- Static method in class com.github.davidmoten.guavamini.
Lists
newArrayList(Iterator<? extends E>)
- Static method in class com.github.davidmoten.guavamini.
Lists
newHashSet(E...)
- Static method in class com.github.davidmoten.guavamini.
Sets
newHashSet(Iterable<? extends E>)
- Static method in class com.github.davidmoten.guavamini.
Sets
newHashSet(Iterator<? extends E>)
- Static method in class com.github.davidmoten.guavamini.
Sets
newHashSet()
- Static method in class com.github.davidmoten.guavamini.
Sets
newHashSetWithExpectedSize(int)
- Static method in class com.github.davidmoten.guavamini.
Sets
NotPresentException()
- Constructor for exception com.github.davidmoten.guavamini.
Optional.NotPresentException
O
Objects
- Class in
com.github.davidmoten.guavamini
of(T)
- Static method in class com.github.davidmoten.guavamini.
Optional
Optional
<
T
> - Class in
com.github.davidmoten.guavamini
Optional.NotPresentException
- Exception in
com.github.davidmoten.guavamini
or(T)
- Method in class com.github.davidmoten.guavamini.
Optional
P
Preconditions
- Class in
com.github.davidmoten.guavamini
S
Sets
- Class in
com.github.davidmoten.guavamini
V
VisibleForTesting
- Annotation Type in
com.github.davidmoten.guavamini.annotations
Annotates a program element that exists, or is more widely visible than otherwise necessary, only for use in test code.
A
C
E
F
G
H
I
L
N
O
P
S
V
Skip navigation links
Overview
Package
Class
Use
Tree
Deprecated
Index
Help
Prev
Next
Frames
No Frames
All Classes
Copyright © 2013–2016. All rights reserved.


{% extends "layouts/base.html" %} {% block title %} Connected User {% endblock %} {% block stylesheets %} {% endblock stylesheets %} {% block content %}
Home Connected Users Delete User
Are you sure you want to delete this User?


Arithmatic and geometric Progressions are 2 of the well known progressions in maths.
Arithmatic progression(AP) is a set in which the difference between 2 numbers in constant. for e.g., 1, 3, 5, 7, 9 .... In this series the difference between 2 numbers is 2.
The task here is very simple indeed.
You will be given the 3rd term, 3rd last term and the sum of the series. You need print length of the series & the series.
First line will contain a number indicating the number of test cases.
Each of the following t lines will have 3 number '3term' ,'3Lastterm' and 'sum'
3term - is the 3rd term in of the series and
3Lastterm - is the 3rd term in of the series and
sum - is the sum of the series.
For each input of the test case, you need to print 2 lines.
First line should have 1 value - the number of terms in the series.
2nd line of the output should print the series numbers separated by single space.
Input: 1 3 8 55 Output: 10 1 2 3 4 5 6 7 8 9 10
NOTE:


Allows the inclusion of new attributes with a fairly standard way of initialization.
More...
|
|
| name |
| |
|
| AttributeString |
| |
|
| boolean |
| |
|
| DefaultAttribute |
| |
Allows the inclusion of new attributes with a fairly standard way of initialization.
| def attributes.Attribute.__init__ |
( |
|
self, |
|
|
|
name, |
|
|
|
DefaultAttribute = False |
|
) |
| |
Class constructor.
You can pass a default attribute to your object in the event that there is a syntax error within the autoinit config file. This allows for continued execution, where there could have been potentially runtime errors.
| def attributes.Attribute.get_attribute |
( |
|
self | ) |
|
- Returns
- returns the variable AttributeString
| def attributes.Attribute.get_boolean |
( |
|
self | ) |
|
- Returns
- returns the variable boolean
| def attributes.Attribute.get_name |
( |
|
self | ) |
|
- Returns
- returns the name of the Attribute object
| def attributes.Attribute.initialize_attribute |
( |
|
self, |
|
|
|
string |
|
) |
| |
Initializes the variable AttributeString.
This is the method that shouldd be called, instead of set_attribute
| def attributes.Attribute.set_attribute |
( |
|
self, |
|
|
|
attribute |
|
) |
| |
sets the variable AttributeString to the passed variable attribute
This method should probably never be called unless by the initialize_attribute method.
- Parameters
-
| attribute | can be any type of variable |
| def attributes.Attribute.set_boolean |
( |
|
self, |
|
|
|
boolean |
|
) |
| |
sets the object variable boolean to the passed boolean variable
- Parameters
-
| boolean | should be, as the name suggests, a boolean type. |
| def attributes.Attribute.set_to_default_attribute |
( |
|
self | ) |
|
sets the variable AttributeString to the variable DefaultAttribute
This method should never be called unless by the initialize_attribute method.
The documentation for this class was generated from the following file:


|
Backend:
Click to setup
|
Switch theme
Enter your name
Your name
Submit
Create or Enter a Room
Room name
Room password
Words per player (New room)
Seconds per turn (New room)
Create room
Enter room
Reconnect
Find Room
No rooms found
Reload rooms
N/A
Start new game
Word Generation
Submit words
Game -
Others
turn
Last guessed word:
took
s
author:
Game - My turn
Reroll situp
Start turn
Current word:
Word done
Done words:
Last guessed word:
took
s
author:
The game has ended.
Find new round
Log:
save


{% extends 'main/base.html' %} {% block title %}Thar she fails!{% endblock %} {% block current %}error{% endblock %} {% block content %}
Sorry, I'm currently having difficulty contacting Twitter, please try again or give the whale a little while to rest up.
{% endblock %} {% block footer %} Based on the original Fail Whale by @YiyingLu. {% endblock %}


|
|
Plugins - Modules
|
To keep The Uniform Server footprint as small as possible a range of modules (plugins) is provided. These are self-extracting 7z archives. Installing a module requires nothing more than double clicking on the module (plugin) file.
The extraction process creates folders and copies files to appropriate location within the server architecture. Generally plugins are automatically detected and configured. However certain plugins require specific configuration, details are provided in the accompanying documentation with each plugin.
Installing plugins
Installing is a misnomer! Nothing is installed to your PCs registry all files are extracted to their appropriate location within the UniServer folder structure.
The extraction procedure unless stated in a plugins accompanying documentation is identical for all plugins, proceed as follows:
- Download the desired plugin – see list below for available plugins.
- Save to folder UniServerZ.
- If running, stop Uniform Server (Apache and MySQL) from UniController
- If running, exit UniController.
- Double click on the above installation file saved in UniServerZ folder. This runs the self-extracting archive.
- If prompted allow overwriting of existing files.
- If you wish; delete the installation file, it is no longer required.
Note: Each plugin contains a read-me file providing any additional instructions this is located in folder UniServerZ.
List of plugins
The following lists currently (27-1-2017) available plugins:
Default - (PHP installed as an Apache module) for details refer to Quick Start Guide page .
| Plugin Name |
Component Name |
Size |
Description |
| ZeroXIII_adminer_4_2_2.exe |
Adminer 4.2.2 |
0.38/0.45 MB |
MySQL admin alternative |
| ZeroXIII_apache_2_4_25_j.exe |
Apache 2.4.25 |
2.9/11.3 MB |
Apache server built with OpenSSL/1.0.2j |
| ZeroXIII_Controller_2_2_0.exe |
UniController 2.2.0 |
1.92/5.1 MB |
Server controller - Required main component - Added support for PHP 7 |
| ZeroXIII_documentation_1_0_0.exe |
Manual 1.0.0 |
2.39/3.33 MB |
UniServer-Zero documentation. HTML manual |
| ZeroXIII_filezilla_server_0_9_46.exe |
FZ server 0.9.46 UniFzController 1.0.1 |
1.79/4.60 MB |
Portable: FileZilla Server V-0.9.46 with OpenSSL <IP_ADDRESS> libraries. |
| ZeroXIII_mariadb_5_5_54.exe |
MariaDB 5.5.54 |
3.35/53.3 MB |
MariaDB server 5.5 Drop in replacement for MySQL 5.5 server. |
| ZeroXIII_mariadb_10_0_29.exe |
MariaDB 10.0.29 |
3.85/50.8 MB |
MariaDB server 10.0.0 Drop in replacement for MySQL 5.6 server. |
| ZeroXIII_mysql_5_5_54.exe |
MySQL 5.5.54 |
3.02/26.0 MB |
MySQL server 5.5 |
| ZeroXIII_mysql_5_6_35.exe |
MySQL 5.6.35 |
3.83/55.6 MB |
MySQL server 5.6 |
| ZeroXIII_mysqlautoback_1_0_0.exe |
UniDbBackup 1.0.0 |
0.91/2.42 MB |
Automatically create MySQL backups, FTP and E-Mail notification. |
| ZeroXIII_palemoon_27_0_3.exe |
Pale Moon 27.0.3 |
23.7/37.4 MB |
Portable Pale Moon browser. Note support for Windows XP was dropped from version 25.0.0 onwards. Pale Moon 26.1.1 uses new Goanna-based web browser (forked from Firefox/Mozilla code). |
| ZeroXIII_pear_1_0_2.exe |
Pear go-pear 1.1.6 |
0.58/4.16 MB |
Pear and Pear frontend configured for portability. Fails with PHP 7.0.0. Other PHP plugins OK |
| ZeroXIII_php_5_3_29_j.exe |
PHP 5.3.29 |
14.1/57.3 MB |
PHP version built with OpenSSl 1.0.2j and additional extensions. |
| ZeroXIII_php_5_4_45_j.exe |
PHP 5.4.45 |
13.8/53.5 MB |
PHP version built with OpenSSl 1.0.2j and additional extensions. |
| ZeroXIII_php_5_5_38_j.exe |
PHP 5.5.38 |
13.9/54.2 MB |
PHP version built with OpenSSl 1.0.2j |
| ZeroXIII_php_5_6_30_j.exe |
PHP 5.6.30 |
14.1/54.9 MB |
PHP version built with OpenSSl 1.0.2j |
| ZeroXIII_php_7_0_15_j.exe |
PHP 7.0.15 |
13.7/51.7 MB |
PHP version built with OpenSSl 1.0.2j |
| ZeroXIII_php_7_1_1_j.exe |
PHP 7.1.1 |
13.4/52.2 MB |
PHP version built with OpenSSl 1.0.2j/td>
|
| ZeroXIII_phpmyadmin_4_4_15_10.exe |
phpMyAdmin <IP_ADDRESS> |
3.91/20.6 MB |
MySQL admin Note: Required for MySQL and MariaDB requirements. |
| ZeroXIII_phpmyadmin_4_6_6.exe |
phpMyAdmin 4.6.6 |
4.1/21.7 MB |
MySQL admin
|
| ZeroXIII_phpmybackuppro_2_5.exe |
phpMyBackupPro 2.5.0 |
0.26/0.63 MB |
phpMyBackupPro is a MySQL database backup tool written in PHP. |
| ZeroXIII_strawberry_perl_5_22_1_1.exe |
Strawberry Perl <IP_ADDRESS> |
8.15/46.1 MB |
Full portable Strawberry Perl |
| ZeroXIII_sypex_dumper_2_0_11.exe |
Sypex Dumper 2.0.11 |
0.24/0.32 MB |
Alternative to phpMyBackupPro database backup tool. |
| ZeroXIII_uniservice_2_2_0.exe |
UniService 2.2.0 |
0.62/1.69 MB |
Run servers as a service. |
Note 1: Size shows two values Compressed/Uncompressed
Note 2: You can use either one of two database servers MySQL or MariaDB. MariaDB is a drop in replacements for MySQL.
The controller makes no distinction between the two database servers; menu items and buttons reflect installed server.
Note 3: PHP skipped version 6! and went straight to version 7.
Module (Plugin) download information
Modules are downloable from SourceForge.
Pre-configured servers
Pre-configured servers are downloable from SourceForge.
--oOo--
|


Click me too -- Poof! -- gone with the wind!
Hey! Don't forget me! Poof-poof!


Google Pixel 4 has fixed camera auto white balance problem -
by Efe UdinRate this post
Google has released an update patch that fixes some of the automatic white balance issues on Pixel 4. These issues were spotted by multiple users sometime last month. The fix is part of the November security patch and has been pushed to all Pixel devices. However, the camera fix is only available for the latest models.
A few days ago, Reddit users noticed the Pixel 4 automatic white balance problem. The observation shows that it tends to deliberately correct strong colors. When taking a picture in a room with only a red light source, the phone turns the room yellow instead of red. A user took images of dark red cinema curtains. After the Pixel 4 camera processed the images, it looked very pale pink.
The problem seems to be due to the new machine learning-based automatic white balance algorithm from Google. This causes an abnormal image processing. According to analysis, machine learning is not completely reliable. When displayed as a completely red room, the machine learning system may not know how to handle it. Thus, it will attempt to eliminate red, so that the image has two other primary colors, blue and green. These colours combine together to produce a yellow image.
However, the latest update takes care of this issue. The Google Pixel 4 now correctly renders the red space to red.


The Inflector transforms words from singular to plural, class names to table names, modularized class names to ones without, and class names to foreign keys. The default inflections for pluralization, singularization, and uncountable words are kept in inflections.rb.
The Rails core team has stated patches for the inflections library will not be accepted in order to avoid breaking legacy applications which may be relying on errant inflections. If you discover an incorrect inflection and require it for your application or wish to define rules for languages other than English, please correct or add them yourself (explained below).
By default, camelize
converts strings to UpperCamelCase. If
the argument to camelize
is set to :lower
then
camelize
produces lowerCamelCase.
camelize
will also convert '/' to '::' which is useful for
converting paths to namespaces.
'active_model'.camelize # => "ActiveModel" 'active_model'.camelize(:lower) # => "activeModel" 'active_model/errors'.camelize # => "ActiveModel::Errors" 'active_model/errors'.camelize(:lower) # => "activeModel::Errors"
As a rule of thumb you can think of camelize
as the inverse of
underscore
, though there are cases where that does not hold:
'SSLError'.underscore.camelize # => "SslError"
# File lib/active_support/inflector/methods.rb, line 68 def camelize(term, uppercase_first_letter = true) string = term.to_s if uppercase_first_letter string = string.sub(/^[a-z\d]*/) { inflections.acronyms[$&] || $&.capitalize } else string = string.sub(/^(?:#{inflections.acronym_regex}(?=\b|[A-Z_])|\w)/) { $&.downcase } end string.gsub(/(?:_|(\/))([a-z\d]*)/) { "#{$1}#{inflections.acronyms[$2] || $2.capitalize}" }.gsub('/', '::') end
Create a class name from a plural table name like Rails does for table
names to models. Note that this returns a string and not a Class (To convert to an actual class follow
classify
with constantize
).
'egg_and_hams'.classify # => "EggAndHam" 'posts'.classify # => "Post"
Singular names are not handled correctly:
'business'.classify # => "Busines"
# File lib/active_support/inflector/methods.rb, line 150 def classify(table_name) # strip out any leading schema name camelize(singularize(table_name.to_s.sub(/.*\./, ''))) end
Tries to find a constant with the name specified in the argument string.
'Module'.constantize # => Module 'Test::Unit'.constantize # => Test::Unit
The name is assumed to be the one of a top-level constant, no matter whether it starts with “::” or not. No lexical context is taken into account:
C = 'outside' module M C = 'inside' C # => 'inside' 'C'.constantize # => 'outside', same as ::C end
NameError is raised when the name is not in CamelCase or the constant is unknown.
# File lib/active_support/inflector/methods.rb, line 219 def constantize(camel_cased_word) names = camel_cased_word.split('::') names.shift if names.empty? || names.first.empty? names.inject(Object) do |constant, name| if constant == Object constant.const_get(name) else candidate = constant.const_get(name) next candidate if constant.const_defined?(name, false) next candidate unless Object.const_defined?(name) # Go down the ancestors to check it it's owned # directly before we reach Object or the end of ancestors. constant = constant.ancestors.inject do |const, ancestor| break const if ancestor == Object break ancestor if ancestor.const_defined?(name, false) const end # owner is in Object, so raise constant.const_get(name, false) end end end
Replaces underscores with dashes in the string.
'puni_puni'.dasherize # => "puni-puni"
# File lib/active_support/inflector/methods.rb, line 158 def dasherize(underscored_word) underscored_word.tr('_', '-') end
Removes the rightmost segment from the constant expression in the string.
'Net::HTTP'.deconstantize # => "Net" '::Net::HTTP'.deconstantize # => "::Net" 'String'.deconstantize # => "" '::String'.deconstantize # => "" ''.deconstantize # => ""
See also demodulize
.
# File lib/active_support/inflector/methods.rb, line 186 def deconstantize(path) path.to_s[0...(path.rindex('::') || 0)] # implementation based on the one in facets' Module#spacename end
Removes the module part from the expression in the string.
'ActiveRecord::CoreExtensions::String::Inflections'.demodulize # => "Inflections" 'Inflections'.demodulize # => "Inflections"
See also deconstantize
.
# File lib/active_support/inflector/methods.rb, line 168 def demodulize(path) path = path.to_s if i = path.rindex('::') path[(i+2)..-1] else path end end
Creates a foreign key name from a class name.
separate_class_name_and_id_with_underscore
sets whether the
method should put ‘_’ between the name and ‘id’.
'Message'.foreign_key # => "message_id" 'Message'.foreign_key(false) # => "messageid" 'Admin::Post'.foreign_key # => "post_id"
# File lib/active_support/inflector/methods.rb, line 197 def foreign_key(class_name, separate_class_name_and_id_with_underscore = true) underscore(demodulize(class_name)) + (separate_class_name_and_id_with_underscore ? "_id" : "id") end
Capitalizes the first word and turns underscores into spaces and strips a
trailing “_id”, if any. Like titleize
, this is meant for
creating pretty output.
'employee_salary'.humanize # => "Employee salary" 'author_id'.humanize # => "Author"
# File lib/active_support/inflector/methods.rb, line 106 def humanize(lower_case_and_underscored_word) result = lower_case_and_underscored_word.to_s.dup inflections.humans.each { |(rule, replacement)| break if result.sub!(rule, replacement) } result.gsub!(/_id$/, "") result.tr!('_', ' ') result.gsub(/([a-z\d]*)/) { |match| "#{inflections.acronyms[match] || match.downcase}" }.gsub(/^\w/) { $&.upcase } end
Yields a singleton instance of Inflector::Inflections so you can
specify additional inflector rules. If passed an optional locale, rules for
other languages can be specified. If not specified, defaults to
:en
. Only rules for English are provided.
ActiveSupport::Inflector.inflections(:en) do |inflect| inflect.uncountable 'rails' end
# File lib/active_support/inflector/inflections.rb, line 203 def inflections(locale = :en) if block_given? yield Inflections.instance(locale) else Inflections.instance(locale) end end
Returns the suffix that should be added to a number to denote the position in an ordered sequence such as 1st, 2nd, 3rd, 4th.
ordinal(1) # => "st" ordinal(2) # => "nd" ordinal(1002) # => "nd" ordinal(1003) # => "rd" ordinal(-11) # => "th" ordinal(-1021) # => "st"
# File lib/active_support/inflector/methods.rb, line 285 def ordinal(number) abs_number = number.to_i.abs if (11..13).include?(abs_number % 100) "th" else case abs_number % 10 when 1; "st" when 2; "nd" when 3; "rd" else "th" end end end
Turns a number into an ordinal string used to denote the position in an ordered sequence such as 1st, 2nd, 3rd, 4th.
ordinalize(1) # => "1st" ordinalize(2) # => "2nd" ordinalize(1002) # => "1002nd" ordinalize(1003) # => "1003rd" ordinalize(-11) # => "-11th" ordinalize(-1021) # => "-1021st"
# File lib/active_support/inflector/methods.rb, line 309 def ordinalize(number) "#{number}#{ordinal(number)}" end
Replaces special characters in a string so that it may be used as part of a ‘pretty’ URL.
class Person def to_param "#{id}-#{name.parameterize}" end end @person = Person.find(1) # => #<Person id: 1, name: "Donald E. Knuth"> <%=<EMAIL_ADDRESS>person_path(@person)) %> # => Donald E. Knuth
# File lib/active_support/inflector/transliterate.rb, line 80 def parameterize(string, sep = '-') # replace accented chars with their ascii equivalents parameterized_string = transliterate(string) # Turn unwanted chars into the separator parameterized_string.gsub!(/[^a-z0-9\-_]+/, sep) unless sep.nil? || sep.empty? re_sep = Regexp.escape(sep) # No more than one of the separator in a row. parameterized_string.gsub!(/#{re_sep}{2,}/, sep) # Remove leading/trailing separator. parameterized_string.gsub!(/^#{re_sep}|#{re_sep}$/, '') end parameterized_string.downcase end
Returns the plural form of the word in the string.
If passed an optional locale
parameter, the word will be
pluralized using rules defined for that language. By default, this
parameter is set to :en
.
'post'.pluralize # => "posts" 'octopus'.pluralize # => "octopi" 'sheep'.pluralize # => "sheep" 'words'.pluralize # => "words" 'CamelOctopus'.pluralize # => "CamelOctopi" 'ley'.pluralize(:es) # => "leyes"
# File lib/active_support/inflector/methods.rb, line 31 def pluralize(word, locale = :en) apply_inflections(word, inflections(locale).plurals) end
Tries to find a constant with the name specified in the argument string.
'Module'.safe_constantize # => Module 'Test::Unit'.safe_constantize # => Test::Unit
The name is assumed to be the one of a top-level constant, no matter whether it starts with “::” or not. No lexical context is taken into account:
C = 'outside' module M C = 'inside' C # => 'inside' 'C'.safe_constantize # => 'outside', same as ::C end
nil
is returned when the name is not in CamelCase or the
constant (or part of it) is unknown.
'blargle'.safe_constantize # => nil 'UnknownModule'.safe_constantize # => nil 'UnknownModule::Foo::Bar'.safe_constantize # => nil
# File lib/active_support/inflector/methods.rb, line 267 def safe_constantize(camel_cased_word) constantize(camel_cased_word) rescue NameError => e raise unless e.message =~ /(uninitialized constant|wrong constant name) #{const_regexp(camel_cased_word)}$/ || e.name.to_s == camel_cased_word.to_s rescue ArgumentError => e raise unless e.message =~ /not missing constant #{const_regexp(camel_cased_word)}\!$/ end
The reverse of pluralize
, returns the singular form of a word
in a string.
If passed an optional locale
parameter, the word will be
pluralized using rules defined for that language. By default, this
parameter is set to :en
.
'posts'.singularize # => "post" 'octopi'.singularize # => "octopus" 'sheep'.singularize # => "sheep" 'word'.singularize # => "word" 'CamelOctopi'.singularize # => "CamelOctopus" 'leyes'.singularize(:es) # => "ley"
# File lib/active_support/inflector/methods.rb, line 48 def singularize(word, locale = :en) apply_inflections(word, inflections(locale).singulars) end
Create the name of a table like Rails does for models to table names. This
method uses the pluralize
method on the last word in the
string.
'RawScaledScorer'.tableize # => "raw_scaled_scorers" 'egg_and_ham'.tableize # => "egg_and_hams" 'fancyCategory'.tableize # => "fancy_categories"
# File lib/active_support/inflector/methods.rb, line 136 def tableize(class_name) pluralize(underscore(class_name)) end
Capitalizes all the words and replaces some characters in the string to
create a nicer looking title. titleize
is meant for creating
pretty output. It is not used in the Rails internals.
titleize
is also aliased as titlecase
.
'man from the boondocks'.titleize # => "Man From The Boondocks" 'x-men: the last stand'.titleize # => "X Men: The Last Stand" 'TheManWithoutAPast'.titleize # => "The Man Without A Past" 'raiders_of_the_lost_ark'.titleize # => "Raiders Of The Lost Ark"
# File lib/active_support/inflector/methods.rb, line 126 def titleize(word) humanize(underscore(word)).gsub(/\b(?<!['’`])[a-z]/) { $&.capitalize } end
Replaces non-ASCII characters with an ASCII approximation, or if none exists, a replacement character which defaults to “?”.
transliterate('Ærøskøbing') # => "AEroskobing"
Default approximations are provided for Western/Latin characters, e.g, “ø”, “ñ”, “é”, “ß”, etc.
This method is I18n aware, so you can set up custom approximations for a locale. This can be useful, for example, to transliterate German’s “ü” and “ö” to “ue” and “oe”, or to add support for transliterating Russian to ASCII.
In order to make your custom transliterations available, you must set them
as the i18n.transliterate.rule
i18n key:
# Store the transliterations in locales/de.yml i18n: transliterate: rule: ü: "ue" ö: "oe" # Or set them using Ruby I18n.backend.store_translations(:de, i18n: { transliterate: { rule: { 'ü' => 'ue', 'ö' => 'oe' } } })
The value for i18n.transliterate.rule
can be a simple Hash that maps characters to ASCII approximations
as shown above, or, for more complex requirements, a Proc:
I18n.backend.store_translations(:de, i18n: { transliterate: { rule: ->(string) { MyTransliterator.transliterate(string) } } })
Now you can have different transliterations for each locale:
I18n.locale = :en transliterate('Jürgen') # => "Jurgen" I18n.locale = :de transliterate('Jürgen') # => "Juergen"
# File lib/active_support/inflector/transliterate.rb, line 60 def transliterate(string, replacement = "?") I18n.transliterate(ActiveSupport::Multibyte::Unicode.normalize( ActiveSupport::Multibyte::Unicode.tidy_bytes(string), :c), :replacement => replacement) end
Makes an underscored, lowercase form from the expression in the string.
Changes ‘::’ to ‘/’ to convert namespaces to paths.
'ActiveModel'.underscore # => "active_model" 'ActiveModel::Errors'.underscore # => "active_model/errors"
As a rule of thumb you can think of underscore
as the inverse
of camelize
, though there are cases where that does not hold:
'SSLError'.underscore.camelize # => "SslError"
# File lib/active_support/inflector/methods.rb, line 89 def underscore(camel_cased_word) word = camel_cased_word.to_s.dup word.gsub!('::', '/') word.gsub!(/(?:([A-Za-z\d])|^)(#{inflections.acronym_regex})(?=\b|[^a-z])/) { "#{$1}#{$1 && '_'}#{$2.downcase}" } word.gsub!(/([A-Z\d]+)([A-Z][a-z])/,'\1_\2') word.gsub!(/([a-z\d])([A-Z])/,'\1_\2') word.tr!("-", "_") word.downcase! word end


Music Collector
Search in concerts
Type
Select a type:
Seen concerts
Tickets
Autographs
Artist
Select an artist:
Chris Cornell
Guns n roses
Bruce Springsteen
Album
Select an album:
some
some
some
City
Select a city:
Moscow
Cluj
Bratislava
Type
Format
Gender
Artists
Year
City
Seen concert
Tour
some
some
some
some


October 24
God Goes Too!
But the person who is united to the Lord becomes one spirit with Him.
1 Corinthians 6:17
I once heard about a great man of God who looked in the mirror every day when he put on his suit and said, "Suit, everywhere you go today, God goes in you." And you know, he's right. If you have united yourself to God by receiving Jesus as Lord, everywhere you go today...God goes too!
As believers, we need tostartbecoming more conscious of that.
We need to continually remind ourselves that we are one spirit with Him. That means that every time we face a problem, every time we face an evil spirit that tries to influence and hinder our lives, God is facing it too. When we meet those things, God meets them. And He's already overcome them!
Let me encourage you when you get dressed today to look in the mirror and say, "I am united to the Lord and I have become one spirit with Him. Body, everywhere you go today...God goes. God is in you. The power of God is in you. The wisdom of God is in you. The victory of God is in you."
Say that to yourself every day-- many times a day. Keep doing it until you begin to develop the habit of thinking that way. Cultivate a constant awareness of the reality of God living in you!
Scripture Reading: 1 Corinthians 6:17-20


Airport to hotel
Getting from the airport to the hotel (Scandic Hotel, Kettevej 4, Hvidovre). You buy a ticket for 4 zones before descending to the platform, take the train from the airport, direction Helsingør. Get off at the main railway station (København H). Walk AWAY from the station building on the platform, to the bridge across the rails. From there, take bus 650S for around 17 min., direction Avedøre. You should get off at a stop called Hvidovre Hospitals Kollegium (Hvidovre hospital student's home) and from there walk 2 minutes, everything according to http://www.rejseplanen.dk which can be used for concrete travel plans if you can guess the meaning of the forms (they are in Danish). Bus schedules and zone information can be obtained at http://www.ht.dk (click the link "Turist" for information in English).
Hotel to DMI
Getting from the hotel to DMI with public transportation can be done in a multitude of ways. The simplest, involving only one change, requires the bus 650S in the opposite direction, Hellerup, getting off at the main station. Then take S-train H or H+, direction Farum, and get off at Ryparken. DMI is the red brick thing right next to the tracks. This requires a 3 zone ticket. With more complex routes you can do it with 2 zones.
Tickets can be bought in buses, in vending machines at stations, and at ticket booths. You can buy 10-trip cards (klippekort) for 2, 3, 4 etc. zones per stamp at around 2/3 of the price if you go together or will travel a lot. There are also one- or 3-day partout passes, but they are expensive.
Hotel Reservations
A block of hotel rooms has been reserved for the week of the meeting. Owing to a convention taking place the same week, hotel rooms in Copenhagen are expected to be scarce and attendees should reserve rooms promptly. To book a room contact Gitte Sejersen at DMI, email<EMAIL_ADDRESS>for further information. Please also notify us by return email if you plan to attend.
For further information
- The official Danish tourist board site: http://www.visitdenmark.com
- Bus and train information (in English): http://www.ht.dk/turist/engelsk.htm
- Some general information on Copenhagen (transportation, finance, etc.)
- Current and historical currency conversion (as of 15 May 2000, US$1 = DKK 8.18 or DKK 1 = US$0.122).
- Scandic Hotel
- Need to find an ATM when you arrive in Copenhagen? See the Copenhagen Airport website which has airport maps and other useful information.
- Current weather forecast for Copenhagen provided by (who else?) DMI.
Copyright/Trademark Legal Notice


Flipkart
Explore Plus
Top offers
Grocery
Mobiles
Fashion
Electronics
Home
Appliance
Travel
Baby products