Misplaced Pages

#674325

85-437: JSONP is vulnerable to the data source replacing the innocuous function call with malicious code, which is why it has been superseded by cross-origin resource sharing (available since 2009) in modern applications. The HTML <script> element is generally allowed to execute JavaScript code retrieved from foreign origins. Services replying with pure JSON data, however, were not able to share data from foreign origins before

170-750: A configuration language . However, it does not support comments . In 2012, Douglas Crockford, JSON creator, had this to say about comments in JSON when used as a configuration language: "I know that the lack of comments makes some people sad, but it shouldn't. Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser." MongoDB uses JSON-like data for its document-oriented database . Some relational databases, such as PostgreSQL and MySQL, have added support for native JSON data types. This allows developers to store JSON data directly in

255-421: A zlib stream with a particular header and DEFLATE blocks with ad-hoc Huffman coding . The resulting alphanumeric-only SWF file is then used as the callback parameter of a JSONP call. High-profile sites such as Google, YouTube, Twitter, Yahoo!, Yandex, LinkedIn, eBay, GitHub, Instagram, and Tumblr were all vulnerable until July 2014. This vulnerability was initially discovered by Erling and Alok Menghrajani, with

340-455: A JSON-based format to define the structure of JSON data for validation, documentation, and interaction control. It provides a contract for the JSON data required by a given application and how that data can be modified. JSON Schema is based on the concepts from XML Schema (XSD) but is JSON-based. As in XSD, the same serialization/deserialization tools can be used both for the schema and data, and it

425-413: A JSONP call looks like this: After the element is injected, the browser evaluates the element, and performs an HTTP GET on the src URL, retrieving the content. Then the browser evaluates the return payload as JavaScript. This is typically a function invocation. In that way, the use of JSONP can allow browser pages to work around the same-origin policy via script element injection. The script runs within

510-411: A Web server by holding two Hypertext Transfer Protocol (HTTP) connections open and recycling them before standard browser time-outs if no further data were exchanged. The cofounders had a round-table discussion and voted on whether to call the data format JSML (JavaScript Markup Language) or JSON (JavaScript Object Notation), as well as under what license type to make it available. The JSON.org website

595-466: A function call) wrapped around it. This "wrapped payload" is then interpreted by the browser. In this way, a function that is already defined in the JavaScript environment can manipulate the JSON data. A typical JSONP request and response are shown below. The function call to parseResponse() is the "P" of JSONP—the "padding" or "prefix" around the pure JSON. For JSONP to work, a server must reply with

680-554: A malicious page can request and obtain JSON data belonging to another site. This will allow the JSON-encoded data to be evaluated in the context of the malicious page, possibly divulging passwords or other sensitive data if the user is currently logged into the other site. Rosetta Flash is an exploitation technique that allows an attacker to exploit servers with a vulnerable JSONP endpoint by causing Adobe Flash Player to believe that an attacker-specified Flash applet originated on

765-467: A practice which would have destroyed interoperability." JSON disallows "trailing commas", a comma after the last value inside a data structure. Trailing commas are a common feature of JSON derivatives to improve ease of use. RFC 8259 describes certain aspects of JSON syntax that, while legal per the specifications, can cause interoperability problems. In 2015, the IETF published RFC 7493, describing

850-424: A public presentation at a security conference. The exploitation of the vulnerability was subsequently improved by Gábor Molnár. Google security engineer Michele Spagnuolo coined the term and has CVE - 2014-4671 and CVE- 2014-5333 . Adobe Flash Player release version 14.0.0.145, released on 8 July 2014, introduced stronger validation of Flash files, and in version 14.0.0.176, released on 12 August 2014, finalized

935-513: A relational database without having to convert it to another data format. JSON being a subset of JavaScript can lead to the misconception that it is safe to pass JSON texts to the JavaScript eval () function. This is not safe, due to certain valid JSON texts, specifically those containing U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR , not being valid JavaScript code until JavaScript specifications were updated in 2019, and so older engines may not support it. To avoid

SECTION 10

#1732780201675

