| Balachander Krishnamurthy | Jeffrey C. Mogul | David M. Kristol |
| AT&T Labs-Research | Western Research Lab | Bell Laboratories |
| 180 Park Avenue | Compaq Computer Corp. | 600 Mountain Ave. |
| Florham Park, NJ 07932 | 250 University Avenue | Murray Hill, NJ 07974 USA |
<EMAIL_ADDRESS>|
Palo Alto, CA 94301 |
<EMAIL_ADDRESS>|
<EMAIL_ADDRESS>|
The HTTP/1.1 protocol is the result of four years of discussion and debate among a broad group of Web researchers and developers. It improves upon its phenomenally successful predecessor, HTTP/1.0, in numerous ways. We discuss the differences between HTTP/1.0 and HTTP/1.1, as well as some of the rationale behind these changes.
By any reasonable standard, the HTTP/1.0 protocol has been stunningly successful. As a measure of its popularity, HTTP accounted for about 75% of Internet backbone traffic in a recent study[TMW97]. In spite of its success, however, HTTP/1.0 is widely understood to have numerous flaws.
HTTP/1.0 evolved from the original ``0.9'' version of HTTP (which is still in rare use). The process leading to HTTP/1.0 involved significant debate and experimentation, but never produced a formal specification. The HTTP Working Group (HTTP-WG) of the Internet Engineering Task Force (IETF) produced a document (RFC1945) [BLFF96] that described the ``common usage'' of HTTP/1.0, but did not attempt to create a formal standard out of the many variant implementations. Instead, over a period of roughly four years, the HTTP-WG developed an improved protocol, known as HTTP/1.1. The HTTP/1.1 specification [FGM+98] is soon to become an IETF Draft Standard. Recent versions of some popular agents (MSIE, Apache) claim HTTP/1.1 compliance in their requests or responses, and many implementations have been tested for interoperable compliance with the specification [Mas98,NG98].
The HTTP/1.1 specification states the various requirements for clients, proxies, and servers. However, additional context and rationales for the changed or new features can help developers understand the motivation behind the changes, and provide them with a richer understanding of the protocol. Additionally, these rationales can give implementors a broader feel for the pros and cons of individual features.
In this paper we describe the major changes between the HTTP/1.0 and HTTP/1.1 protocols. The HTTP/1.1 specification is almost three times as long as RFC1945, reflecting an increase in complexity, clarity, and specificity. Even so, numerous rules are implied by the HTTP/1.1 specification, rather than being explicitly stated. While some attempts have been made to document the differences between HTTP/1.0 and HTTP/1.1 ([Mar97,Yap97], Section 19.6.1 of [FGM+98]), we know of no published analysis that covers major differences and the rationale behind them, and that reflects the most recent (and probably near-final) revision of the HTTP/1.1 specification. Because the HTTP-WG, a large and international group of researchers and developers, conducted most of its discussions via its mailing list, the archive of that list [CLF98] documents the history of the HTTP/1.1 effort. But that archive contains over 8500 messages, rendering it opaque to all but the most determined protocol historian.
We structure our discussion by (somewhat arbitrarily) dividing the protocol changes into nine major areas:
We devote a section to each area, including the motivation for changes and a description of the corresponding new features.
The HTTP/1.1 effort assumed, from the outset, that compatibility with the installed base of HTTP implementations (including many that did not conform with [BLFF96]) was mandatory. It seemed unlikely that most software vendors or Web site operators would deploy systems that failed to interoperate with the millions of existing clients, servers, and proxies.
Because the HTTP/1.1 effort took over four years, and generated numerous interim draft documents, many implementors deployed systems using the ``HTTP/1.1'' protocol version before the final version of the specification was finished. This created another compatibility problem: the final version had to be substantially compatible with these pseudo-HTTP/1.1 versions, even if the interim drafts turned out to have errors in them.
These absolute requirements for compatibility with poorly specified prior versions led to a number of idiosyncrasies and non-uniformities in the final design. It is not possible to understand the rationale for all of the HTTP/1.1 features without recognizing this point.
The compatibility issue also underlined the need to include, in HTTP/1.1, as much support as possible for future extensibility. That is, if a future version of HTTP were to be designed, it should not be hamstrung by any additional compatibility problems.
Note that HTTP has always specified that if an implementation receives a header that it does not understand, it must ignore the header. This rule allows a multitude of extensions without any change to the protocol version, although it does not by itself support all possible extensions.
In spite of the confusion over the meaning of the ``HTTP/1.1'' protocol version token (does it imply compatibility with one of the interim drafts, or with the final standard?), in many cases the version number in an HTTP message can be used to deduce the capabilities of the sender. A companion document to the HTTP specification [MFGN97] clearly specified the ground rules for the use and interpretation of HTTP version numbers.
The version number in an HTTP message refers to the hop-by-hop sender of the message, not the end-to-end sender. Thus the message's version number is directly useful in determining hop-by-hop message-level capabilities, but not very useful in determining end-to-end capabilities. For example, if an HTTP/1.1 origin server receives a message forwarded by an HTTP/1.1 proxy, it cannot tell from that message whether the ultimate client uses HTTP/1.0 or HTTP/1.1.
For this reason, as well as to
support debugging, HTTP/1.1 defines a Via
header
that describes the path followed by a forwarded message. The path
information includes the HTTP version numbers of all senders along
the path and is recorded by each successive recipient. (Only the
last of multiple consecutive HTTP/1.0 senders will be listed,
because HTTP/1.0 proxies will not add information to the Via
header.)
HTTP/1.1 introduces the OPTIONS
method, a way for a client to learn about the capabilities of
a server without actually requesting a resource. For example,
a proxy can verify that the server complies with a specific version
of the protocol. Unfortunately, the precise semantics of the OPTIONS
method were the subject of an intense and unresolved debate, and
we believe that the mechanism is not yet fully specified.
In order to ease the deployment
of incompatible future protocols, HTTP/1.1 includes the new Upgrade
request-header. By sending the Upgrade
header, a
client can inform a server of the set of protocols it supports
as an alternate means of communication. The server may choose
to switch protocols, but this is not mandatory.
Web developers recognized early on that the caching of responses was both possible and highly desirable. Caching is effective because a few resources are requested often by many users, or repeatedly by a given user. Caches are employed in most Web browsers and in many proxy servers; occasionally they are also employed in conjunction with certain origin servers. Web caching products, such as Cisco's cache engine [Cis] and Inktomi's Traffic Server [Ink] (to name two), are now a major business.
Many researchers have studied the effectiveness of HTTP caching [KLM97,DFKM97,ASA+95,IC97]. Caching improves user-perceived latency by eliminating the network communication with the origin server. Caching also reduces bandwidth consumption, by avoiding the transmission of unnecessary network packets. Reduced bandwidth consumption also indirectly reduces latency for uncached interactions, by reducing network congestion. Finally, caching can reduce the load on origin servers (and on intermediate proxies), further improving latency for uncached interactions.
One risk with caching is that the caching mechanism might not be ``semantically transparent'': that is, it might return a response different from what would be returned by direct communication with the origin server. While some applications can tolerate non-transparent responses, many Web applications (electronic commerce, for example) cannot.
HTTP/1.0 provided a simple caching
mechanism. An origin server may mark a response, using the Expires
header, with a time until which a cache could return the response
without violating semantic transparency. Further, a cache may
check the current validity of a response using what is known as
a conditional request: it may include an If-Modified-Since
header in a request for the resource, specifying the value given
in the cached response's Last-Modified
header. The
server may then either respond with a 304 (Not Modified) status
code, implying that the cache entry is valid, or it may send a
normal 200 (OK) response to replace the cache entry.
HTTP/1.0 also included a mechanism,
the Pragma: no-cache
header, for the client to indicate
that a request should not be satisfied from a cache.
The HTTP/1.0 caching mechanism worked moderately well, but it had many conceptual shortcomings. It did not allow either origin servers or clients to give full and explicit instructions to caches; therefore, it depended on a body of heuristics that were not well-specified. This led to two problems: incorrect caching of some responses that should not have been cached, and failure to cache some responses that could have been cached. The former causes semantic problems; the latter causes performance problems.
HTTP/1.1 attempts to clarify the concepts behind caching, and to provide explicit and extensible protocol mechanisms for caching. While it retains the basic HTTP/1.0 design, it augments that design both with new features, and with more careful specifications of the existing features.
In HTTP/1.1 terminology, a cache entry is fresh until it reaches its expiration time, at which point it becomes stale. A cache need not discard a stale entry, but it normally must revalidate it with the origin server before returning it in response to a subsequent request. However, the protocol allows both origin servers and end-user clients to override this basic rule.
In HTTP/1.0, a cache revalidated
an entry using the If-Modified-Since
header. This
header uses absolute timestamps with one-second resolution, which
could lead to caching errors either because of clock synchronization
errors, or because of lack of resolution. Therefore, HTTP/1.1
introduces the more general concept of an opaque cache validator
string, known as an entity tag. If two responses for
the same resource have the same entity tag, then they must (by
specification) be identical. Because an entity tag is opaque,
the origin server may use any information it deems necessary to
construct it (such as a fine-grained timestamp or an internal
database pointer), as long as it meets the uniqueness requirement.
Clients may compare entity tags for equality, but cannot otherwise
manipulate them. HTTP/1.1 servers attach entity tags to responses
using the ETag
header.
HTTP/1.1 includes a number of
new conditional request-headers, in addition to If-Modified-Since
.
The most basic is If-None-Match
, which allows a client
to present one or more entity tags from its cache entries for
a resource. If none of these matches the resource's current entity
tag value, the server returns a normal response; otherwise, it
may return a 304 (Not Modified) response with an ETag
header that indicates which cache entry is currently valid. Note
that this mechanism allows the server to cycle through a set of
possible responses, while the If-Modified-Since
mechanism
only generates a cache hit if the most recent response is valid.
HTTP/1.1 also adds new conditional
headers called If-Unmodified-Since
and If-Match
,
creating other forms of preconditions on requests. These preconditions
are useful in more complex situations; in particular, see the
discussion in Section 4.1
of Range requests.
In order to make caching requirements
more explicit, HTTP/1.1 adds the new Cache-Control
header, allowing an extensible set of cache-control directives
to be transmitted in both requests and responses. The set defined
by HTTP/1.1 is quite large, so we concentrate on several notable
members.
Because the absolute timestamps
in the HTTP/1.0 Expires
header can lead to failures
in the presence of clock skew (and observations suggest that serious
clock skew is common), HTTP/1.1 can use relative expiration times,
via the max-age
directive. (It also introduces an
Age
header, so that caches can indicate how long
a response has been sitting in caches along the way.)
Because some users have privacy
requirements that limit caching beyond the need for semantic transparency,
the private
and no-store
directives
allow servers and clients to prevent the storage of some or all
of a response. However, this does not guarantee privacy; only
cryptographic mechanisms can provide true privacy.
Some proxies transform responses
(for example, to reduce image complexity before transmission over
a slow link [FGBA96]),
but because some responses cannot be blindly transformed without
losing information, the no-transform
directive may
be used to prevent transformations.
A
cache finds a cache entry by using a key value in a lookup algorithm.
The simplistic caching model in HTTP/1.0 uses just the requested
URL as the cache key. However, the content negotiation mechanism
(described in Section 10)
breaks this model, because the response may vary not only based
on the URL, but also based on one or more request-headers (such
as Accept-Language
and Accept-Charset
).
To support caching of negotiated
responses, and for future extensibility, HTTP/1.1 includes the
Vary
response-header. This header field carries a
list of the relevant selecting request-header fields
that participated in the selection of the response variant. In
order to use the particular variant of the cached response in
replying to a subsequent request, the selecting request-headers
of the new request must exactly match those of the original request.
This simple and elegant extension mechanism works for many cases of negotiation, but it does not allow for much intelligence at the cache. For example, a smart cache could, in principle, realize that one request header value is compatible with another, without being equal. The HTTP/1.1 development effort included an attempt to provide so-called ``transparent content negotiation'' that would allow caches some active participation, but ultimately no consensus developed, and this attempt [HM98b,HM98a] was separated from the HTTP/1.1 specification.
Network bandwidth is almost always limited. Both by intrinsically delaying the transmission of data, and through the added queueing delay caused by congestion, wasting bandwidth increases latency. HTTP/1.0 wastes bandwidth in several ways that HTTP/1.1 addresses. A typical example is a server's sending an entire (large) resource when the client only needs a small part of it. There was no way in HTTP/1.0 to request partial objects. Also, it is possible for bandwidth to be wasted in the forward direction: if a HTTP/1.0 server could not accept large requests, it would return an error code after bandwidth had already been consumed. What was missing was the ability to negotiate with a server and to ensure its ability to handle such requests before sending them.
A
client may need only part of a resource. For example, it may want
to display just the beginning of a long document, or it may want
to continue downloading a file after a transfer was terminated
in mid-stream. HTTP/1.1 range requests allow a client
to request portions of a resource. While the range mechanism is
extensible to other units (such as chapters of a document, or
frames of a movie), HTTP/1.1 supports only ranges of bytes. A
client makes a range request by including the Range
header in its request, specifying one or more contiguous ranges
of bytes. The server can either ignore the Range
header, or it can return one or more ranges in the response.
If a response contains a range,
rather than the entire resource, it carries the 206 (Partial Content)
status code. This code prevents HTTP/1.0 proxy caches from accidentally
treating the response as a full one, and then using it as a cached
response to a subsequent request. In a range response, the Content-Range
header indicates the offset and length of the returned range,
and the new multipart/byteranges
MIME type allows
the transmission of multiple ranges in one message.
Range requests can be used in a variety of ways, such as:
Some of these forms of range request involve cache conditionals. That is, the proper response may depend on the validity of the client's cache entry (if any).
For example, the first kind (getting
a prefix of the resource) might be done unconditionally, or it
might be done with an If-None-Match
header; the latter
implies that the client only wants the range if the underlying
object has changed, and otherwise will use its cache entry.
The second kind of request, on
the other hand, is made when the client does not have a cache
entry that includes the desired range. Therefore, the client wants
the range only if the underlying object has not changed;
otherwise, it wants the full response. This could be accomplished
by first sending a range request with an If-Match
header, and then repeating the request without either header if
the first request fails. However, since this is an important optimization,
HTTP/1.1 includes an If-Range
header, which effectively
performs that sequence in a single interaction.
Range requests were originally proposed by Ari Luotonen and John Franks [FL95], using an extension to the URL syntax instead of a separate header field. However, this approach proved less general than the approach ultimated used in HTTP/1.1, especially with respect to conditional requests.
Some HTTP requests (for example,
the PUT
or POST
methods) carry request
bodies, which may be arbitrarily long. If, the server is not willing
to accept the request, perhaps because of an authentication failure,
it would be a waste of bandwidth to transmit such a large request
body.
HTTP/1.1 includes a new status code, 100 (Continue), to inform the client that the request body should be transmitted. When this mechanism is used, the client first sends its request headers, then waits for a response. If the response is an error code, such as 401 (Unauthorized), indicating that the server does not need to read the request body, the request is terminated. If the response is 100 (Continue), the client can then send the request body, knowing that the server will accept it.
However, HTTP/1.0 clients do not
understand the 100 (Continue) response. Therefore, in order to
trigger the use of this mechanism, the client sends the new Expect
header, with a value of 100-continue
. (The Expect
header could be used for other, future purposes not defined in
HTTP/1.1.)
Because not all servers use this
mechanism (the Expect
header is a relatively late
addition to HTTP/1.1, and early ``HTTP/1.1'' servers did not implement
it), the client must not wait indefinitely for a 100 (Continue)
response before sending its request body. HTTP/1.1 specifies a
number of somewhat complex rules to avoid either infinite waits
or wasted bandwidth. We lack sufficient experience based on deployed
implementations to know if this design will work efficiently.
One well-known way to conserve bandwidth is through the use of data compression. While most image formats (GIF, JPEG, MPEG) are precompressed, many other data types used in the Web are not. One study showed that aggressive use of additional compression could save almost 40% of the bytes sent via HTTP [MDFK97]. While HTTP/1.0 included some support for compression, it did not provide adequate mechanisms for negotiating the use of compression, or for distinguishing between end-to-end and hop-by-hop compression.
HTTP/1.1 makes a distinction between content-codings, which are end-to-end encodings that might be inherent in the native format of a resource, and transfer-codings, which are always hop-by-hop. Compression can be done either as a content-coding or as a transfer-coding. To support this choice, and the choice between various existing and future compression codings, without breaking compatibility with the installed base, HTTP/1.1 had to carefully revise and extend the mechanisms for negotiating the use of codings.
HTTP/1.0 includes the Content-Encoding
header, which indicates the end-to-end content-coding(s) used
for a message; HTTP/1.1 adds the Transfer-Encoding
header, which indicates the hop-by-hop transfer-coding(s) used
for a message.
HTTP/1.1 (unlike HTTP/1.0) carefully
specifies the Accept-Encoding
header, used by a client
to indicate what content-codings it can handle, and which ones
it prefers. One tricky issue is the need to support ``robot''
clients that are attempting to create mirrors of the origin server's
resources; another problem is the need to interoperate with HTTP/1.0
implementations, for which Accept-Encoding
was poorly
specified.
HTTP/1.1 also includes the TE
header, which allows the client to indicate which transfer-codings
are acceptable, and which are preferred. Note that one important
transfer-coding, Chunked
, has a special function
(not related to compression), and is discussed further in Section 6.1.
HTTP almost always uses TCP as its transport protocol. TCP works best for long-lived connections, but the original HTTP design used a new TCP connection for each request, so each request incurred the cost of setting up a new TCP connection (at least one round-trip time across the network, plus several overhead packets). Since most Web interactions are short (the median response message size is about 4 Kbytes [MDFK97]), the TCP connections seldom get past the ``slow-start'' region [Jac88] and therefore fail to maximize their use of the available bandwidth.
Web pages frequently have embedded images, sometimes many of them, and each image is retrieved via a separate HTTP request. The use of a new TCP connection for each image retrieval serializes the display of the entire page on the connection-setup latencies for all of the requests. Netscape introduced the use of parallel TCP connections to compensate for this serialization, but the possibility of increased congestion limits the utility of this approach.
To resolve these problems, Padmanabhan and Mogul [PM95] recommended the use of persistent connections and the pipelining of requests on a persistent connection.
Before discussing persistent connections, we address a more basic issue. Given the use of intermediate proxies, HTTP makes a distinction between the end-to-end path taken by a message, and the actual hop-by-hop connection between two HTTP implementations.
HTTP/1.1 introduces the concept
of hop-by-hop headers: message headers that apply only to a given
connection, and not to the entire path. (For example, we have
already described the hop-by-hop Transfer-Encoding
and TE
headers.) The use of hop-by-hop headers creates
a potential problem: if such a header were to be forwarded by
a naive proxy, it might mislead the recipient.
Therefore, HTTP/1.1 includes the
Connection
header. This header lists all of the hop-by-hop
headers in a message, telling the recipient that these headers
must be removed from that message before it is forwarded. This
extensible mechanism allows the future introduction of new hop-by-hop
headers; the sender need not know whether the recipient understands
a new header in order to prevent the recipient from forwarding
the header.
Because HTTP/1.0 proxies do not
understand the Connection
header, however, HTTP/1.1
imposes an additional rule. If a Connection
header
is received in an HTTP/1.0 message, then it must have been incorrectly
forwarded by an HTTP/1.0 proxy. Therefore, all of the headers
it lists were also incorrectly forwarded, and must be ignored.
The Connection
header
may also list connection-tokens, which are not headers
but rather per-connection boolean flags. For example, HTTP/1.1
defines the token close
to permit the peer to indicate
that it does not want to use a persistent connection. Again, the
Connection
header mechanism prevents these tokens
from being forwarded.
HTTP/1.0, in its documented form, made no provision for persistent
connections. Some HTTP/1.0 implementations, however, use a Keep-Alive
header (described in [Fie95])
to request that a connection persist. This design did not interoperate
with intermediate proxies (see Section 19.6.2 of [FGM+98]);
HTTP/1.1 specifies a more general solution.
In recognition of their desirable properties, HTTP/1.1 makes persistent connections the default. HTTP/1.1 clients, servers, and proxies assume that a connection will be kept open after the transmission of a request and its response. The protocol does allow an implementation to close a connection at any time, in order to manage its resources, although it is best to do so only after the end of a response.
Because an implementation may
prefer not to use persistent connections if it cannot efficiently
scale to large numbers of connections or may want to cleanly terminate
one for resource-management reasons, the protocol permits it to
send a Connection: close
header to inform the recipient
that the connection will not be reused.
Although HTTP/1.1 encourages the transmission of multiple requests over a single TCP connection, each request must still be sent in one contiguous message, and a server must send responses (on a given connection) in the order that it received the corresponding requests. However, a client need not wait to receive the response for one request before sending another request on the same connection. In fact, a client could send an arbitrarily large number of requests over a TCP connection before receiving any of the responses. This practice, known as pipelining, can greatly improve performance [NGBS+97]. It avoids the need to wait for network round-trips, and it makes the best possible use of the TCP protocol.
HTTP messages may carry a body
of arbitrary length. The recipient of a message needs to know
where the message ends. The sender can use the Content-Length
header, which gives the length of the body. However, many responses
are generated dynamically, by CGI [CGI98]
processes and similar mechanisms. Without buffering the entire
response (which would add latency), the server cannot know how
long it will be and cannot send a Content-Length
header.
When not using persistent connections, the solution is simple: the server closes the connection. This option is available in HTTP/1.1, but it defeats the performance advantages of persistent connections.
HTTP/1.1
resolves the problem of delimiting message bodies by introducing
the Chunked
transfer-coding. The sender breaks the
message body into chunks of arbitrary length, and each chunk is
sent with its length prepended; it marks the end of the message
with a zero-length chunk. The sender uses the Transfer-Encoding:
chunked
header to signal the use of chunking.
This mechanism allows the sender to buffer small pieces of the message, instead of the entire message, without adding much complexity or overhead. All HTTP/1.1 implementations must be able to receive chunked messages.
The Chunked
transfer-coding
solves another problem, not related to performance. In HTTP/1.0,
if the sender does not include a Content-Length
header,
the recipient cannot tell if the message has been truncated due
to transmission problems. This ambiguity leads to errors, especially
when truncated responses are stored in caches.
Chunking solves another problem
related to sender-side message buffering. Some header fields,
such as Content-MD5
(a cryptographic checksum over
the message body), cannot be computed until after the message
body is generated. In HTTP/1.0, the use of such header fields
required the sender to buffer the entire message.
In HTTP/1.1, a chunked message may include a trailer after the final chunk. A trailer is simply a set of one or more header fields. By placing them at the end of the message, the sender allows itself to compute them after generating the message body.
The sender alerts the recipient
to the presence of message trailers by including a Trailer
header, which lists the set of headers deferred until the trailer.
This alert, for example, allows a browser to avoid displaying
a prefix of the response before it has received authentication
information carried in a trailer.
HTTP/1.1 imposes certain conditions
on the use of trailers, to prevent certain kinds of interoperability
failure. For example, if a server sends a lengthy message with
a trailer to an HTTP/1.1 proxy that is forwarding the response
to an HTTP/1.0 client, the proxy must either buffer the entire
message or drop the trailer. Rather than insist that proxies buffer
arbitrarily long messages, which would be infeasible, the protocol
sets rules that should prevent any critical information in the
trailer (such as authentication information) from being lost because
of this problem. Specifically, a server cannot send a trailer
unless either the information it contains is purely optional,
or the client has sent a TE: trailers
header, indicating
that it is willing to receive trailers (and, implicitly, to buffer
the entire response if it is forwarding the message to an HTTP/1.0
client).
Several HTTP/1.1 mechanisms, such
as Digest Access Authentication (see Section 9.1),
require end-to-end agreement on the length of the message body;
this is known as the entity-length. Hop-by-hop transfer-codings,
such as compression or chunking, can temporarily change the transfer-length
of a message. Before this distinction was clarified, some earlier
implementations used the Content-Length
header indiscriminately.
Therefore, HTTP/1.1 gives a lengthy
set of rules for indicating and inferring the entity-length of
a message. For example, if a non-identity transfer-coding is used
(so the transfer-length and entity-length differ), the sender
is not allowed to use the Content-Length
header at
all. When a response contains multiple byte ranges, using Content-Type:
multipart/byteranges
, then this self-delimiting format
defines the transfer-length.
Companies and organizations use URLs to advertise themselves and their products and services. When a URL appears in a medium other than the Web itself, people seem to prefer ``pure hostname'' URLs; i.e., URLs without any path syntax following the hostname. These are often known as ``vanity URLs,'' but in spite of the implied disparagement, it's unlikely that non-purist users will abandon this practice, which has led to the continuing creation of huge numbers of hostnames.
IP addresses are widely perceived
as a scarce resource (pending the uncertain transition to IPv6 [DH95]). The Domain Name System (DNS)
allows multiple host names to be bound to the same IP address.
Unfortunately, because the original designers of HTTP did not
anticipate the ``success disaster'' they were enabling, HTTP/1.0
requests do not pass the hostname part of the request URL. For
example, if a user makes a request for the resource at URL http://example1.org/home.html
,
the browser sends a message with the Request-Line
GET /home.html HTTP/1.0
to the server at example1.org
.
This prevents the binding of another HTTP server hostname, such
as exampleB.org
to the same IP address, because the
server receiving such a message cannot tell which server the message
is meant for. Thus, the proliferation of vanity URLs causes a
proliferation of IP address allocations.
The Internet Engineering Steering
Group (IESG), which manages the IETF process, insisted that HTTP/1.1
take steps to improve conservation of IP addresses. Since HTTP/1.1
had to interoperate with HTTP/1.0, it could not change the format
of the Request-Line to include the server hostname. Instead, HTTP/1.1
requires requests to include a Host
header, first
proposed by John Franks [Fra94],
that carries the hostname. This converts the example above to:
GET /home.html HTTP/1.1 Host: example1.org
If the URL references a port other
than the default (TCP port 80), this is also given in the Host
header.
Clearly, since HTTP/1.0 clients
will not send Host
headers, HTTP/1.1 servers cannot
simply reject all messages without them. However, the HTTP/1.1
specification requires that an HTTP/1.1 server must reject any
HTTP/1.1 message that does not contain a Host
header.
The intent of the Host
header mechanism, and in particular the requirement that enforces
its presence in HTTP/1.1 requests, is to speed the transition
away from assigning a new IP address for every vanity URL. However,
as long as a substantial fraction of the users on the Internet
use browsers that do not send Host
, no Web site operator
(such as an electronic commerce business) that depends on these
users will give up a vanity-URL IP address. The transition, therefore,
may take many years. It may be obviated by an earlier transition
to IPv6, or by the use of market mechanisms to discourage the
unnecessary consumption of IPv4 addresses.
HTTP/1.0 defined a relatively small set of sixteen status codes, including the normal 200 (OK) code. Experience revealed the need for finer resolution in error reporting.
HTTP status codes indicate the success or failure of a request. For a successful response, the status code cannot provide additional advisory information, in part because the placement of the status code in the Status-Line, instead of in a header field, prevents the use of multiple status codes.
HTTP/1.1 introduces a Warning
header, which may carry any number of subsidiary status indications.
The intent is to allow a sender to advise the recipient that something
may be unsatisfactory about an ostensibly successful response.
HTTP/1.1 defines an initial set
of Warning
codes, mostly related to the actions of
caches along the response path. For example, a Warning
can mark a response as having been returned by a cache during
disconnected operation, when it is not possible to validate the
cache entry with the origin server.
The Warning
codes
are divided into two classes, based on the first digit of the
3-digit code. One class of warnings must be deleted after a successful
revalidation of a cache entry; the other class must be retained
with a revalidated cache entry. Because this distinction is made
based on the first digit of the code, rather than through an exhaustive
listing of the codes, it is extensible to Warning
codes defined in the future.
There are 24 new status codes in HTTP/1.1; we have discussed 100 (Continue), 206 (Partial Content), and 300 (Multiple Choices) elsewhere in this paper. A few of the more notable additions include
Most of the other new status codes are minor extensions.
In recent years, the IETF has heightened its sensitivity to issues of privacy and security. One special concern has been the elimination of passwords transmitted ``in the clear.'' This increased emphasis has manifested itself in the HTTP/1.1 specification (and other closely related specifications).
HTTP/1.0 provides a challenge-response access control mechanism,
Basic authentication. The origin server responds to a
request for which it needs authentication with a WWW-Authenticate
header that identifies the authentication scheme (in
this case, ``Basic'') and realm. (The realm value allows
a server to partition sets of resources into ``protection spaces,''
each with its own authorization database.)
The client (user agent) typically
queries the user for a username and password for the realm, then
repeats the original request, this time including an Authorization
header that contains the username and password. Assuming these
credentials are acceptable to it, the origin server responds by
sending the expected content. A client may continue to send the
same credentials for other resources in the same realm on the
same server, thus eliminating the extra overhead of the challenge
and response.
A serious flaw in Basic authentication is that the username and password in the credentials are unencrypted and therefore vulnerable to network snooping. The credentials also have no time dependency, so they could be collected at leisure and used long after they were collected. Digest access authentication [FHBH+97,FHBH+98] provides a simple mechanism that uses the same framework as Basic authentication while eliminating many of its flaws. (Digest access authentication, being largely separable from the HTTP/1.1 specification, has developed in parallel with it.)
The message flow in Digest access authentication mirrors that of Basic and uses the same headers, but with a scheme of ``Digest.'' The server's challenge in Digest access authentication uses a nonce (one-time) value, among other information. To respond successfully, a client must compute a checksum (MD5, by default) of the username, password, nonce, HTTP method of the request, and the requested URI. Not only is the password no longer unencrypted, but the given response is correct only for a single resource and method. Thus, an attacker that can snoop on the network could only replay the request, the response for which he has already seen. Unlike with Basic authentication, obtaining these credentials does not provide access to other resources.
As with Basic authentication, the client may make further requests to the same realm and include Digest credentials, computed with the appropriate request method and request-URI. However, the origin server's nonce value may be time-dependent. The server can reject the credentials by saying the response used a stale nonce and by providing a new one. The client can then recompute its credentials without needing to ask the user for username and password again.
In addition to the straightforward
authentication capability, Digest access authentication offers
two other features: support for third-party authentication servers,
and a limited message integrity feature (through the Authentication-Info
header).
Some proxy servers provide service only to properly authenticated clients. This prevents, for example, other clients from stealing bandwidth from an unsuspecting proxy.
To support proxy authentication,
HTTP/1.1 introduces the Proxy-Authenticate
and Proxy-Authorization
headers. They play the same role as the WWW-Authenticate
and Authorization
headers in HTTP/1.0, except that
the new headers are hop-by-hop, rather than end-to-end. Proxy
authentication may use either of the Digest or Basic authentication
schemes, but the former is preferred.
A proxy server sends the client
a Proxy-Authenticate
header, containing a challenge,
in a 407 (Proxy Authentication Required) response. The client
then repeats the initial request, but adds a Proxy-Authorization
header that contains credentials appropriate to the challenge.
After successful proxy authentication, a client typically sends
the same Proxy-Authorization
header to the proxy
with each subsequent request, rather than wait to be challenged
again.
The URI of a resource often represents information that some users may view as private. Users may prefer not to have it widely known that they have visited certain sites.
The Referer
[sic]
header in a request provides the server with the URI of the resource
from which the request-URI was obtained. This gives the server
information about the user's previous page-view. To protect against
unexpected privacy violations, the HTTP/1.1 specification takes
pains to discourage sending the Referer
header inappropriately;
for example, when a user enters a URL from the keyboard, the application
should not send a Referer
header describing the currently-visible
page, nor should a client send the Referer
header
in an insecure request if the referring page had been transferred
securely.
The use of a GET
-based
HTML form causes the encoding of form parameters in the request-URI.
Most proxy servers log these request-URIs. To protect against
revealing sensitive information, such as passwords or credit-card
numbers, in a URI, the HTTP/1.1 specification strongly discourages
the use of GET
-based forms for submitting such data.
The use of POST
-based forms prevents the form parameters
from appearing in a request-URI, and therefore from being logged
inappropriately.
MIME's Content-MD5
header contains the MD5 digest of the entity being sent[MR95].
The HTTP/1.1 specification provides specific rules for the use
of this header in the Web, which differ slightly from its use
in MIME (electronic mail). The sender may choose to send Content-MD5
so the recipient can detect accidental changes to the entity during
its transmission. Content-MD5
is a good example of
a header that a server might usefully send as a trailer.
Clearly the Content-MD5
value could easily be spoofed and cannot serve as a means of security.
Also, because Content-MD5
covers just the entity
in one message, it cannot be used to determine if a full response
has been successfully reassembled from a number of partial (range)
responses, or whether response headers have been altered.
HTTP requests are stateless. That is, from a server's perspective, each request can ordinarily be treated as independent of any other. For Web applications, however, state can sometimes be useful. For example, a shopping application would like to keep track of what is in a user's ``shopping basket,'' as the basket's contents change over the course of a sequence of HTTP requests.
Netscape introduced ``cookies'' [Net] in version 1.1 of their browser as a state management mechanism. The IETF subsequently standardized cookies in RFC2109 [KM97]. (The cookie specification is another example of how HTTP can be extended by a separate specification without affecting the core protocol. Cookie support is optional in servers and user agents, although some Web-based services will not work in their absence.)
The basic cookie mechanism is simple. An origin server sends an arbitrary piece of (state) information to the client in its response. The client is responsible for saving the information and returning it with its next request to the origin server. RFC2109 and Netscape's original specification relax this model so that a cookie can be returned to any of a collection of related servers, rather than just to one. The specifications also restricts for which URIs on a given server the cookie may be returned. A servers may assign a lifetime to a cookie, after which it is no longer used.
Cookies have both privacy and security implications. Because their content is arbitrary, cookies may contain sensitive application-dependent information. For example, they could contain credit card numbers, user names and passwords, or other personal information. Applications that send such information over unencrypted connections leave it vulnerable to snooping, and cookies stored at a client system might reveal sensitive information to another user of (or intruder into) that client.
RFC2109 proved to be controversial, primarily because of restrictions that were introduced to protect privacy. Probably the most controversial of these has to do with ``unverifiable transactions'' and ``third-party cookies.'' Consider this scenario.
http://www.example1.com/home.html
.
IMG
(image) tag with a reference to http://ad.example.com/adv1.gif
,
an advertisement.
ad.example.com
.
http://www.exampleB.com/home.html
.
IMG
tag with a reference to http://ad.example.com/adv2.gif
.
ad.example.com
in the process. The response includes
a new cookie from ad.example.com
.
Privacy advocates, and others, worried that:
ad.example.com
,
a site she didn't even know she was going to visit (an ``unverifiable
transaction''); and
ad.example.com
in the second image request (step
6).
If a Referer
header
is sent with each of the image requests to ad.example.com
,
then that site can begin to accumulate a profile of the user's
interests from the sites she visited, here http://www.example1.com/home.html
and http://www.exampleB.com/home.html
. Such an advertising
site could potentially select advertisements that are likely to
be interesting to her. While that profiling process is relatively
benign in isolation, it could become more personal if the profile
can also be tied to a specific real person, not just a persona.
For example, this might happen if the user goes through some kind
of registration at www.example1.com
.
RFC2109 sought to limit the possible
pernicious effects of cookies by requiring user agents to reject
cookies that arrive from the responses to unverifiable transactions.
RFC2109 further stated that user agents could be configured to
accept such cookies, provided that the default was not
to accept them. This default setting was a source of concern for
advertising networks (companies that run sites like ad.example.com
in the example) whose business model depended on cookies, and
whose business blossomed in the interval between when the specification
was essentially complete (July, 1996) and the time it appeared
as an RFC (February, 1997). RFC2109 has undergone further refinement [KM98] in response to comments,
both political and technical.
Web users speak many languages and use many character sets. Some Web resources are available in several variants to satisfy this multiplicity. HTTP/1.0 included the notion of content negotiation, a mechanism by which a client can inform the server which language(s) and/or character set(s) are acceptable to the user.
Content negotiation has proved to be a contentious and confusing area. Some aspects that appeared simple at first turned out to be quite difficult to resolve. For example, although current IETF practice is to insist on explicit character set labeling in all relevant contexts, the existing HTTP practice has been to use a default character set in most contexts, but not all implementations chose the same default. The use of unlabeled defaults greatly complicates the problem of internationalizing the Web.
HTTP/1.0 provided a few features to support content negotiation, but RFC1945 [BLFF96] never uses that term and devotes less than a page to the relevant protocol features. The HTTP/1.1 specification specifies these features with far greater care, and introduces a number of new concepts.
The goal of the content negotiation mechanism is to choose the best available representation of a resource. HTTP/1.1 provides two orthogonal forms of content negotiation, differing in where the choice is made:
Accept-Language
,
Accept-Charset
, etc. The server then chooses the
representation that best matches the preferences expressed in
these headers.
Although the HTTP/1.1 specification
reserves the Alternates
[HM98b]
header name for use in agent-driven negotiation, the HTTP working
group never completed a specification of this header, and server-driven
negotiation remains the only usable form.
Some users may speak multiple languages, but with varying degrees of fluency. Similarly, a Web resource might be available in its original language, and in several translations of varying faithfulness. HTTP introduces the use of quality values to express the importance or degree of acceptability of various negotiable parameters. A quality value (or qvalue) is a fixed-point number between 0.0 and 1.0. For example, a native speaker of English with some fluency in French, and who can impose on a Danish-speaking office-mate, might configure a browser to generate requests including
Accept-Language: en, fr;q=0.5, da;q=0.1
Because the content-negotiation mechanism allows qvalues and wildcards, and expresses variation across many dimensions (language, character-set, content-type, and content-encoding) the automated choice of the ``best available'' variant can be complex and might generate unexpected outcomes. These choices can interact with caching in subtle ways; see the discussion in Section 3.4.
Content negotiation promises to be a fertile area for additional protocol evolution. For example, the HTTP working group recognized the utility of automatic negotiation regarding client implementation features, such as screen size, resolution, and color depth. The IETF has created the Content Negotiation working group to carry forward with work in the area.
Although the HTTP working group will disband after the publication of the HTTP/1.1 specification, there are numerous pending proposals for further improvements. Here we sketch a few of the more significant ones.
The HTTP/1.1 specification placed a strong emphasis on extensibility but was not able to resolve this issue entirely. Although it has not yet achieved the status of a working group, one effort has been trying to define a general extensibility mechanism [NLL98].
As we noted in Section 10, the Content Negotiation working group is working on proposals to better define content negotiation [HM98b,HM98a] and feature tags.
Several researchers have observed that when Web resources change (thus invalidating cache entries), they usually do not change very much [DFKM97,MDFK97]. This suggests that transmitting only the differences (or delta) between the current resource value and a cached response, rather than an entire new response, could save bandwidth and time. Two of us, in conjunction with several other people, have proposed a simple extension to HTTP/1.1 to support delta encoding [MKD+99].
In today's Web, content is widely shared, but it mostly flows in one direction, from servers to clients. The Web could become a medium for distributed updates to shared content. The IETF's World Wide Web Distributed Authoring and Versioning (WEBDAV) working group is in the process of defining HTTP extensions to enable this vision [SVWD98].
HTTP/1.1 differs from HTTP/1.0 in numerous ways, both large and small. While many of these changes are clearly for the better, the protocol description has tripled in length, and many of the new features were introduced without any real experimental evaluation to back them up. The HTTP/1.1 specification also includes numerous irregularities for compatibility with the installed base of HTTP/1.0 implementations.
This increase in complexity complicates the job of client, server, and especially proxy cache implementors. It has already led to unexpected interactions between features, and will probably lead to others. We do not expect the adoption of HTTP/1.1 to go entirely without glitches. Fortunately, the numerous provisions in HTTP/1.1 for extensibility should simplify the introduction of future modifications.
We would like to thank the anonymous referees for their reviews.
http://ei.cs.vt.edu/~succeed/WWW4/WWW4.html
.
http://www.w3.org/CGI/
.
http://www.cisco.com/warp/public/751/cache
.
http://www.ics.uci.edu/pub/ietf/http/hypermail/
.
http://www.usenix.org/events/usits97
.
ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-06.txt
ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-03.txt
;
ftp://ftp.ietf.org/internet-drafts/draft-ietf-http-authentication-03.txt
;
http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q4/0063.html
.
http://www.ics.uci.edu/pub/ietf/http/hypermail/1995q2/0122.html
.
http://www.ics.uci.edu/pub/ietf/http/hypermail/1994q4/0019.html
.
http://www.usenix.org/events/usits97
.
http://www.inktomi.com/products/traffic/
.
http://www.usenix.org/publications/library/proceedings/usits97/kroeger.html
.
http://portal.research.bell-labs.com/~dmk/cookie-3.6.txt
;
this is a work in progress.
http://www.jmarshall.com/easy/http/
,
1997.
http://www.ietf.org/IESG/http1.1-implementations.txt
.
ftp://ftp.ietf.org/internet-drafts/draft-mogul-http-delta-01.txt
;
this is a work in progress.
http://www.netscape.com/newsref/std/cookie_spec.html
.
http://www.w3.org/Protocols/HTTP/Forum/Reports/
.
ftp://ftp.ietf.org/internet-drafts/draft-frystyk-http-extensions-01.txt
;
http://www.dstc.edu.au/aw3tc/papers/yap/
.
Vitae
Balachander Krishnamurthy is a researcher at AT&T Labs-Research in Florham Park, NJ, and can be reached at<EMAIL_ADDRESS>Jeffrey C. Mogul received an S.B. from the Massachusetts Institute of Technology in 1979, an M.S. from Stanford University in 1980, and his PhD from the Stanford University Computer Science Department in 1986. Dr. Mogul has been an active participant in the Internet community, and is the author or co-author of several Internet Standards; most recently, he has contributed extensively to the HTTP/1.1 specification. Since 1986, he has been a researcher at the Compaq (formerly Digital) Western Research Laboratory, working on network and operating systems issues for high-performance computer systems, and on improving performance of the Internet and the World Wide Web. He is a member of ACM, Sigma Xi, and CPSR, and was Programm Committee Chair for the Winter 1994 USENIX Technical Conference, and for the IEEE TCOS Sixth Workshop on Hot Topics in Operating Systems.
Address for correspondence: Compaq Computer Corporation Western Research Laboratory, 250 University Avenue, Palo Alto, California, 94301<EMAIL_ADDRESS>David M. Kristol is currently a Member of Technical Staff at Bell Laboratories, Lucent Technologies, in the Information Sciences Research Center, where he now does research in security and electronic commerce on the Internet. Previously, he worked on formal specifications for communications protocols. For six years he was responsible for the C compilers for UNIX(r) System V as a member of Bell Labs's Unix support organization, and he was the principal developer of the System V ANSI C compiler. He joined Bell Laboratories in 1981. Earlier, Kristol worked at Massachusetts Computer Associates, where he developed a mass spectrometry data system, and at GenRad, Inc., where he developed automatic test equipment systems. He received BA and BSEE degrees from the University of Pennsylvania, Philadelphia, and MS and ME degrees (in Applied Mathematics) from Harvard University.
His email address is: dmk@bell-labs.com.


