Latest Threat ResearchGlassWorm Loader Hits Open VSX via Developer Account Compromise.Details
Socket
Book a DemoInstallSign in
Socket

partly

Package Overview
Dependencies
Maintainers
1
Versions
2
Alerts
File Explorer

Advanced tools

Socket logo

Install Socket

Detect and block malicious and high-risk dependencies

Install

partly

Simple, extensible, multipart payload encoder and decoder that complies with the official RFC grammar.

latest
Source
npmnpm
Version
1.0.0
Version published
Maintainers
1
Created
Source

Partly

This module is meant to be a simple, extensible, "multipart" payload encoder and decoder. It complies with the official grammar specification located here:

  • http://tools.ietf.org/html/rfc822
  • http://tools.ietf.org/html/rfc2045
  • http://tools.ietf.org/html/rfc2046
  • http://tools.ietf.org/html/rfc2047
  • http://tools.ietf.org/html/rfc2048
  • http://tools.ietf.org/html/rfc2049

The RFC documents are also bundled with this project.

Assumptions made for simplicity:

  • RFC 822 header fields have unstructured s and s.
  • RFC 822 header fields may be in any order.
  • RFC 2045 defined header fields are RFC 822 grammar compliant.
  • RFC 2045 defined header fields all begin with "Content-".
  • RFC 2046 composite media type, "multipart", must include a global boundary parameter.
  • RFC 2046 composite media type, "multipart", encoders must not generate transport padding (WSP).
  • RFC 2046 composite media type, "multipart", decoders must gracefully handle transport padding (WSP).
  • RFC 2046 composite media type, "multipart", decoders must ignore or discard any preamble or epilogue.
  • RFC 2046 composite media type, "multipart", body parts must use RFC 822 message syntax.
  • RFC 2046 composite media type, "multipart", body parts must allow for optional header fields.
  • RFC 2046 composite media type, "multipart", body parts must make no semantic assumption regarding header fields.
  • RFC 2046 composite media type, "multipart", body parts must not contain the boundary delimiter.

Lexical Tokens:

CHAR  = <any ASCII character>                                           ; ( 0-127, %x00-7F )
ALPHA = <any ASCII alphabetic character>                                ; ( 65-90 / 97-122, %x41-5A / %x61-7A )
DIGIT = <any ASCII decimal digit>                                       ; ( 48-57, %x30-39 )
CTL   = <any ASCII control character and DEL>                           ; ( 0-31 / 127, %x00-1F / %x7F )
CR    = <ASCII CR, carriage return>                                     ; ( 13, %x0D )
LF    = <ASCII LF, linefeed>                                            ; ( 10, %x0A )
SPACE = <ASCII SP, space>                                               ; ( 32, %x20 )
HTAB  = <ASCII HT, horizontal-tab>                                      ; ( 09, %x09 )
CRLF  = CR LF                                                           ; ( 13 10, %x0D %x0A )
WSP   = SPACE / HTAB                                                    ; ( 32 / 09, %x20 %x09 )
OCTET = <any 0-255 octet value>                                         ; ( 0-255, %x00-FF )
text  = <any CHAR, including bare CR & bare LF, but NOT including CRLF>

RFC 822 Header Fields BNF:

field-name = 1*<any CHAR, excluding CTLs, SPACE, and ":">
field-body = *text [CRLF WSP field-body]
field      = field-name ":" [field-body] CRLF

RFC 2046 "Multipart" Boundary BNF:

bcharsnospace = DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" / "," / "-" / "." / "/" / ":" / "=" / "?"
bchars        = bcharsnospace / " "
boundary      = 0*69<bchars> bcharsnospace

RFC 2046 "Multipart" Body BNF:

body-part      = *field [CRLF *OCTET]
multipart-body = [*(*text CRLF) *text CRLF]                ; Optional Preamble
                 "--" boundary *WSP CRLF                   ; --F6Rxhi'v4e)(fn
                 body-part                                 ; Content-Type: application/json
                                                           ;
                                                           ; {"cool":"stuff"}
                 *(CRLF "--" boundary *WSP CRLF body-part) ; --F6Rxhi'v4e)(fn
                                                           ; Content-Type: application/json
                                                           ;
                                                           ; {"cool":"other stuff"}
                 CRLF "--" boundary "--" *WSP              ; --F6Rxhi'v4e)(fn--
                 [CRLF *(*text CRLF) *text]                ; Optional Epilogue

A Complex Multipart Example:

This message contains five parts that are to be displayed serially:

  • 2 introductory plain text objects
  • 1 embedded multipart message
  • 1 text/enriched object
  • 1 closing encapsulated text message in a non-ASCII character set

The embedded multipart message itself contains two objects to be displayed in parallel:

  • 1 picture

  • 1 audio fragment

    MIME-Version: 1.0 From: Nathaniel Borenstein nsb@nsb.fv.com To: Ned Freed ned@innosoft.com Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) Subject: A multipart example Content-Type: multipart/mixed; boundary=unique-boundary-1

    This is the preamble area of a multipart message. Mail readers that understand multipart format should ignore this preamble.

    If you are reading this text, you might want to consider changing to a mail reader that understands how to properly display multipart messages.

    --unique-boundary-1

    ... Some text appears here ...

    [Note that the blank between the boundary and the start of the text in this part means no header fields were given and this is text in the US-ASCII character set. It could have been done with explicit typing as in the next part.]

    --unique-boundary-1 Content-type: text/plain; charset=US-ASCII

    This could have been part of the previous part, but illustrates explicit versus implicit typing of body parts.

    --unique-boundary-1 Content-Type: multipart/parallel; boundary=unique-boundary-2

    --unique-boundary-2 Content-Type: audio/basic Content-Transfer-Encoding: base64

    ... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ...

    --unique-boundary-2 Content-Type: image/jpeg Content-Transfer-Encoding: base64

    ... base64-encoded image data goes here ...

    --unique-boundary-2--

    --unique-boundary-1 Content-type: text/enriched

    This is enriched. as defined in RFC 1896

    Isn't it cool?

    --unique-boundary-1 Content-Type: message/rfc822

    From: (mailbox in US-ASCII) To: (address in US-ASCII) Subject: (subject in US-ASCII) Content-Type: Text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-printable

    ... Additional text in ISO-8859-1 goes here ...

    --unique-boundary-1--

Installation

npm install partly --save

Usage

/**
 * Module Dependencies.
 */
var partly = require('partly'),
    mp = partly.multipart,
    bp = partly.bodypart;

var body = mp('mixed');

console.log(
    body
        .addBodyPart(
            bp()
                .setType('application/json')
                .setPayload('{}')
        ).toString()
);

Tests

No unit tests are currently present. Eventually:

npm test

Contributing

In lieu of a formal style guideline, take care to maintain the existing coding style.

Keywords

multipart

FAQs

Package last updated on 19 Aug 2014

Did you know?

Socket

Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.

Install

Related posts