x This domain is for sale. If you intrested, Please contact : webspeckle@gmail.com

Definition

Http status code quick reference

Status codes in the 100x range (from 100-199) are informational, and describe the processing for the request.

Status codes in the 200x range (from 200-299) indicate the action requested by the client was received, understood, accepted and processed successfully

Status codes in the 300x range (from 300-399) indicate that the client must take additional action to complete the request, such as following a redirect

Status codes in the 400x range (from 400-499) is intended for cases in which the client seems to have erred and must correct the request before continuing. The aforementioned 404 is an example of this.

Status codes in the 500x range (from 500-599) is intended for cases where the server failed to fulfill an apparently valid request.

Free file and folder comparison tool for developers

Meld is a visual diff and merge tool targeted at developers. Meld helps you compare files, directories, and version controlled projects. It provides two- and three-way comparison of both files and directories.

Meld is packaged for most Linux/Unix distributions, including Fedora, Ubuntu, and Suse. Unless you want the absolutely latest version, you should install Meld through your package manager.

Features
Two- and three-way comparison of files and directories
File comparisons update as you type
Auto-merge mode and actions on change blocks help make merges easier
Visualisations make it easier to compare your files
Supports Git, Bazaar, Mercurial, Subversion, etc.

Visit: http://meldmerge.org/

Meld is licensed under the GPL v2, except as noted. 

What is a subdomain?

Subdomain is a domain that is a part of a main domain. For example, abc.example.com. Here 'abc' is the subdomain and 'example.com' is the main domain. You can also add multiple levels of subdomains. Subdomains are different from directories. For example, example.com/abc points to a directory within the example.com domain, not to a subdomain of example.com.

The whole domain name does not exceed a total length of 255 characters, but in practice most domain registries limit at 253 characters.

What is a Domain name?

A domain name is an identification string that defines a realm of administrative autonomy, authority or control within the Internet. Domain names are formed by the rules and procedures of the Domain Name System (DNS). Any name registered in the DNS is a domain name. Domain names are used in various networking contexts and application-specific naming and addressing purposes. In general, a domain name represents an Internet Protocol (IP) resource, such as a personal computer used to access the Internet, a server computer hosting a web site, or the web site itself or any other service communicated via the Internet.

A domain name may point to multiple IP addresses to provide server redundancy for the services offered, a feature that is used to manage the traffic of large, popular web sites.

The domain name is a component of a uniform resource locator (URL) used to access web sites, for example:

https://www.google.com

In the above url
Protocol is 'https'
Subdomain is 'www'
domain name is 'google.com'

Domain names are organized in subordinate levels (subdomains) of the DNS root domain, which is nameless. The first-level set of domain names are the top-level domains (TLDs), including the generic top-level domains (gTLDs), such as the prominent domains com, info, net, edu, and org, and the country code top-level domains (ccTLDs). Below these top-level domains in the DNS hierarchy are the second-level and third-level domain names that are typically open for reservation by end-users who wish to connect local area networks to the Internet, create other publicly accessible Internet resources or run web sites.

How to store data in a web browser by using web storage?

Web storage is used for storing data in a web browser. Web storage supports persistent data storage, similar to cookies but with a greatly enhanced capacity and no information stored in the HTTP request header. There are two main web storage types: local storage and session storage, behaving similarly to persistent cookies and session cookies respectively.

Web storage can be viewed simplistically as an improvement on cookies. However, it differs from cookies in some key ways.

Storage size

Web storage provides far greater storage capacity (5 MB per origin in Google Chrome, Mozilla Firefox, and Opera; 10 MB per storage area in Internet Explorer; 25MB per origin on BlackBerry 10 devices) compared to 4 kB (around 1000 times less space) available to cookies.

Client-side interface

Unlike cookies, which can be accessed by both the server and client side, web storage falls exclusively under the purview of client-side scripting.

Web storage data is not automatically transmitted to the server in every HTTP request, and a web server can't directly write to Web storage. However, either of these effects can be achieved with explicit client-side scripts, allowing for fine-tuning of the desired interaction with the server.