This function turns an element into a leaflet map that display a single lot. The map will be displayed as a zoomable heat map if the lot already has the tree photos data. As a fall back, the map will be displayed as a polygon if the data are not available. The heat map are responding to the tree cluster and will be displayed as marker on higher zoom level

data-id
data-tree-page
data-offset


Admin module for MEAN applications to manage:
Install Package in root of your mean app:
$ mean install mean-admin
Add the admin role to your user:
$ mean user <email> -a admin
(Re)start the server:
$ grunt
In order to deploy mean-admin
to Heroku or otherwise, add the following line to package.json
of the mean app:
"mean-admin": "linnovate/mean-admin",
Note: the mean-admin
pubilshed on npm does not work with meanio. The line above will pull the module directly from GitHub.
Don't forget to add the admin
role to the admin user. Make sure server/config/env/production.js
is updated with the production db url, then use the --env
flag as:
$ mean user <email> -a admin --env production


#include "graphics_afx.h"
#include "GrFramebuffer.h"
#include "GrTexture.h"
#include "GrTextureRect.h"
#include "GrRenderbuffer.h"
#include "GrRenderTarget.h"
#include "GrRenderTargetMgr.h"
#include "GrConfig.h"
#include "GLSubsys.h"
#include "GrUtil.h"
#include "GrTextureMgr.h"
#include "GrShader.h"
#include "GrShaderMgr.h"
#include "GrRenderUtil.h"
#include <mmsystem.h>
#include <gl/glu.h>
Go to the source code of this file.
Defines | |
| #define | PP_SCALE_ST 0 |
| #define | PP_OFFSET_ST 1 |
| #define | PP_BLUR_DIR 2 |
| #define | PP_BLOOM_START 3 |
| #define | PP_BLOOM_STRENGTH 4 |
| #define | PP_HIPASS_OFFSET 5 |
| #define | PP_LUM_OFFSET 2 |
| #define | PP_CURRENDER_OFFSET_ST 1 |
| #define | PP_BLUR_OFFSET_ST 2 |
| #define | PP_BLUR_SCALE_ST 3 |
Variables | |
| GrFramebuffer * | gGrFramebuffer = 0 |
| const unsigned int | kTexCoordScaleHandle = 1 |
| user param handles for HDR shaders. | |
| const unsigned int | kBlurVecHandle = 2 |
| float | kHorzVec [4] = { 1.0f, 0.0f, 0.0f, 0.0f } |
| blur vectors. | |
| float | kVertVec [4] = { 0.0f, 1.0f, 0.0f, 0.0f } |
| #define PP_BLOOM_START 3 |
Definition at line 39 of file GrFramebuffer.cpp.
| #define PP_BLOOM_STRENGTH 4 |
Definition at line 40 of file GrFramebuffer.cpp.
| #define PP_BLUR_DIR 2 |
Definition at line 38 of file GrFramebuffer.cpp.
| #define PP_BLUR_OFFSET_ST 2 |
Definition at line 45 of file GrFramebuffer.cpp.
| #define PP_BLUR_SCALE_ST 3 |
Definition at line 46 of file GrFramebuffer.cpp.
| #define PP_CURRENDER_OFFSET_ST 1 |
Definition at line 44 of file GrFramebuffer.cpp.
| #define PP_HIPASS_OFFSET 5 |
Definition at line 41 of file GrFramebuffer.cpp.
| #define PP_LUM_OFFSET 2 |
Definition at line 42 of file GrFramebuffer.cpp.
| #define PP_OFFSET_ST 1 |
Definition at line 37 of file GrFramebuffer.cpp.
| #define PP_SCALE_ST 0 |
Definition at line 36 of file GrFramebuffer.cpp.
Definition at line 34 of file GrFramebuffer.cpp.
| const unsigned int kBlurVecHandle = 2 |
Definition at line 50 of file GrFramebuffer.cpp.
| float kHorzVec[4] = { 1.0f, 0.0f, 0.0f, 0.0f } |
| const unsigned int kTexCoordScaleHandle = 1 |
| float kVertVec[4] = { 0.0f, 1.0f, 0.0f, 0.0f } |
Definition at line 54 of file GrFramebuffer.cpp.


