Skip to content
This repository

Feb 11, 2013

  1. Christopher Faulet

    Refactor WebSockets and add support of optional callback functions

    Main changes:
      * Fix some bugs about UTF-8 encoding and messages fragmentation
      * Add support of optional callback functions
      * Add support of many startup options
      * Add support of outgoing fragmented messages
      * Add a websocket testsuite
    
                                     - * -
    *** bug fixes ***
    
    First of all, an huge part of yaws_websocket.erl was rewritten to fix bugs
    about the messages fragmentation and the UTF-8 encoding of incoming text
    messages:
    
      * UTF-8 encoding
        before, when a text message was fragmented, only the first frame was
        checked and partial UTF-8 sequences were not supported. Now, checks
        are done on each message part and a partial UTF-8 sequence at the end
        of a frame is accumulated and checked with the next frame (for basic
        callback only).
    
      * Messages fragmentation
        for basic callback modules, because of a buggy mapping between frames
        and messages, the messages fragmentation was almost unusable. To fix
        this, the message handling was rewritten.
    
    Now, all tests in the autobahn testsuite[1] pass successfully.
    
                                     - * -
    *** Optional callback functions ***
    
    Then, from an idea of François de Metz[2], yaws_websocket module was
    extended to support optional callback functions. See the documentation for
    details (www/websockets.yaws).
    
    Quickly, optional callback functions are:
    
      * Module:init/1           (for basic and advanced callback modules)
      * Module:terminate/2      (for basic and advanced callback modules)
      * Module:handle_open/2    (for basic and advanced callback modules)
      * Module:handle_info/2    (for basic and advanced callback modules)
      * Module:handle_message/2 (for basic callback modules only, used in place
                                 of Module:handle_message/1)
    
    Thanks to Pablo Vieytes[3] which added handle_info to optional callback
    functions.
                                     - * -
    *** Startup options ***
    
    To start a websocket process a script must return the following term from
    its out/1 function:
    
      {websocket, CallbackMod, Options}
    
    where 'Options' is a (possibly empty) proplist. Following parameters are
    supported:
    
      * {origin, Orig}
      * {callback, Type}
      * {keepalive, Boolean}
      * {keepalive_timeout, Tout}
      * {keepalive_grace_period, Time}
      * {drop_on_timeout, Boolean}
      * {close_timeout, Tout}
      * {close_if_unmasked, Boolean}
      * {max_frame_size, Int}
      * {max_message_size, Int}
      * {auto_fragment_message, Boolean}
      * {auto_fragment_threshold, Int}
    
    See the documentation for details (www/websockets.yaws).
    
                                     - * -
    *** Outgoing fragmented messages ***
    
    A callback module can now send fragmented messages to clients using the
    record #ws_frame{}:
    
     #ws_frame{fin     = true,  %% true | false
               rsv     = 0,
               opcode,          %% text | binary | continuation...
               payload = <<>>}. %% binary(), unmasked data
    
    --
    [1] http://autobahn.ws/testsuite
    [2] #99
    [3] https://github.com/pvieytes
    capflam authored

Nov 15, 2012

  1. Christopher Faulet

    Extend syntax of redirect block to allow an optional status code

    Now, it is possible to change the HTTP status code used in redirect rules.
    Supported formats are:
    
       Path = URL
       Path = code
       Path = code URL
    
    * '==' syntax instead of '=' is always valid.
    * If no status code is defined, Yaws will perform a 302 redirect.
    * For 3xx status codes, the URL parameter must be present and will be used
      to build the new location.
    * For other status codes (1xx, 2xx, 4xx and 5xx), it can be omitted. In the
      absence of URL, Yaws will return a generic response with the specified
      status code. Otherwise, the URL parameter must be a relative URL and will
      be used to customize the response.
    
    For example:
    
      <redirect>
        /foo = http://yaws.hyber.org  # (1)
        /bar = 301 /foo               # (2)
        /baz = 404                    # (3)
        /qux = 403 /forbidden.yaws    # (4)
      </redirect>
    
    (1) do a 302 redirect on 'http://yaws.hyber.org/foo/...';
    (2) do a 301 redirect on 'scheme:host:port/bar/...'
    (3) return a generic 404 error
    (4) do a reentrant call to '/forbidden.yaws' by setting the status code
        to 403.
    
    Note: this new feature is fully compatible with older one.
    capflam authored vinoski committed

Oct 13, 2012

  1. Steve Vinoski

    WebDAV compliancy rework (Tjeerd van der Laan)

    The WebDAV support is reworked and adds class 1, 2 and 3 compliancy
    which includes:
    
    * XML request body parsing and  multistatus responses
    
    * PROPFIND and PROPPATCH methods returning properties asked for
    
    * all RFC4918 properties, the Apache executable property plus some
      Microsoft extensions
    
    * locking mechanism (class 2 compliancy) on all destructive methods
    
    * If header parsing
    vinoski authored