1020-424: A replacement for XML-RPC or SOAP . It is a simple protocol that defines only a handful of data types and commands. JSON-RPC lets a system send notifications (information to the server that does not require a response) and multiple calls to the server that can be answered out of order. Asynchronous JavaScript and JSON (or AJAJ) refers to the same dynamic web page methodology as Ajax , but instead of XML , JSON

1105-495: A response that includes the JSONP function. JSONP does not work with JSON-formatted results. The JSONP function invocation that gets sent back, and the payload that the function receives, must be agreed upon by the client and server. By convention, the server providing the JSON data offers the requesting website to name the JSONP function, typically using the name jsonp or callback as the named query-string parameter, in its request to

1190-509: A single message. The root part would contain the HTML document, and use image tags to reference images stored in the latter parts. The type is defined in RFC 2387. multipart/report is a message type that contains data formatted for a mail server to read. It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for

1275-469: A single value and each attribute can appear at most once on each element. XML separates "data" from "metadata" (via the use of elements and attributes), while JSON does not have such a concept. Another key difference is the addressing of values. JSON has objects with a simple "key" to "value" mapping, whereas in XML addressing happens on "nodes", which all receive a unique ID via the XML processor. Additionally,

1360-553: A system. The system was sold to Sun Microsystems , Amazon.com , and EDS . JSON was based on a subset of the JavaScript scripting language (specifically, Standard ECMA -262 3rd Edition—December 1999 ) and is commonly used with JavaScript, but it is a language-independent data format. Code for parsing and generating JSON data is readily available in many programming languages . JSON's website lists JSON libraries by language. In October 2013, Ecma International published

1445-510: A valid JSON text must consist of only an object or an array type, which could contain other types within them. This restriction was dropped in RFC   7158 , where a JSON text was redefined as any serialized value. Numbers in JSON are agnostic with regard to their representation within programming languages. While this allows for numbers of arbitrary precision to be serialized, it may lead to portability issues. For example, since no differentiation

1530-439: A variety of multipart types. This mechanism supports (non-exhaustively): The original MIME specifications only described the structure of mail messages. They did not address the issue of presentation styles. The content-disposition header field was added in RFC 2183 to specify the presentation style. A MIME part can have: In addition to the presentation style, the field Content-Disposition also provides parameters for specifying

1615-543: A whole does not have a charset; non-ASCII characters in the part headers are handled by the Encoded-Word system, and the part bodies can have charsets specified if appropriate for their content-type. Notes: The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another. The subtype is specified in the Content-Type header field of

1700-400: Is a commonly used data format with diverse uses in electronic data interchange , including that of web applications with servers . JSON is a language-independent data format. It was derived from JavaScript , but many modern programming languages include code to generate and parse JSON-format data. JSON filenames use the extension .json . Douglas Crockford originally specified

1785-474: Is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822". The MIME type is defined in RFC 2046. The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The order of the parts is significant. RFC1341 states: In general, user agents that compose multipart/alternative entities should place

SECTION 20

#1732780201675

1870-514: Is allowed and ignored around or between syntactic elements (values and punctuation, but not within a string value). Four specific characters are considered whitespace for this purpose: space , horizontal tab , line feed , and carriage return . In particular, the byte order mark must not be generated by a conforming implementation (though it may be accepted when parsing JSON). JSON does not provide syntax for comments . Early versions of JSON (such as specified by RFC   4627 ) required that

1955-470: Is also owned by 3DO ). Upon discovery of early Ajax capabilities, digiGroups, Noosh, and others used frames to pass information into the user browsers' visual field without refreshing a Web application's visual context, realizing real-time rich Web applications using only the standard HTTP, HTML, and JavaScript capabilities of Netscape 4.0.5+ and Internet Explorer 5+. Crockford then found that JavaScript could be used as an object-based messaging format for such

2040-520: Is also valid JavaScript syntax. The specification was started in 2012 and finished in 2018 with version 1.0.0. The main differences to JSON syntax are: JSON5 syntax is supported in some software as an extension of JSON syntax, for instance in SQLite . JSONC (JSON with Comments) is a subset of JSON5 used in Microsoft's Visual Studio Code : Several serialization formats have been built on or from