Digital will planning made easy!
Find Out MoreProvide for your loved ones with our digital will-making service. It is free and you are never too late to get started now.
Get Started!Make a will on the website by answering simple questions, we also have a image recognition software, which will make the setup of the will even more simpler.
After the digitization of the will, the platform will sent out the link to the guarantors, to be accessed that the later date when the account holder have deceased.
Through the use of e-signatures(bio-metric thumbprint), we can digitize the experience of the will for the whole legacy.
With a legal binding digital will, one can visit the respective financial institutions to get the fund re-structured according the to the next generation needs.


Fast Send
1. input a token
2. send a file or press recv button
recv:
send:
recv
Send progress:
Receive progress:


Glucose Sodium Bromide
Formula: 2C6H12O6·NaBr·H2O
Crystalline adduct (cocrystal) of carbohydrate glucose with sodium bromide.
Details ...
All the stuff I put online, in one place finally
Formula: 2C6H12O6·NaBr·H2O
Crystalline adduct (cocrystal) of carbohydrate glucose with sodium bromide.
Formula: (NH3CH2COOH)2C2O4
Oxalic acid H2C2O4 is among the strongest inorganic acids, and can easily form salts with many weak bases such as amino-acid glycine. When one mole of oxalic acid is crystallized together with 2 moles of glycine, transparent sticks of glycine oxalate grows.
Different names: diglycine oxalate, glycinium oxalate.
Saccharin is the first successful chemical sugar substitute; it gained its popularity during the time of WWII and is still in use nowadays, though to a much lesser extent: there are tastier and safer substitutes now. Strictly speaking, saccharin is a weak acid, that is almost insoluble in water. Soluble saccharin is its sodium salt: sodium saccharinate.
Formula: C6H14O6
Mannitol is a sugar alcohol, chemically similar to xylitol and erythritol, but having very different crystal morphology. It crystallizes as long transparent sticks.
Cocrystal of urea and citric acid in 1:1 molar ration. Tentative formula: CO(NH2)2·C3H4(OH)(COOH)3 (can contain unknown amount of water).