Local and session storage

Web storage offers two different storage areas—local storage and session storage—which differ in scope and lifetime. Data placed in local storage is per origin (the combination of protocol, hostname, and port number as defined in the same-origin policy) (the data is available to all scripts loaded from pages from the same origin that previously stored the data) and persists after the browser is closed. Session storage is per-origin-per-window-or-tab and is limited to the lifetime of the window. Session storage is intended to allow separate instances of the same web application to run in different windows without interfering with each other, a use case that's not well supported by cookies.

Interface and data model

Web storage currently provides a better programmatic interface than cookies because it exposes an associative array data model where the keys and values are both strings.

Browsers that support web storage have the global variables sessionStorage and localStorage declared at the window level. The following JavaScript code can be used on these browsers to trigger web storage behaviour:

sessionStorage
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened) ...
alert(sessionStorage.getItem('key'));
localStorage
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
Only strings can be stored via the Storage API. Attempting to store a different data type will result in an automatic conversion into a string in most browsers. Conversion into JSON (JavaScript Object Notation), however, allows for effective storage of JavaScript objects.

// Store an object instead of a string
localStorage.setItem('key', {name: 'value'});
alert(typeof localStorage.getItem('key')); // string

// Store an integer instead of a string
localStorage.setItem('key', 1);
alert(typeof localStorage.getItem('key')); // string

// Store an object using JSON
localStorage.setItem('key', JSON.stringify({name: 'value'}));
alert(JSON.parse(localStorage.getItem('key')).name); // value

Properties

Storage.length
Returns an integer representing the number of data items stored in the Storage object.

Methods

Storage.key()
When passed a number n, this method will return the name of the nth key in the storage.

Storage.getItem()
When passed a key name, will return that key's value.

Storage.setItem()
When passed a key name and value, will add that key to the storage, or update that key's value if it already exists.

Storage.removeItem()
When passed a key name, will remove that key from the storage.

Storage.clear()
When invoked, will empty all keys out of the storage.

What is cookie?

An HTTP cookie (also called web cookie, Internet cookie, browser cookie, or simply cookie) is a small piece of data sent from a website and stored on the user's computer by the user's web browser while the user is browsing. Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items added in the shopping cart in an online store) or to record the user's browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to remember arbitrary pieces of information that the user previously entered into form fields such as names, addresses, passwords, and credit card numbers.