2125-531: Is an example of how local factors may affect how an application chooses which "best" part of the message to display. While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, anti-spam filters would only examine the text/plain part of a message, because it is easier to parse than the text/html part. But spammers eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in

2210-498: Is defined in RFC 1847. A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are identified by their separate content types for the control part. The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" ( S/MIME ). The MIME type defined in RFC 1847. The MIME type multipart/form-data

2295-523: Is interpreted as "Subject: ¡Hola, señor!". The encoded-word format is not used for the names of the headers fields (for example Subject ). These names are usually English terms and always in ASCII in the raw message. When viewing a message with a non-English email client, the header field names might be translated by the client. The MIME multipart message contains a boundary in the header field Content-Type: ; this boundary, which must not occur in any of

2380-532: Is known as script element injection . The <script> element is injected into the HTML DOM, with the URL of the desired JSONP endpoint set as the "src" attribute. This dynamic script element injection is usually done by a JavaScript helper library. jQuery and other frameworks have JSONP helper functions; there are also standalone options. An example of using jQuery to dynamically inject script element for

2465-422: Is made between integer and floating-point values, some implementations may treat 42 , 42.0 , and 4.2E+1 as the same number, while others may not. The JSON standard makes no requirements regarding implementation details such as overflow , underflow , loss of precision, rounding, or signed zeros , but it does recommend expecting no more than IEEE 754 binary64 precision for "good interoperability". There

2550-405: Is necessary is the serialization of data types that are not part of the JSON standard, for example, dates and regular expressions . The official MIME type for JSON text is application/json , and most modern implementations have adopted this. Legacy MIME types include text/json , text/x-json , and text/javascript . The standard filename extension is .json. JSON Schema specifies

2635-535: Is no inherent precision loss in serializing a machine-level binary representation of a floating-point number (like binary64) into a human-readable decimal representation (like numbers in JSON) and back since there exist published algorithms to do this exactly and optimally. Comments were intentionally excluded from JSON. In 2012, Douglas Crockford described his design decision thus: "I removed comments from JSON because I saw people were using them to hold parsing directives,

JSONP - Misplaced Pages Continue

2720-401: Is not a data interchange language. CBOR has a superset of the JSON data types, but it is not text-based. Ion is also a superset of JSON, with a wider range of primary types, annotations, comments, and allowing trailing commas. XML has been used to describe structured data and to serialize objects. Various XML-based protocols exist to represent the same kind of data structures as JSON for

2805-465: Is not the fifth version of JSON). YAML version 1.2 is a superset of JSON; prior versions were not strictly compatible. For example, escaping a slash / with a backslash \ is valid in JSON, but was not valid in YAML. YAML supports comments, while JSON does not. CSON (" CoffeeScript Object Notation") uses significant indentation , unquoted keys, and assumes an outer object declaration. It

2890-437: Is now used by many Web 2.0 applications such as Dojo Toolkit and Google Web Toolkit . JSON JSON ( JavaScript Object Notation , pronounced / ˈ dʒ eɪ s ən / or / ˈ dʒ eɪ ˌ s ɒ n / ) is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of name–value pairs and arrays (or other serializable values). It

2975-452: Is self-describing. It is specified in an Internet Draft at the IETF, with the latest version as of 2024 being "Draft 2020-12". There are several validators available for different programming languages, each with varying levels of conformance. The JSON standard does not support object references , but an IETF draft standard for JSON-based object references exists. JSON-RPC is a remote procedure call (RPC) protocol built on JSON, as

3060-540: Is the current version of the Internet Standard STD 90, and it remains consistent with ECMA-404. That same year, JSON was also standardized as ISO/IEC 21778:2017. The ECMA and ISO/IEC standards describe only the allowed syntax, whereas the RFC covers some security and interoperability considerations. JSON grew out of a need for a real-time server-to-browser session communication protocol without using browser plugins such as Flash or Java applets,

3145-472: Is the data format. AJAJ is a web development technique that provides for the ability of a web page to request new data after it has loaded into the web browser . Typically, it renders new data from the server in response to user actions on that web page. For example, what the user types into a search box , client-side code then sends to the server, which immediately responds with a drop-down list of matching database items. JSON has seen ad hoc usage as