| Class | Applies to | Description |
|---|---|---|
{{ item.class }} |
{{ item.applies | default: "N/A" | markdown | newline_to_br }} | {{ item.description | markdown }} |
At their most basic, our topbar component provides branding and context for the user. In this example, we have a scaled back version showing some global navigation, user settings & preferences, and notifications.
Depending on the user's authentication levels, we may need to include lots of options and menus. The topbar can include new marketing notifications, marketing navigation, a search bar, user details, moderator tools, review queues, achievements, inbox, help, and various bits of navigation.
{% header "h3", "Theming" %}By default, the topbar automatically switches between light and dark modes as expected. In specific products like Teams, we choose to force a dark version to help the user differentiate between contexts. You can choose either light or dark by applying their respective classes to the main component.
The topbar can also include a search bar. Depending on the user’s products, it may be appropriate to add a select menu to choose the context for their search.
If a user is logged out, or is anonymous, we provide a container for various calls to actions. This is a less opinionated container that only provides layout without styling of the individual children.
By default, the topbar has a container that is full width, up to our widest point as defined by our global variables. If you need to override this, you can apply any combination of atomic base classes to the container.


Leshia was a pleasure to work with and I would highly recommend her services.
She's highly creative and has a keen eye for detail. She consistently delivered work of
the highest standard, and pushed for pixel perfect finishes for her designs from developers,
while staying within tight time restraints.
Olu Meduoye
www.olumeduoye.com