Other kinds of cookies perform essential functions in the modern web. Perhaps most importantly, authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in with. Without such a mechanism, the site would not know whether to send a page containing sensitive information, or require the user to authenticate themselves by logging in. The security of an authentication cookie generally depends on the security of the issuing website and the user's web browser, and on whether the cookie data is encrypted. Security vulnerabilities may allow a cookie's data to be read by a hacker, used to gain access to user data, or used to gain access (with the user's credentials) to the website to which the cookie belongs (see cross-site scripting and cross-site request forgery for examples)


A cookie consists of the following components

  1. Name
  2. Value
  3. Zero or more attributes (name/value pairs). Attributes store information such as the cookie’s expiration, domain, and flags (such as Secure and HttpOnly).

Session cookie

A session cookie, also known as an in-memory cookie or transient cookie, exists only in temporary memory while the user navigates the website. Web browsers normally delete session cookies when the user closes the browser. Unlike other cookies, session cookies do not have an expiration date assigned to them, which is how the browser knows to treat them as session cookies.

Persistent cookie

Instead of expiring when the web browser is closed as session cookies do, a persistent cookie expires at a specific date or after a specific length of time. This means that, for the cookie's entire lifespan (which can be as long or as short as its creators want), its information will be transmitted to the server every time the user visits the website that it belongs to, or every time the user views a resource belonging to that website from another website (such as an advertisement).

For this reason, persistent cookies are sometimes referred to as tracking cookies because they can be used by advertisers to record information about a user's web browsing habits over an extended period of time. However, they are also used for "legitimate" reasons (such as keeping users logged into their accounts on websites, to avoid re-entering login credentials at every visit).

These cookies are however reset if the expiration time is reached or the user manually deletes the cookie.

Secure cookie

A secure cookie can only be transmitted over an encrypted connection (i.e. HTTPS). They cannot be transmitted over unencrypted connections (i.e. HTTP). This makes the cookie less likely to be exposed to cookie theft via eavesdropping. A cookie is made secure by adding the Secure flag to the cookie.

HttpOnly cookie

An HttpOnly cookie cannot be accessed by client-side APIs, such as JavaScript. This restriction eliminates the threat of cookie theft via cross-site scripting (XSS). However, the cookie remains vulnerable to cross-site tracing (XST) and cross-site request forgery (XSRF) attacks. A cookie is given this characteristic by adding the HttpOnly flag to the cookie.

SameSite cookie

Google Chrome recently introduced a new kind of cookie which can only be sent in requests originating from the same origin as the target domain. This restriction mitigates attacks such as cross-site request forgery (XSRF).

Third-party cookie

Normally, a cookie's domain attribute will match the domain that is shown in the web browser's address bar. This is called a first-party cookie. A third-party cookie, however, belongs to a domain different from the one shown in the address bar. This sort of cookie typically appears when web pages feature content from external websites, such as banner advertisements. This opens up the potential for tracking the user's browsing history, and is often used by advertisers in an effort to serve relevant advertisements to each user.

As an example, suppose a user visits www.example.org. This web site contains an advertisement from ad.foxytracking.com, which, when downloaded, sets a cookie belonging to the advertisement's domain (ad.foxytracking.com). Then, the user visits another website, www.foo.com, which also contains an advertisement from ad.foxytracking.com, and which also sets a cookie belonging to that domain (ad.foxytracking.com). Eventually, both of these cookies will be sent to the advertiser when loading their advertisements or visiting their website. The advertiser can then use these cookies to build up a browsing history of the user across all the websites that have ads from this advertiser.

Most modern web browsers contain privacy settings that can block third-party cookies.

Supercookie

A supercookie is a cookie with an origin of a top-level domain (such as .com) or a public suffix (such as .co.uk). Ordinary cookies, by contrast, have an origin of a specific domain name, such as example.com.

Supercookies can be a potential security concern and are therefore often blocked by web browsers. If unblocked by the browser, an attacker in control of a malicious website could set a supercookie and potentially disrupt or impersonate legitimate user requests to another website that shares the same top-level domain or public suffix as the malicious website. For example, a supercookie with an origin of .com, could maliciously affect a request made to example.com, even if the cookie did not originate from example.com. This can be used to fake logins or change user information.

The term "supercookie" is sometimes used for tracking technologies that do not rely on HTTP cookies.

Zombie cookie

A zombie cookie is a cookie that is automatically recreated after being deleted. This is accomplished by storing the cookie's content in multiple locations, such as Flash Local shared object, HTML5 Web storage, and other client-side and even server-side locations. When the cookie's absence is detected, the cookie is recreated using the data stored in these locations.

What is Spring Boot?

Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that you can “just run”. We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration. You can use Spring Boot to create Java applications that can be started using java -jar or more traditional war deployments. We also provide a command line tool that runs “spring scripts”.

Most Spring Boot applications need very little Spring configuration. The most important feature of Spring Framework is Dependency Injection.

Features

  • Create stand-alone Spring applications
  • Embed Tomcat, Jetty or Undertow directly (no need to deploy WAR files)
  • Provide opinionated 'starter' POMs to simplify your Maven configuration
  • Automatically configure Spring whenever possible
  • Provide production-ready features such as metrics, health checks and externalized configuration
  • Absolutely no code generation and no requirement for XML configuration

Spring Boot auto-configuration attempts to automatically configure your Spring application based on the jar dependencies that you have added. For example, If HSQLDB is on your classpath, and you have not manually configured any database connection beans, then we will auto-configure an in-memory database.

One of the biggest advantages of packaging your application as jar and using an embedded HTTP server is that you can run your application as you would any other. Debugging Spring Boot applications is also easy; you don’t need any special IDE plugins or extensions. SpringApplication will load properties from application.properties files.

Spring Boot uses Commons Logging for all internal logging, but leaves the underlying log implementation open. Default configurations are provided for Java Util Logging, Log4J2 and Logback. In each case loggers are pre-configured to use console output with optional file output also available.

By default, If you use the ‘Starters’, Logback will be used for logging. Appropriate Logback routing is also included to ensure that dependent libraries that use Java Util Logging, Commons Logging, Log4J or SLF4J will all work correctly.

Spring Boot is well suited for web application development. You can easily create a self-contained HTTP server using embedded Tomcat, Jetty, or Undertow. Most web applications will use the spring-boot-starter-web module to get up and running quickly.

As well as REST web services, you can also use Spring MVC to serve dynamic HTML content. Spring MVC supports a variety of templating technologies including Thymeleaf, FreeMarker and JSPs. Many other templating engines also ship their own Spring MVC integrations.

Spring Boot includes auto-configuration support for the following templating engines:
  1. FreeMarker
  2. Groovy
  3. Thymeleaf
  4. Mustache

JSPs should be avoided if possible, there are several known limitations when using them with embedded servlet containers.

Spring Boot provides an /error mapping by default that handles all errors in a sensible way, and it is registered as a ‘global’ error page in the servlet container. For machine clients it will produce a JSON response with details of the error, the HTTP status and the exception message. For browser clients there is a ‘whitelabel’ error view that renders the same data in HTML format (to customize it just add a View that resolves to ‘error’). To replace the default behaviour completely you can implement ErrorController and register a bean definition of that type, or simply add a bean of type ErrorAttributes to use the existing mechanism but replace the contents.

If you want to display a custom HTML error page for a given status code, you add a file to an /error folder. Error pages can either be static HTML (i.e. added under any of the static resource folders) or built using templates. The name of the file should be the exact status code or a series mask.


What is CodeMirror?

CodeMirror is a versatile text editor implemented in JavaScript for the browser. It is specialized for editing code, and comes with a number of language modes and addons that implement more advanced editing functionality.CodeMirror is an open-source project shared under an MIT license

A rich programming API and a CSS theming system are available for customizing CodeMirror to fit your application, and extending it with new functionality.The desktop versions of the following browsers, in standards mode (HTML5 <!doctype html> recommended) are supported: Firefox (version 4 >=), Chrome,  Safari (5.2 >=),  Internet Explorer (8 >=),  Opera (9  >=). Recent versions of the iOS browser and Chrome on Android should work pretty well.

Features

  1. Support for over 100 languages out of the box
  2. A powerful, composable language mode system
  3. Autocompletion (XML)
  4. Code folding
  5. Configurable keybindings
  6. Vim, Emacs, and Sublime Text bindings
  7. Search and replace interface
  8. Bracket and tag matching
  9. Support for split views
  10. Linter integration
  11. Mixing font sizes and styles
  12. Various themes
  13. Able to resize to fit content
  14. Inline and block widgets
  15. Programmable gutters
  16. Making ranges of text styled, read-only, or atomic
  17. Bi-directional text support 


What is Hex Triplet?

A hex triplet is a six-digit, three-byte hexadecimal number used in HTML, CSS, SVG, and other computing applications to represent colors. The bytes represent the red, green and blue components of the color. One byte represents a number in the range 00 to FF (in hexadecimal notation), or 0 to 255 in decimal notation. This represents the least (0) to the most (255) intensity of each of the color components. Thus web colors specify colors in the True Color (24-bit RGB) color scheme. The hex triplet is formed by concatenating three bytes in hexadecimal notation, in the following order:

Byte 1: red value (color type red)
Byte 2: green value (color type green)
Byte 3: blue value (color type blue)

RedGreenBlue

For example, consider the color where the red/green/blue values are decimal numbers: red=36, green=104, blue=160 (a grayish-blue color). The decimal numbers 36, 104 and 160 are equivalent to the hexadecimal numbers 24, 68 and A0 respectively. The hex triplet is obtained by concatenating the 6 hexadecimal digits together, 2468A0 in this example.
If any one of the three color values is less than 16 (hex) or 10 (decimal), it must be represented with a leading zero so that the triplet always has exactly six digits. For example, the decimal triplet 4, 8, 16 would be represented by the hex digits 04, 08, 10, forming the hex triplet 040810.

The number of colors that can be represented by this system is 2563 or 224 or 166 = 16,777,216

Shorthand hexadecimal form

An abbreviated, three (hexadecimal)-digit form is used.[4] Expanding this form to the six-digit form is as simple as doubling each digit: 09C becomes 0099CC as presented on the following CSS example:

.threedigit { color: #09C;    }
.sixdigit   { color: #0099CC; } /* same color as above */

The three-digit form is described in the CSS specification, not in HTML. As a result, the three-digit form in an attribute other than "style" is not interpreted as a valid color in some browsers.

This shorthand form reduces the palette to 4,096 colors, equivalent of 12-bit color as opposed to 24-bit color using the whole six-digit form (16,777,216 colors), this limitation is sufficient for many text based documents.

What is KERMIT?

Kermit is a robust transport-independent file-transfer protocol and a large collection of software programs that implement it on a wide variety of platforms. In addition to file transfer, many of these programs also make network, dialed, and/or serial-port connections and also offer features such as terminal emulation, character-set conversion, and scripting for automation of any communication or file-management task. The Kermit Project originated at Columbia University in New York City in 1981 and remained there for 30 years. Since 2011 it is independent.

Kermit is the name of a file-transfer and -management protocol and a suite of computer programs for many types of computers that implements that protocol as well as other communication functions ranging from terminal emulation to automation of communications tasks through a high-level cross-platform scripting language. The software is transport-independent, operating over TCP/IP connections in traditional clear-text mode or secured by SSH, SSL/TLS, or Kerberos IV or V, as well as over serial-port connections, modems, and other communication methods (X.25, DECnet, various LAN protocols such as NETBIOS and LAT, parallel ports, etc, on particular platforms).
The Kermit Project was founded at the Columbia University Computer Center (now CUIT) in 1981.

The major features of the most popular Kermit programs are:

  1. Connection establishment and maintenance for a wide variety of connection methods (TCP/IP, X.25, LAN, serial port, modem, etc).
  2. Terminal emulation.
  3. Error-free file transfer.
  4. Internet protocols including Telnet, Rlogin, FTP, and HTTP.
  5. Internet security methods including Kerberos, SSL/TLS, SSH, and SRP.
  6. Character-set conversion during both terminal emulation and file transfer – a unique feature of Kermit software.
  7. Numeric and alphanumeric paging.
  8. Script programming to automate complicated or repetitive tasks. 

 Our premiere Kermit software implementations are:

Kermit 95 for Windows 95/98/ME, Windows NT/2000/XP/Vista/7/8/10, and OS/2;
C-Kermit for UNIX, VMS, VOS, and several other operating system families;
E-Kermit for embedding.
MS-DOS Kermit for DOS and Windows 3.x;
IBM Mainframe Kermit for VM/CMS, MVS/TSO, and CICS. 
Kermit protocol has developed into a sophisticated, powerful, and extensible transport-independent tool for file transfer and management, incorporating, among other things:

  • Transmission of multiple files in a single operation.
  • File attribute transmission (size, date, permissions, etc)
  • File name, record-format, and character-set conversion
  • File collision options, including an "update" feature
  • File transfer recovery (resumption of an interrupted binary-mode transfer from the point of failure)
  • Auto upload and download
  • Client/Server file transfer and management
  • Automatic per-file text/binary mode switching during file-group transmission
  • Recursive directory-tree transfer, even between unlike platforms
  • Uniform services on serial and network connections
  • An Internet Kermit Service Daemon