3230-412: Is used for sending files with different Content-Type header fields inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless explicitly specified with Content-Disposition: attachment in which case offered as attachments). The default content-type for each part is "text/plain". The type is defined in RFC 2046. multipart/digest

3315-491: The IANA's list of transfer encodings define the values shown below, which are not case sensitive. '7bit', '8bit', and 'binary' mean that no binary-to-text encoding on top of the original encoding was used. In these cases, the header field is actually redundant for the email client to decode the message body, but it may still be useful as an indicator of what type of object is being sent. Values ' quoted-printable ' and ' base64 ' tell

3400-551: The Internet Engineering Task Force obsoleted RFC   7159 when it published RFC   8259 , which is the current version of the Internet Standard STD 90. Crockford added a clause to the JSON license stating, "The Software shall be used for Good, not Evil", in order to open-source the JSON libraries while mocking corporate lawyers and those who are overly pedantic. On the other hand, this clause led to license compatibility problems of

3485-647: The Simple Mail Transfer Protocol (SMTP), the Post Office Protocol (POP), and the Internet Message Access Protocol (IMAP). MIME is an Internet standard . It is specified in a series of requests for comments : RFC 2045 , RFC 2046 , RFC 2047 , RFC 4288 , RFC 4289 and RFC 2049 . The integration with SMTP email is specified in RFC 1521 and RFC 1522 . Although

JSONP - Misplaced Pages Continue

3570-523: The Unicode line terminators U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR to appear unescaped in quoted strings, while ECMAScript 2018 and older do not. This is a consequence of JSON disallowing only "control characters". For maximum portability, these characters should be backslash-escaped. JSON exchange in an open ecosystem must be encoded in UTF-8 . The encoding supports

3655-452: The content-disposition fields in the messages and uses independent algorithms for selecting the MIME parts to display automatically. Thunderbird prior to version 3 also sends out newly composed messages with inline content disposition for all MIME parts. Most users are unaware of how to set the content disposition to attachment . Many mail user agents also send messages with the file name in

3740-407: The name parameter of the content-type header instead of the filename parameter of the header field Content-Disposition . This practice is discouraged, as the file name should be specified either with the parameter filename , or with both the parameters filename and name . In HTTP, the response header field Content-Disposition: attachment is usually used as a hint to the client to present

3825-411: The "I-JSON Message Format", a restricted profile of JSON that constrains the syntax and processing of JSON to avoid, as much as possible, these interoperability issues. While JSON provides a syntactic framework for data interchange, unambiguous data interchange also requires agreement between producer and consumer on the semantics of specific use of the JSON syntax. One example of where such an agreement

3910-569: The Andrew Messaging System, which was part of Andrew Project developed at Carnegie Mellon University (CMU), as a cross-platform alternative to the Andrew-specific data format. The presence of this header field indicates the message is MIME-formatted. The value is typically "1.0". The field appears as follows: According to MIME co-creator Nathaniel Borenstein , the version number was introduced to permit changes to

3995-517: The JSON format in the early 2000s. He and Chip Morningstar sent the first JSON message in April 2001. The 2017 international standard (ECMA-404 and ISO/IEC 21778:2017) specifies that "JSON" is "pronounced / ˈ dʒ eɪ . s ə n / , as in ' Jason and The Argonauts ' ". The first (2013) edition of ECMA-404 did not address the pronunciation. The UNIX and Linux System Administration Handbook states, " Douglas Crockford , who named and promoted

4080-423: The JSON format, says it's pronounced like the name Jason. But somehow, 'JAY-sawn' seems to have become more common in the technical community." Crockford said in 2011, "There's a lot of argument about how you pronounce that, but I strictly don't care." After RFC 4627 had been available as its "informational" specification since 2006, JSON was first standardized in 2013, as ECMA -404. RFC 8259, published in 2017,

4165-438: The JSON license with other open-source licenses since open-source software and free software usually imply no restrictions on the purpose of use. The following example shows a possible JSON representation describing a person. Although Crockford originally asserted that JSON is a strict subset of JavaScript and ECMAScript , his specification actually allows valid JSON documents that are not valid JavaScript; JSON allows