Aug 25, 2012

  1. Steve Vinoski

    make sure "rebar eunit" passes

    When using yaws as an app dependency for another application built with
    rebar, I noticed that testing that application with "rebar eunit" would
    fail while testing yaws. It was easy to work around with "rebar eunit
    skip_deps=true" but yaws really should pass its tests when tested via
    rebar.
    
    Change rebar.config to add ibrowse as a dependency. It's used only for
    testing, but rebar doesn't support test-only dependencies, plus it's
    filtered out during release generation anyway.
    
    Modify some of the test files to be able to find ibrowse include files
    regardless of whether they're built via make or via rebar. Also rename all
    non-eunit test functions ending in "_test" so they don't confuse eunit. Also
    had to move the embedded_yaws_id_dir test from eunit to t2 because it fails
    under "rebar eunit" when yaws is a dependency for another app. It fails
    because it calls into the yaws_api:embedded_start_conf function which tries
    to call application:load(yaws), but paths aren't properly set up to allow
    that to work under these testing circumstances.
    
    Note that not all tests currently run under rebar; building with make and
    then running "make test" results in many more tests being executed. Fixing
    this will come later.
    vinoski authored

Jul 25, 2012

  1. Christopher Faulet

    Make the mime types mappings configurable

    Now, it possible to customize the global mime types mappings and to overload
    it for each virtual server. It can be done using following directives in the
    global part or the server part of the configuration:
    
    * default_type: Defines the default mime type to be used where Yaws cannot
      determine it by its mime types mappings (default: text/plain).
      In the server part, this directive overloads the global one.
    
    * default_charset: Defines the default charset to be added when a response
      content-type is text/* (default: none). In the server part, this directive
      overloads the global one.
    
    * mime_types_file: Overrides the default mime.types file included with Yaws
      (default: ${PREFIX}/lib/yaws/priv/mime.types). In the server part, this
      directive overloads the global one but mappings defined in this file will
      not overload those defined by add_types directives in the global part.
    
    * add_types: Specifies one or more mappings between mime types and file
      extensions. More than one extension can be assigned to a mime type. If a
      mapping is defined in the global part and redefined in a server part using
      this directive, then the later is used. Else the global one is kept.
    
    * add_charsets: Specifies one or more mappings between charsets and file
      extensions. More than one extension can be assigned to a charset. If a
      mapping is defined in the global part and redefined in a server part using
      this directive, then the later is used. Else the global one is kept.
    
    Here is an example:
    
      default_type = text/html
    
      <server localhost>
          port = 8000
          listen = 0.0.0.0
          docroot = /var/www
          # nothing is overloaded in the vhost
      </server>
    
      <server localhost>
          port = 8001
          listen = 0.0.0.0
          docroot = /var/www
    
          # overload global configuration:
          default_type    = text/plain
          mime_types_file = /etc/mime.types
          add_types       = <text/xhtml, yaws> <application/x-test, tst test>
          default_charset = UTF-8
          add_charsets    = <ISO-8859-1, php html yaws> <US-ASCII, tst>
      </server>
    
    During Yaws compilation, a default module 'mime_types' is created using the
    default mime.types file. Then, when yaws starts up, this module is
    re-generated, re-compiled and loaded dynamically. The new module replaces the
    default one but the .beam file is unchanged. So if one of these steps failed,
    we fall back on the default module.
    capflam authored capflam committed

Jun 27, 2012

  1. Steve Vinoski

    loosen docroot checking for certain server configs

    For server configurations that define a reverse proxy, redirection for the
    path "/", forward proxies, or appmods on "/", a docroot isn't
    needed. Change yaws_config to avoid errors for missing docroot settings for
    such servers. Add test/t6 to check these configurations.
    vinoski authored

Jun 11, 2012

  1. Steve Vinoski

    handle large non-chunked content in yaws_revproxy

    Use partial_post_size as a block size to handle large non-chunked content
    from backend servers in yaws_revproxy. Read the content block by block,
    returning each block to the client as it arrives. This avoids having to
    read the entire backend response into memory before replying to the
    client. Add a test for this new functionality and fix .gitignore to ignore
    the new content file used for the test.
    vinoski authored

May 11, 2012

  1. Christopher Faulet

    Add support for precompressed static files

    By setting use_gzip_static to true in deflate options, in a vhost
    configuration, It is possible to serve precompressed versions of
    static files. Yaws will look for precompressed files in the same
    location as original files that end in ".gz".
    
    Only files that do not fit in the cache are concerned and the mtime
    of a precompressed file must be higher than the one of original file.
    capflam authored

Apr 25, 2012

  1. Christopher Faulet

    Add options to configure deflate compression behaviour

    By adding "<deflate> ... </deflate>" structure in vhosts configuration,
    it is possible to configure how deflate compression will be applied
    and when it will come into effect. Now we can:
    
     * define the smallest response size that will be compressed
     * define the compression level to be used
     * specify the zlib compression window size
     * specify how much memory should be allocated for the internal
       compression state
     * choose the strategy used to tune the compression algorithm
    
    All these parameters are used when a zlib stream is initialized for
    compression.
    
    It is also possible to define all compressible mime types.
    Here is an example:
    
    <server localhost>
      ...
      deflate = true
      <deflate>
        min_compress_size = 4096
        compression_level = best_compression
        mime_types        = defaults, image/*
        mime_types        = application/xml, application/xhtml+xml, application/rss+xml
        mem_level         = 9
        strategy          = default
        window_size       = 15
      </deflate>
      ...
    </server>
    capflam authored

Apr 24, 2012

  1. Steve Vinoski

    add rebar dependencies needed for SOAP applications

    Use rebar.config.script to dynamically add SOAP dependencies if the shell
    environment variable YAWS_SOAP is set. This way, Yaws users not interested
    in SOAP do not need these dependencies.
    vinoski authored
  2. Steve Vinoski

    change dialyzer Makefile targets to handle known warnings

    At the suggestion of Tuncer Ayaz, modify the dialyzer targets to use the
    new known_dialyzer_warnings file to ignore all known dialyzer warnings.
    vinoski authored

Mar 06, 2012

  1. Christopher Faulet

    Update gitignore file

    capflam authored

Dec 21, 2011

  1. Tuncer Ayaz

    Add reltool based release support

    Running "rebar generate" now creates a self-contained yaws system
    under the build directory's "rel" subdirectory. The yaws script it
    provides at ./rel/yaws/bin/yaws isn't the same as the normal yaws
    script (the one normally found at ./bin/yaws); rather, it's a special
    script that starts yaws and the Erlang applications on which it
    depends as a local self-contained Erlang node. You can run
    
    ./rel/yaws/bin/yaws console
    
    to start an interactive yaws node, or
    
    ./rel/yaws/bin/yaws start
    
    to run it as a daemon, which you can later stop with
    
    ./rel/yaws/bin/yaws stop
    
    This script does not accept the command-line options that ./bin/yaws
    does, at least for now. If this is a problem, please raise an issue at
    the Yaws github repo or on the Yaws mailing list.
    tuncer authored vinoski committed
  2. Steve Vinoski

    make "rebar compile" install under the build dir

    A "rebar compile" used to install yaws, yaws.conf, and other files
    under the user's home directory, just like "make local_install". This
    approach isn't idiomatic to rebar usage, so change it to install files
    locally under the build directory. Starting ./bin/yaws from the build
    directory starts this local installation.
    vinoski authored

Jul 17, 2011

  1. Steve Vinoski

    add yapp.app to .gitignore

    vinoski authored

May 28, 2011

  1. Christopher Faulet

    add tests for authentication mechanisms

    capflam authored vinoski committed
  2. Christopher Faulet

    add a test for external interpretation of php scripts

    capflam authored vinoski committed

May 23, 2011

  1. Christopher Faulet

    add yaws.appup.src template file (capflam)

    Add yaws.appup.src template file used to build the final yaws.appup
    file. Also add ebin/yaws.appup to .gitignore.
    capflam authored vinoski committed

Apr 10, 2011

  1. Steve Vinoski

    add applications/wiki/scripts files to .gitignore

    vinoski authored

Mar 03, 2011

  1. Steve Vinoski

    avoid keeping our own copy of ibrowse

    Remove our copy of ibrowse in our test directory from git
    control. Instead, download ibrowse master from github if we don't have
    a fresh copy. Track master HEAD to make sure we have the latest.
    
    Change test/Makefile to fetch ibrowse if needed as part of building
    the "all" target.
    
    Add test/ibrowse to .gitignore.
    vinoski authored

Jul 24, 2010

  1. Steve Vinoski

    add generated doc files to .gitignore

    vinoski authored

Apr 12, 2010

  1. Steve Vinoski

    add www/*.txt files, which are generated by tests

    vinoski authored

Apr 10, 2010

  1. Steve Vinoski

    add files generated by tests and more build-generated files

    vinoski authored

Jun 09, 2009

  1. Added a .gitignore to file to ignore generated files, this makes 'git…

    … status' a lot more readable.
    Fabian Alenius authored
Something went wrong with that request. Please try again.