Learn everything you need to know to get started building a MongoDB-based app. From basic installation, JSON, schema design, querying, insertion of data, indexing and working with the .NET driver.
Learn More


Chart.js Polar Area in a DC Chart Group
Using Data pulled from Zepfanman's movie spreadsheet about Hayao Miyazaki films
Miyazaki's Films Grouped by IMDb Rating
Miyazaki's Films Grouped by IMDb Votes


Unprecedented value results from identifying risks,
working to reduce each risk and working to make each
risk more predictable.
Identification and management of risks are the
main concerns in every software project.
We identify fundamental risks
involved in creating an enterprise application system.
We describe each risk and address how we make it
become more predictable.
See section:
for the breakdown of costs and how we address each of them.
We reduce several critical types of risk.
The end-result is greater overall predictability
(as well as increased quality and reliability).
This includes risk of loss due to the following:
Automating development of complex software components
reduces risk across the board in all areas of implementation.
Automating development of complex software components
reduces risk across the board in all areas of implementation.
The risks are possible problems that might endanger the objectives of the project.
The risks here It is the possibility of a negative or undesirable outcome.
It is essential to rely upon a computational approach to
systematically auto-generate necessary tests, at necessary levels,
using necessary contexts, and tests cases.
Relying upon a proprly configured repository manager such as
is an adequate approach.
Proper management of external 3rd party dependencies is a huge challenge and is not easily accomplished.
Relying upon hierachies of Maven bom
files as well as information provided by Maven is an effective approach
to managing dependencies and systematically detecting and eliminating missing
dependencies and hidden conflicts.


{{ blogEntry.title | capitalize }} postado {{blogEntry.timestamp[3] | lower }}, {{blogEntry.timestamp[0]}} de {{blogEntry.timestamp[1]}}, {{blogEntry.timestamp[2]}} {{ blogEntry.content | safe }} Please enable JavaScript to view the comments powered by Disqus.