4250-507: The JSON specification. Examples include MIME Multipurpose Internet Mail Extensions ( MIME ) is a standard that extends the format of email messages to support text in character sets other than ASCII , as well as attachments of audio, video, images, and application programs. Message bodies may consist of multiple parts, and header information may be specified in non-ASCII character sets. Email messages with MIME formatting are typically transmitted with standard protocols, such as

4335-478: The MIME encoded-word syntax (RFC 2047) instead of a literal string. This syntax uses a string of ASCII characters indicating both the original character encoding (the " charset ") and the content-transfer-encoding used to map the bytes of the charset into ASCII characters. The form is: " =? charset ? encoding ? encoded text ?= ". The ASCII codes for the question mark ("?") and equals sign ("=") may not be represented directly as they are used to delimit

SECTION 50

#1732780201675

4420-564: The MIME formalism was designed mainly for SMTP, its content types are also important in other communication protocols . In the HyperText Transfer Protocol (HTTP) for the World Wide Web , servers insert a MIME header field at the beginning of any Web transmission. Clients use the content type or media type header to select an appropriate viewer application for the type of data indicated. MIME originated from

4505-418: The MIME protocol in subsequent versions. However, Borenstein admitted short-comings in the specification that hindered the implementation of this feature: "We did not adequately specify how to handle a future MIME version. ... So if you write something that knows 1.0, what should you do if you encounter 2.0 or 1.1? I sort of thought it was obvious but it turned out everyone implemented that in different ways. And

4590-447: The XML standard defines a common attribute xml:id , that can be used by the user, to set an ID explicitly. XML tag names cannot contain any of the characters !"#$ %&'()*+,/;<=>?@[\]^`{|}~ , nor a space character, and cannot begin with - , . , or a numeric digit, whereas JSON keys can (even if quotation mark and backslash must be escaped). XML values are strings of characters , with no built-in type safety . XML has

4675-462: The adoption of CORS ( Cross-origin resource sharing ). For example, a request to a foreign service http://server.example.com/Users/1234 may return a record for a person named Clem in the JSON format. JSON syntax is consistent with JavaScript's object syntax. Without support for CORS, an attempt to use the data across domains results in a JavaScript error. The browser will download the <script> file, evaluate its contents, misinterpret

4760-415: The body parts in increasing order of preference, that is, with the preferred format last. Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this. Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places