Shorthand property to set values the thickness of the padding area. If left is omitted, it is the same as right. If bottom is omitted it is the same as top, if right is omitted it is the same as top. The value may not be negative
Attaches one or more drop-shadows to the box. The property is a comma-separated list of shadows, each specified by 2-4 length values, an optional color, and an optional 'inset' keyword. Omitted lengths are 0; omitted colors are a user agent chosen color.


Asian qualifiers: Today's scores and stats
by FIFA.comSeveral of Asian football's biggest names were in action today as the continent's second qualifying round for the 2022 FIFA World Cup Qatar™ continued.
Here are all of today's results and stand-out statistics.
Results
Myanmar 4-3 Tajikistan
- Myanmar shock Tajikistan in a seven-goal thriller to pick up their first points of the campaign, ending a three-game winless run and dealing a heavy blow to their visitors' qualifying hopes.
Maldives 1-2 Philippines
- Two goals in 16 second-half minutes secure the Philippines a key victory over Maldives, taking the visitors on to seven points in Group A.
Turkmenistan 3-1 Korea DPR
- Turkmenistan register a surprisingly comfortable win over Korea DPR - erstwhile joint-leaders of Group H - and move on to six points, just one point below their beaten visitors.
Kyrgyz Republic 0-2 Japan
- Japan retain their perfect record thus far. The Samurai Blue have now gone four games without dropping a point or conceding a goal.
Uzbekistan 2-3 Saudi Arabia
- A stunning late comeback gives Saudi Arabia victory in this vital top-of-the-table clash and sees them leapfrog their hosts to seize top spot in Group D. This was the Saudis' 70th win in World Cup qualifying.
Hong Kong 0-0 Bahrain
- Stalemate at the Hong Kong Stadium as Bahrain - currently joint-top of Group C - spurn the chance to make ground on rivals Iraq and Iran, who face off shortly.
Malaysia 2-1 Thailand
- Neighbours Malaysia come from behind to inflict Thailand's first defeat of the Qatar 2022 qualifying campaign, dealing a heavy blow to the erstwhile Group G leaders' hopes of progressing.
Lebanon 0-0 Korea Republic
- The goalless draw in Beirut sees Turkmenistan jump to the top of Group H. Lebanon were playing in their 60th World Cup qualifier in history, while it was Korea Republic's six consecutive qualifier without conceding a goal, totaling an impressive 556 minutes.
Vietnam 1-0 United Arab Emirates
- Vietnam go top of Group G following a famous win in Hanoi thanks to Nguyen Tien Linh's goal right before half-time. This is their third consecutive World Cup qualifying win, which is a record for the nation.
Syria 2-1 China PR
- A huge win for Group A leaders Syria, who maintained their 100 per cent record by seeing off section rivals China PR. Zhang Linpeng was the Syrians' unwitting match-winner, putting through his own goal with 14 minutes remaining to leave the Chinese five points adrift of their qualifying rivals.
Afghanistan 1-1 India
- Seminlen Doungel was India's injury-time hero, scoring a 93rd-minute leveller to snatch a point against Afghanistan when a costly defeat in Group E looked inevitable. The Indians' winless run in World Cup qualifying now stretches to six matches though.
Iraq IR 2-1 Iran
- A stunning victory for Iraq, who scored in the 92nd minute through Alaa Abbas to move four points clear of their old rivals at the top of Group C. This was Iran's second successive World Cup qualifying defeat - a fate that has befallen them only twice before (in 1974 and 1998).
Yemen 1-0 Palestine
- Yemen ended an unwanted streak of five World Cup qualifiers without a win by edging Palestine, playing in their 30th World Cup qualifying match, 1-0 in Al Muharraq. Omar Abdullah Al-Dahi scored the winning goal in the 54th minute to help his side leapfrog their opponents into third place in Group D.
Oman 4-1 Bangladesh
- Oman won the first World Cup qualifier played between the two sides. The comfortable win sees them go one point behind Qatar at the summit of Group E. For Bangladesh, they have now gone five World Cup qualifiers without a win.
Kuwait 9-0 Chinese Taipei
- Kuwait win convincingly in Kuwait City in what was their 50th victory in 97 World Cup qualifying matches. The result also equals their biggest-ever win in World Cup qualifying history (10-1 v Macau in 1993 and 9-0 v Myanmar in 2015).
Jordan 0-1 Australia
- Australia win in Jordan in World Cup qualifying for the first time, following two previous defeats. The victory sees them stay perfect with four wins from four at the top of Group B.


-
J. Faye Yuan
Writer & Creative Director
When she is not writing or creating, she is probably busy asking questions.
-
Juan Paredes
Editor & Producer
He enjoys working on projects that create emotional and cerebral experiences for the general public as a way to effect greater change.
-
Matt Watkajtys
Lead Engineer
Bringing projects to life one commit at a time.
-
Celso White
Developer
Storyteller, front-end developer. Loves creating user-centric experiences.
-
Tom Calabrese
Product Designer
He is also the founder of an ed-tech nonprofit, helping kids write.
-
Jihii Jolly
Consulting Producer
She's a journalist who specializes in video and writing on religion, culture and media.
He Said/She Said is a participatory, transmedia project about dating in the digital age.
Watch the TrailerScroll to begin the story
Sue just met John. They’re having a New York moment of trying to get to know each other as quickly as possible before the fear of missing out sets in.
"It was instantly like I need to know this guy,"
she later recalls.
Act 1 documents their story, capturing a specific moment in time - the first 48 hours of courtship.
"Her eyes were like these bottomless pits... I could get lost in them," he later remembers.
We asked them what happened in the cuddle room, and they responded...
Whose version of the cuddle room do you believe?
The price of omission! Let's see what her friend has to say.
"Everything being completely... voluntary... and purely chosen... is really sexy and attractive."
"There's something ephemeral about him... but there's also a quality of permanence to him."
Do you think they mean what they say here?
What happens next you must be wondering...
In early 2015, I set out to document how couples conduct their online and offline relationships. How can we harness the power of social messaging tools to tell stories about relationships in transition? And how can such stories become their own tools for reflection?
In this age of ubiquitous self-documentation, I suspect there are moments when we come to doubt the things we post. I wonder in those moments: Are we cutting corners by forcing our experience to fit our language - language fleeting enough to draw an invisible sea of nods and approval?
The timing of each episode’s release mimics the relationship dynamic at play. A tone of urgency characterizes every interaction in the first couple’s story. Their segments will be released at a quicker pace than that of the second couple, who is well-entrenched in their day-to-days. The heartbreaking journey of voluntary separation always begins with stagnation. Segments released about the third couple are characterized by false starts and abrupt endings.


LDD Regression Testing¶
Overview¶
Local Data Dictionary (LDD) stewards are expected to provide example labels that can be used for regression testing LDDs delivered for release. The number and complexity of examples developed are dependent upon the dictionary steward and what is determined to be a high-priority or is thought to be something that are critical to the dictionary. The following page describes some examples of regression tests as well as where/how these files should be provided to PDS Engineering Node to complete that testing.
Regression Test Data¶
Regression tests should be made up of PDS4 example products that either successfully or unsuccessfully validate using the PDS Validate Tool.
For simple examples of generating simple regression test cases, see the LDD Template repository.
Regression Test Data Rules¶
In order for your regression test data to be autonomously tested during the automated LDD Generation process, you must follow the following rules when posting your test data to Github:
No schematrons - do not include schematron references in the labels. the pipeline will automatically add the newly generated schematrons to the validation.
No schemaLocations - do not include schemaLocation references in the labels. the pipeline will automatically add the newly generated schematrons to the validation.
Include ``[IM_VERSION]`` for information_model_version - use
[IM_VERSION]
value forinformation_model_version
attribute so it can be dynamically replaced by the pipeline
Test Data Directory Layout¶
Regression test products should be maintained within the test/
directory of your LDD Repo:
ldd-test/
├── ...
├── test
│ ├── No.Data
│ ├── test1_FAIL.xml
│ └── test1_VALID.xml
where:
PDS4_SP_1100_1000_test
- this top level directory should be named using the formatPDS4_<namespace_id>_<IM_version>_<LDD_version>_test
*FAIL*
- all PDS4 XML labels that will fail validation against delivered dictionaries. Output from Validate Tool should go into*FAIL*.log
files in order to compare output from EN Validate execution.*VALID*
- all PDS4 XML labels that will complete successful validation against delivered dictionaries.


JUST ANNOUNCED: The Killers are playing two huge stadiums next summer
by By Nick LevineThe Killers reminded us just how many absolute bangers they have at their disposal when they headlined Glastonbury this summer. Now the Vegas rock dandies have announced they’ll be deploying them again at a couple of huge UK stadium shows next summer, as part of their Imploding The Mirage tour. Amazing name, we think you'll agree.
Brandon Flowers and the gang will play Manchester’s Emirates Old Trafford Stadium on May 30 and London’s Emirates Stadium on June 6. This is your first chance to see them in the capital since November 2017, when they played The O2, so make sure you’re ready when tickets go on sale at 9am on November 22. And if you don't manage to bag any, try to be gracious and ‘Smile Like You Mean It’.
The Killers tickets will go on sale here. Check out more big gigs happening in the capital in 2020 here.


{{ confirmCasesCount |number : '1.0-0' }}
Today: {{todayConfirmedCases | number}}{{confirmCasesCount - recoveredCount - diedCount | number}}
{{recoveredCount | number}}
Today: {{todayRecoveredCases | number}}{{diedCount | number}}
Today: {{todayDiedCases | number}}| State/UT | Confirmed | Active | Recovered | Deceased | Tested |
|---|---|---|---|---|---|
| {{state.stateName}} |
{{state.todayConfirmed}}
{{state.confirmedCases | number}}
|
{{state.confirmedCases - state.recoveredCases - state.deceasedCases | number}} |
{{state.todayRecovered | number}}
{{state.recoveredCases | number}} |
{{state.todayDied | number}}
{{state.deceasedCases | number}} |
{{state.tested | number}} |
| Total | {{confirmCasesCount | number}} | {{confirmCasesCount - recoveredCount - diedCount | number}} | {{recoveredCount | number}} | {{diedCount | number}} | {{totalTests| number}} |


Kogi Election: INEC Presents Certificate Of Return To Bello
by Olugbenga IgeThe Independent National Electoral Commission (INEC) has presented the Certificate of Return to Governor Yahaya Bello of Kogi State.
Concise News had reported that INEC Returning Officer for the election, Ibrahim Umar, said Bello polled a massive 406,222 votes to defeat his main rival, Musa Wada of the Peoples Democratic Party (PDP) who got 189,704 votes.
According to Umar, the candidate of the Social Democratic Party (SDP), Natasha Akpoti, garnered 9,482 votes.
The National Commissioner in charge of North Central, Mohammed Kudu Haruna, presented the certificates to Bello and his deputy governor-elect, Edward Onoja at the INEC state headquarters in Lokoja.
Haruna said: “Today marks a new beginning after the election and a call to duty for the governor-elect and his deputy.”
In his acceptance speech, Governor Bello appreciated the Kogi people for re-electing him and his party, the All Progressives Congress (APC) back into office.
According to the governor, the event will not be the last time he will be receiving a Certificate of Return from INEC.
He was accompanied by his wife and top government officials and chieftains of the All Progressives Congress in the state.


Save Your Contact
Save
ID
Name
Email
Job Title
Action
DELETE
×
Do you want to delete this?
Edit Info
×
Name
Email
Job Title


Select-Autocomplete Control with dynamic list
Your favorite form the list:
[
{"label":"LightGreen","value":"lightgreen"},
{"label":"Green","value":"green"},
{"label":"DarkGreen","value":"darkgreen"},
{"label":"LightBlue","value":"lightblue"},
{"label":"Blue","value":"blue"},
{"label":"DarkBlue","value":"darkblue"},
{"label":"LightRed","value":"lightred"},
{"label":"Red","value":"red"},
{"label":"DarkRed","value":"darkred"},
{"label":"LightYellow","value":"lightyellow"},
{"label":"Yellow","value":"yellow"},
{"label":"DarkYellow","value":"darkyellow"}
]
User can provide a value that's not in the list
Your free selection:
Do not use `xf-material-select` with conflicting 'selection' settings on the same bound
node. This
will lead to unexpected behavior as a selection='closed' control will reset a manually given value.


You're using Internet Explorer 6-8 to browse webpages right now, our website will work better for you if you upgrade to Internet Explorer 9 or switch to another browser.
Chrome
Firefox
Opera


github.com/moneydesktop
moneydesktop.com
twitter.com/moneydesktop
An OLAP Cube library in Ruby (WIP)
RubyGem for ASCII art characters emoting your messages
ActiveRecord migration library to speed up schema changes for large PostgreSQL tables


Dougie
- Mini Rex
- Neutered Male
- Age: 4 years
- Weight: 5 lbs
More Info
Hi! My name is Dougie.
I was in a shelter that lacked the resources to continue to care for me, so I came to Animal Humane Society to find a new home.
I am a Shy Snuggler! Shy Snugglers are relaxed, gentle and a little bit timid. They adapt fairly quickly to new environments, people and changes in routine, but can be overwhelmed by too much noise or activity. They are affectionate and enjoy human interaction, but also need time alone. They are rarely mischievous and often live harmoniously with other pets. They prefer a calm, quiet home and are a great choice for first-time adopters and homes with gentle children of all ages. They are not the best candidate for agility class or the role of therapy animal, but may enjoy these roles over time.
ID#: 31253658
Location: Golden Valley (Mon-Fri: Noon-8pm / Sat-Sun 10am-6pm)
Adoption Fee: $51.00


This is the projects view.
list projects belonging to contacts and ask to join
accept/reject join requests from other users
invite users to project (and Ubi)
project cards
export status to pdf
embed/create docs (PID etc)
Just add a project title for now and you can add team members and other important details later
{{project.title}}
{{project.Description}}
My role: {{proj.$value}}
Status: {{project.currentStatus}}
Created At:
Created By:


| Score Aggregation | My Score | My Relative Score (%) | Max Score |
|---|---|---|---|
| Score for quizzes | {{quizzesTotalScore}} | {{quizzesTotalRelativeScore}}% | {{quizzesTotalMaxScore}} |
| Score for programming exercises | {{programmingExerciseTotalScore}} | {{programmingExerciseTotalRelativeScore}}% | {{programmingExerciseTotalMaxScore}} |
| Score for modeling exercises | {{modelingExerciseTotalScore}} | {{modelingExerciseTotalRelativeScore}}% | {{modelingExerciseTotalMaxScore}} |
| Total score for this course | {{totalScore}} | {{totalRelativeScore}}% | {{totalMaxScore}} |
| Score Aggregation | My Score | My Relative Score (%) | Max Score | |
|---|---|---|---|---|
| Score for quizzes | {{quizzesTotalScore}} | {{quizzesTotalRelativeScore}}% | {{quizzesTotalMaxScore}} | |
| Score for homework | {{eistHomeworkTotalScore}} | {{eistHomeworkRelativeScore}}% | {{eistHomeworkMaxScore}} | |
| Score for in-class exercises | {{eistInClassTotalScore}} | {{eistInClassRelativeScore}}% | {{eistInClassMaxScore}} | |
| Total score for this course | {{totalScore}} | {{totalRelativeScore}}% | {{totalMaxScore}} |


HashSetImplementation<E>
Set<E>
HashSet();
Creates a Set that contains all elements of other.
HashSet.from(Iterable<E> other);


fun allPermissionsGranted(): Unit
All the required permissions have been granted, so we can now do the sensitive operations that require these permissions, namely initing the cameras and also creating the storage folder that will house saved images


{% extends "layout.html" %} {% block page_title %} Publish government data {% endblock %} {% block proposition_header %} {% include "includes/propositional_navigation_service.html" %} {% endblock %} {% block header_class %} with-proposition {% endblock %} {% block content %} {% include "includes/phase_banner_alpha.html" %} {% include "includes/side-navigation.html" %} {{formData | safe}} Your harvester has been created The harvester has been created and a first-run has been scheduled to run in the next 30 minutes. Would you like to be notified of changes after each harvest? Would you like to be notified? Yes No {% endblock %}
The harvester has been created and a first-run has been scheduled to run in the next 30 minutes.


Image credit Image credit placement Top left Top right Bottom left Bottom right Image credit color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Photo Credit Color Image treatment Small Large Promo Email Large Header Promo Image Polaroid calloutSmall calloutLarge Image button None Play button Audio button Image caption Image caption size


Clergeot carries UMass over Central Connecticut 89-43
by EndPlayAMHERST, Mass. (AP) - Keon Clergeot scored 20 points as UMass rolled past Central Connecticut 89-43 on Saturday.
Sean East II had 15 points and six assists for UMass (4-0), which shot 52. 5 % from the floor (32 of 61) and 10 of 22 from behind the 3-point arc. Samba Diallo added 13 points. Djery Baptiste had 12 rebounds and three blocks for the Minutemen.
Greg Outlaw had 12 points for the Blue Devils (0-4), who were hampered by 16 of 48 shooting and 24 turnovers.
UMass matches up against Rider at home on Wednesday. Central Connecticut looks for its first win against New Hampshire at home on Tuesday.
___
For more AP college basketball coverage: https://apnews.com/Collegebasketball and http://twitter.com/AP_Top25
___
This was generated by Automated Insights, http://www.automatedinsights.com/ap, using data from STATS LLC, https://www.stats.com


--- layout: post title: Episode 027 | Jason Resnick - The Right Priorities link: http://traffic.libsyn.com/developeronfire/DeveloperOnFire-27-JasonResnick.mp3 length: 36700160 speaker: Dave Rael duration: '46:18' subtitle: 'Developer On Fire: Jason Resnick' guest_name: Jason Resnick image: /assets/images/JasonResnick.jpg guest_blog: http://rezzz.com/ guest_twitter: rezzz disqus_url: http://developeronfire.com/Podcast/Episodes/jason-resnick-the-right-priorities episode_number: 27 book_recommendations: - { url: "http://www.amazon.com/dp/B002MUAJ2A/?tag=devonfir-20", title: "Rework", author: "Jason Fried and David Heinemeier Hansson"} tags: - { url: "http://www.amazon.com/dp/B002MUAJ2A/?tag=devonfir-20", title: "Rework", author: "Jason Fried and David Heinemeier Hansson"} redirect_from: - "/27/" - "/027/" - "/0027/" - "/jason-resnick-the-right-priorities/" - "/Jason-Resnick/" - "/JasonResnick/" - "/Podcast/Episodes/27/" - "/Podcast/Episodes/027/" - "/Podcast/Episodes/0027/" - "/Podcast/Episodes/jason-resnick-the-right-priorities/" - "/Podcast/Episodes/Jason-Resnick/" - "/Podcast/Episodes/JasonResnick/" guid: http://developeronfire.com:80/Podcast/Episodes/jason-resnick-the-right-priorities ---
Jason Resnick is a WordPress developer and has been focused only on WordPress for several years now. He “grew up” learning Java, went down the Ruby on Rails path, all the while doing custom PHP development. WordPress made sense because he loved how the eco-system of the backend is, but more importantly the community around it. Being a part of the community is great! He’s a co-host on a monthly podcast, centered around WordPress development called WP Dev Table and try and give back to this great community in any way I can.
1. Be straightforward and honest with people
2. Be genuine
3. Be a part of your community


Garment and UV Printing
This week's task was to design and print our own T-shirt, using the Brother GT-361 printer.
This is the original picture of my football team that I chose to put on my T-shirt.
Then, using Adobe Photoshop, I touched up the photo a bit, and cropped it as I want it to show on my T-shirt.
This is the picture after the process.
Then, I opened up the file in a program called "PDIP 1.2" and adjusted the picture to a place where I wanted it to be printed on the shirt.
This is my final product of my T-shirt Printing!
Using the UV printer, I printed a picture on my phone case.
For my design, I found a picture of gucci manes tatto and uploaded it to coreldraw.
Then, I saved it as .EPS file.
So, here is my design
Because my phone is iphone 6 plus, I was able to find a case to print on in the makerspace.
I set up the UV printer and measured the height and area of the phone case using automatic measure.
Then, using Roland Versawork, I set up the position and the size of the image and printed!
Here is my result!
I had placed the case the wrong way so, it didn't print out correctly.
Download and View My Project Here
Tshirt Printing file
UV phonecase Printing


Here you can find luxury products at a great price. In addition, in honor of the new year, we have a 30% discount on all products. Not miss. Discounts are valid until 31.12.2020.


Controls:
Press Up, Down, Left, Right arrow to move
Press Z to A
Press and hold Z to turbo A
Press X to B
Press and hold X to turbo B
Press C to select
Press V to start or pause
Press R to reset
Select game:
Adventure Island 2
Battle City
Circus Charlie
Contra
Contra Force
Donkey Kong 3
Donkey Kong Jr
Double Dragon 2
Excitebike
Ice Climber
Jackal
Kung Fu
Legend Of Kage
Lode Runner
Super Mario
Mighty Final Fight
M.U.S.C.L.E
Road Fighter
Shadow Of The Ninja
Three Eye Boy
Yie-Ar Kung Fu
Play as Player 1
Room id:
Play as Player 2