4845-553: The concept of schema , that permits strong typing, user-defined types, predefined tags, and formal structure, allowing for formal validation of an XML stream. JSON has several types built-in and has a similar schema concept in JSON Schema . XML supports comments, while JSON does not. Support for comments and other features have been deemed useful, which has led to several nonstandard JSON supersets being created. Among them are HJSON, HOCON, and JSON5 (which despite its name,

4930-406: The constituent parts. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by Content-ID . The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part. One common usage of this subtype is to send a web page complete with images in

5015-475: The dominant methods used in the early 2000s. Crockford first specified and popularized the JSON format. The acronym originated at State Software, a company cofounded by Crockford and others in March 2001. The cofounders agreed to build a system that used standard browser capabilities and provided an abstraction layer for Web developers to create stateful Web applications that had a persistent duplex connection to

5100-705: The email client that a binary-to-text encoding scheme was used and that appropriate initial decoding is necessary before the message can be read with its original encoding (e.g. UTF-8). There is no encoding defined which is explicitly designed for sending arbitrary binary data through SMTP transports with the 8BITMIME extension. Thus, if BINARYMIME isn't supported, base64 or quoted-printable (with their associated inefficiency) are sometimes still useful. This restriction does not apply to other uses of MIME such as Web Services with MIME attachments or MTOM . Since RFC 2822, conforming message header field names and values use ASCII characters; values that contain non-ASCII data should use

5185-536: The encoded word. The ASCII code for space may not be represented directly because it could cause older parsers to split up the encoded word undesirably. To make the encoding smaller and easier to read the underscore is used to represent the ASCII code for space creating the side effect that underscore cannot be represented directly. The use of encoded words in certain parts of header fields imposes further restrictions on which characters may be represented directly. For example, Subject: =?iso-8859-1?Q?=A1Hola,_se=F1or!?=

SECTION 60

#1732780201675

5270-437: The first edition of its JSON standard ECMA-404. That same year, RFC   7158 used ECMA-404 as a reference. In 2014, RFC   7159 became the main reference for JSON's Internet uses, superseding RFC   4627 and RFC   7158 (but preserving ECMA-262 and ECMA-404 as main references). In November 2017, ISO/IEC JTC 1/SC 22 published ISO/IEC 21778:2017 as an international standard. On December 13, 2017,

5355-507: The fix, preventing this exploit from working. Prior to Adobe's fix, websites could protect themselves by prepending an empty JavaScript comment (/**/) or even just a newline as the first bytes of the JSONP response. In July 2005, George Jempty suggested an optional variable assignment be prepended to JSON. The original proposal for JSONP, where the padding is a callback function, appears to have been made by Bob Ippolito in December 2005 and

5440-616: The full Unicode character set, including those characters outside the Basic Multilingual Plane (U+0000 to U+FFFF). However, if escaped, those characters must be written using UTF-16 surrogate pairs . For example, to include the Emoji character U+1F610 😐 NEUTRAL FACE in JSON: JSON became a strict subset of ECMAScript as of the language's 2019 revision. JSON's basic data types are: Whitespace

5525-481: The language's 2019 revision. Various JSON parser implementations have suffered from denial-of-service attack and mass assignment vulnerability . JSON is promoted as a low-overhead alternative to XML as both of these formats have widespread support for creation, reading, and decoding in the real-world situations where they are commonly used. Apart from XML, examples could include CSV and supersets of JSON. Google Protocol Buffers can fill this role, although it

5610-432: The mail server to read. The type is defined in RFC 6522. A multipart/signed message is used to attach a digital signature to a message. It has exactly two body parts, a body part and a signature part. The whole of the body part, including mime fields, is used to create the signature part. Many signature types are possible, like "application/pgp-signature" (RFC 3156) and "application/pkcs7-signature" ( S/MIME ). The type

5695-520: The many pitfalls caused by executing arbitrary code from the Internet, a new function, JSON . parse () , was first added to the fifth edition of ECMAScript, which as of 2017 is supported by all major browsers. For non-supported browsers, an API-compatible JavaScript library is provided by Douglas Crockford . In addition, the TC39 proposal "Subsume JSON" made ECMAScript a strict JSON superset as of

5780-419: The name of the file, the creation date and modification date, which can be used by the reader's mail user agent to store the attachment. The following example is taken from RFC 2183, where the header field is defined: The filename may be encoded as defined in RFC 2231. As of 2010, a majority of mail user agents did not follow this prescription fully. The widely used Mozilla Thunderbird mail client ignores

5865-507: The overall message. For example, a multipart MIME message using the digest subtype would have its Content-Type set as "multipart/digest". The RFC initially defined four subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognized subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs. multipart/mixed

5950-440: The parts, is placed between the parts, and at the beginning and end of the body of the message, as follows: Each part consists of its own content header (zero or more Content- header fields) and a body. Multipart content can be nested. The Content-Transfer-Encoding of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as

6035-499: The plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages. Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one HTML (text/html) . The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this

6120-420: The raw JSON data as a block, and throw a syntax error. Even if the data were interpreted as a JavaScript object literal, it could not be accessed by JavaScript running in the browser, since without a variable assignment, object literals are inaccessible. In the JSONP usage pattern, the URL request pointed to by the src attribute in the <script> element returns JSON data, with JavaScript code (usually

6205-510: The remote servers to inject any content into a website. If the remote servers have vulnerabilities that allow JavaScript injection, the page served from the original server is exposed to an increased risk. If an attacker can inject any JavaScript into the original web page, then that code can retrieve additional JavaScript from any domain, bypassing the same-origin policy . The Content Security Policy HTTP Header lets web sites tell web browsers which domain scripts may be included from. An effort

6290-505: The response body as a downloadable file. Typically, when receiving such a response, a Web browser prompts the user to save its content as a file, instead of displaying it as a page in a browser window, with filename suggesting the default file name. In June 1992, MIME (RFC 1341, since made obsolete by RFC 2045) defined a set of methods for representing binary data in formats other than ASCII text format. The content-transfer-encoding: MIME header field has 2-sided significance: The RFC and

6375-419: The restrictions associated with application/json content type, as demonstrated in reflected file download (RFD) attack from 2014. Insecure JSONP endpoints can be also injected with malicious data. Naive deployments of JSONP are subject to cross-site request forgery (CSRF or XSRF) attacks. Because the HTML <script> element does not respect the same-origin policy in web browser implementations,

6460-428: The result is that it would be just about impossible for the Internet to ever define a 2.0 or a 1.1." This header field indicates the media type of the message content, consisting of a type and subtype , for example Through the use of the multipart type, MIME allows mail messages to have parts arranged in a tree structure where the leaf nodes are any non-multipart content type and the non-leaf nodes are any of

6545-427: The same kind of data interchange purposes. Data can be encoded in XML in several ways. The most expansive form using tag pairs results in a much larger (in character count) representation than JSON, but if data is stored in attributes and 'short tag' form where the closing tag is replaced with /> , the representation is often about the same size as JSON or just a little larger. However, an XML attribute can only have

6630-519: The same problems as resolving JSON with eval() : both interpret the JSON text as JavaScript, which meant differences in handling U+2028 ( Line Separator ) and U+2029 ( Paragraph Separator ) from JSON proper. This made some JSON strings non-legal in JSONP; servers serving JSONP had to escape these characters prior to transmission. This issue has now been rectified in ES2019. Unsanitized callback names may be used to pass malicious data to clients, bypassing

6715-482: The scope of the including page and, as such, is still subject to cross-domain restrictions relative to the domain of the including page. This means that a web page cannot, for example, load a library hosted on another site via JSONP and then make XMLHttpRequest requests to that site (unless cross-origin resource sharing (CORS) is supported), although one could use such a library to make XMLHttpRequests to one's own site. Including script elements from remote servers allows

6800-420: The server: <script src="http://server.example.com/Users/1234?callback=parseResponse"></script> . In this example, the received payload would be: JSONP makes sense only when used with a script element. For each new JSONP request, the browser must add a new <script> element, or reuse an existing one. The former option—adding a new script element—is done via dynamic DOM manipulation, and

6885-448: The text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message. The type is defined in RFC 2046. A multipart/related is used to indicate that each message part is a component of an aggregate whole. It is for compound objects consisting of several inter-related components – proper display cannot be achieved by individually displaying

6970-464: The vulnerable server. Flash Player implements same-origin policy allowing one to make requests (with cookies) and receive responses from the hosting site. The applet can then send the retrieved data back to the attacker. This is a cross-origin exploit with an impact similar to embedding an arbitrary Flash applet in the vulnerable domain. The exploit uses an ActionScript payload compiled to an SWF file composed entirely of alphanumeric characters by crafting

7055-493: Was launched in 2001. In December 2005, Yahoo! began offering some of its Web services in JSON. A precursor to the JSON libraries was used in a children's digital asset trading game project named Cartoon Orbit at Communities.com (the State cofounders had all worked at this company previously) for Cartoon Network , which used a browser side plug-in with a proprietary messaging format to manipulate DHTML elements (this system

7140-456: Was undertaken around 2011 to define a safer strict subset definition for JSONP that browsers would be able to enforce on script requests with a specific MIME type such as "application/json-p". If the response did not parse as strict JSONP, the browser could throw an error or just ignore the entire response. However, this approach was abandoned in favor of CORS , and the correct MIME type for JSONP remains application/javascript . JSONP carried

7225-426: Was used for configuring GitHub 's Atom text editor . There is also an unrelated project called CSON ("Cursive Script Object Notation") that is more syntactically similar to JSON. HOCON ("Human-Optimized Config Object Notation") is a format for human-readable data, and a superset of JSON. The uses of HOCON are: JSON5 ("JSON5 Data Interchange Format") is an extension of JSON syntax that, just like JSON,

#674325