Weather Dashboard
Search for a City:
Search
City Name
Date
Temp:
Wind:
Humidity:
UV Index:
5 Day Forecast:


Ruth Bader Ginsburg Back From Hospital
It was the latest in a string of health scares for the liberal Supreme Court justice.
by Kevin DaleySupreme Court Justice Ruth Bader Ginsburg returned home Sunday, following a brief hospitalization for chills and fever.
The 86-year-old justice was admitted to Johns Hopkins Hospital in Baltimore, Maryland, for evaluation and treatment of possible infections, according to a Saturday night statement from the high court. A Court spokesperson said Sunday that Ginsburg is “home and doing well.”
The justice’s discharge from Johns Hopkins on Sunday morning was expected. Saturday night’s statement indicated Ginsburg’s symptoms abated following treatment with “intravenous antibiotics and fluids.”
Saturday’s hospitalization is the latest in a series of health problems Ginsburg has had to manage in the past 12 months. Those trials began in November 2018, when she fell in her chambers at the high court and fractured three ribs.
One month later, Ginsburg was admitted to Sloan Kettering Memorial Cancer Center for a pulmonary lobectomy, a procedure which treats lung cancer. She returned to Sloan Kettering in August for outpatient radiation therapy following a pancreatic cancer diagnosis.
She also missed oral arguments Nov. 13 due to illness.
The justices will not hear cases again until Monday, Dec. 2, providing sufficient time for Ginsburg’s recovery. The high court’s December sitting featured the first Second Amendment case the justices have considered in nearly a decade.
Content created by The Daily Caller News Foundation is available without charge to any eligible news publisher that can provide a large audience. For licensing opportunities of our original content, please contact<EMAIL_ADDRESS>Image: Reuters.


hola mundo
Holy guacamole! You should check in on some of those fields below.
Holy guacamole! You should check in on some of those fields below.
Header
Primary card title
Some quick example text to build on the card title and make up the bulk of the card's content.
Header
Primary card title
Some quick example text to build on the card title and make up the bulk of the card's content.


{% extends "base.html" %} {% load staticfiles %} {% block content %} {% for row in almanacs %}
Foundations
Foundation Trilogy - A Theory of Everything
Smartest Kids in the World - An absolute must read
1984 - Dangers of the Two-Party System
Brave New World - Truly Profound
Siddhartha - On the path to Enlightenment
The Singularity is Near or the shorter Singularity Rising - Must read one
Brain Training
The Incredible Machine and Crazy Machines - Engi Practice
Perspective - 100% Free 2d / 3d crossover.
SpaceChem - Advanced Engi Practice
Antichamber - On Choice and Dimensionality
Limbo - Elegance
Schein - Hidden Viewpoints
Closure - Adjust Your Viewpoint
Ibb and Obb - Two is Smarter than One
Braid - Genre Defining
Vessel - Puzzle Platform Engi
The Swapper - A Real Challenge
The Bridge - Escher-Level Difficult
The Way Back (wiki reading)
Ouroboros - An ancient meme related to the Phoenix
Pandora's Box - The Tree of Knowledge?
Tower of Babel - Disconnect Theory?
Sisyphus - On the importance of hard work
Book of Revelations - Enlightenment
Etymologiae (what's in a name?) - Patron saint of CS
Algorithms (thanks al-Kwharizmi!)
The Renaissance - The Technological Renaissance has already begun?
Great Awakening (of society? our collective conscious?)
Convergent Evolution - Great minds think alike.
Resonance - Self-Amplification (a T.O.E.?)
Transcendence - On the path to Enlightenment
There and Back Again
Journey to the Center of the Earth
Alchemist - The moving, powerful journey of a lone shepherd
Stargate - On the Importance of Portal
Cryptonomicon - The inspiration for BitCoin?
Fifth Element - At the intersection of Old & New (aka The Middle)
Galactic Infrastructure
Spin / Axis / Vortex - Must Read
Algebraist - How to become a Seer / Disconnect Theory
Ringworld - Dyson Structure / Disconnect Theory
The Dispossessed - TPS & Disconnect Theory
Left Hand of Darkness - Evolution
On the Nature of Memory
Memento - Memory Hacking
Before I go to Sleep - Memory Hacking / Manipulation
Slaughterhouse 5 - The Ol' Switcheroo
Do Androids Dream of Electric Sheep? - Blade Runner Inspiration
Secret History of Consciousness
One Mind - Part of a Greater Consciousness and why it matters
Arch-Types and the Collective Unconscious - In contrast to the above
Empire Building
Genghis Khan and the making of the modern world - On the Power of Benevolent Empire
Confessions of an Economic Hit-Man - Non-Violent Imperialism
Dragonlance (War of Souls) - Fantasy Epic - Birth of an Empire
Rome: Rise and Fall of an Empire - The old Arch-Type for Empire Building
On the Importance of Disobedience
Fight Club - Anarchist Philosophy - Jubilee Theory
Spartacus - Today's Lannisters are less obvious
Ender's Game - At the intersection of Hate and Love
Book of the New Sun / Part 2 - SciFi Epic on Arch-Types
I am Legend - Never give up. Never surrender. I've heard great things about the book
The Giver - New Colors
Kingdom of Heaven - Pay attention to Edward Norton
Office Space - Money is not the end-all be-all
Animal Farm - How to manipulate and farm
Meme Theory
Snow Crash - Sumeria FTW
Existence - A Galactic Meme
Rendevous with Rama - Stellar Seed Theory
Future World - How to be a Leader
Ubik - Surviving Purgatory
Signs and Semiotics
Signs - On the Importance of Serendipity
Jeff Who Lives at Home - Listen to the Universe
Aleph - That Moment When..
Da Vinci Code - Semiotics Intro
Illuminati - Semiotics Follow-Up
Our-O-Boros
Primer - On the Importance of a Fail-Safe
12 Monkeys - Time Travel without One?
Pi - A singular devotion
Life of Pi - A wandering devotion
Labyrinth Guides
Ready Player One - More Almanacs Inc.
Nightfall - On the Importance of Patterns
Sirens of Titan - Go with the Flow
Through the Looking Glass - Broken Shards
Lean Startup - A Guide for Entrepreneurs
Neuromancer - A Guide for the Internet
Waiting for Godot - Who is Godot?
Common Pitfalls
Battlestar Galactica - The A.I. Wars
Minority Report - How to predict the future Irresponsibly
Cat's Cradle - A Grey Goo Dystopic
No Exit - How to get stuck
Farenheit 451 - How to devolve society
Paycheck - How to love life as a COG
Guided Compendiums
The Divine Comedy - How to Escape Hell
Canterbury Tales - How to Trigger a Renaissance
Hyperion - Tomorrow's Canterbury Tails / Disconnect Theory
Cloud Atlas - How to Transcend Time
The other Cloud Atlas - Less known but relevant
The Fifth Column (and 49 other stories) - Building Tall
The Sixth Column - Building Wide
I, Robot - Asimov meets Sherlock
Simulacra and Simulation
Simulacra and Simulation - Inspired The Matrix
Thirteenth Floor - Convergent Evolution (vis-a-vis The Matrix)
Caprica - Batttlestar Origin Story. Must watch
eXistenZ - On the Importance of Meta
Computer Science
Turing - My Intellectual Anscestor
Algorithms - How to compute efficiently
Functional Programming - How to code efficiently
Foundations of Programming Languages - How to design a language
Reversible Computing - How to use resources efficiently
Man: Computer, Ape, or Angel? - A collection of essays
Principles of Liquid Feedback - The guiding light for the DDP
The Very Small
Fantastic Voyage - Hop on the Magic School Bus
Life's Ratchet - How Molecular Machines Extract Order From Chaos
The Machinery of Life - A Picture says a Thousand Words
Universal Non-Faction
From Eternity to Here - On The Arrow of Time
The Elegant Universe - An Introduction to Modern Physics Theory
Brief History of Time - Get Caught up on the last 13.7 Billion Years
Godel, Escher, Bach: The Golden Braid - At the intersection of CS, Art, and Philosophy
Kafkaesque
Metamorphosis - When the World Doesn't Understand You
Don Quixote - When the World is Against You
Blindness - The One-Eyed Man is King
Sedaris
Squirrel Seeks Chipmunk - Fables for Today
Holidays On Ice - Fables for Family
Me Talk Pretty One Day - Memoirs


This sample demonstrates the basc styles usage.
"Little Red Riding Hood" is a famous fairy tale about a young girl's encounter with a wolf. The story has been changed considerably in its history and subject to numerous modern adaptations and readings.
| Chinese | 小紅帽 |
| Italian | Cappuccetto Rosso |
| Spanish | Caperucita Roja |
The version most widely known today is based on the Brothers Grimm variant. It is about a girl called Little Red Riding Hood, after the red hooded cape or cloak she wears. The girl walks through the woods to deliver food to her sick grandmother.
A wolf wants to eat the girl but is afraid to do so in public. He approaches the girl, and she naïvely tells him where she is going. He suggests the girl pick some flowers, which she does. In the meantime, he goes to the grandmother's house and gains entry by pretending to be the girl. He swallows the grandmother whole, and waits for the girl, disguised as the grandmother.
When the girl arrives, she notices he looks very strange to be her grandma. In most
retellings, this eventually culminates with Little Red Riding Hood saying, "My,
what big teeth you have!"
To which the wolf replies, "The better to eat you with," and swallows
her whole, too.
A hunter, however, comes to the rescue and cuts the wolf open. Little Red Riding Hood and her grandmother emerge unharmed. They fill the wolf's body with heavy stones, which drown him when he falls into a well. Other versions of the story have had the grandmother shut in the closet instead of eaten, and some have Little Red Riding Hood saved by the hunter as the wolf advances on her rather than after she is eaten.
The tale makes the clearest contrast between the safe world of the village and the dangers of the forest, conventional antitheses that are essentially medieval, though no written versions are as old as that.
—


Usually the driver is the individual who writes the code. The navigator directs the driver and stears the direction of the code. The two programmers are supposed to swithc roles frequently. The driver is supposed to focus all of his or her attention on the tactical aspects while the observer is the safety net.


{% extends 'base.html' %} {% block title %}About Me{% endblock %} {% block content %}
I am Muhammad Niaz Morshed who made this throughout learning Django Framework.
It is a simple To-Do app which enables you to add your things to do and cross or delete them when you want to organize your daily works.Its beautiful minimal design makes it look really CLEAN to me.This app is made with python 3.8, Bootstrap 4.4, HTML 5 and Django Framework. It's my very first web app in Django, so be patient.
Explore my little works