Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Commits on Jul 7, 2014
  1. @capflam

    Massive autotools refactoring & cleanup

    capflam authored
    Now, all makefile are generated by automake. This way, many things are more
    configurable and maintainable.
    
    Main (visible) changes:
    
     * Now, you can configure and compile Yaws outside the source directory. It is
       also possible to generate an archive for distribution, using the 'dist' target
       (from now, 'distcheck' target should always pass).
    
     * We track .erl dependencies using '-M*' flags of ERLC.
    
     * generated header 'yaws_configure.hrl' disappears. HAVE_SENDFILE,
       HAVE_ERLANG_SENDFILE and HAVE_CRYPTO_HASH macros are defined in ERLC flags.
    
     * yaws_generated:localinstall/0 function disappears (see comment about local
       install).
    
     * To create a windows installer, we just need to run the 'mkinstaller'
       target. Read win32/README.developer for details.
    
     * We use standard Erlang installation path for Yaws, relative to the erlang
       library directory (/usr/lib/erlang/lib). Now, '$(libdir)/yaws' is a link. We
       do the same for yapp application.
    
     * "local install" was removed. Now, to do a "developer install", we just need
       to set a prefix during the project configuration using --prefix option. So,
       you need to install yaws to test it.
    
     * DESTDIR variable is still supported.
    
     * scripts/make-release was rewritten to use 'dist' and 'mkinstaller' targets.
    
     * Installation of Yaws applications has slightly changed. Now they are
       installed in their own directory, in '$(localstatedir)/yaws'. So, chat
       application will be installed in '$(localstatedir)/yaws/chat', with 'www' and
       'ebin' subdirs.
    
    Main targets (others than all/install/clean....):
    
      * all           : compile Yaws
      * debug         : compile Yaws with debug flags
      * clean         : remove files produced by all or debug target
      * install       : do a proper install of Yaws
      * doc or docs   : build the documentation
      * check or test : launch tests
      * cleantest     : remove files produced by check target
      * dialyzer      : run dialyzer on Yaws
      * mkinstaller   : build an installer for windows
      * cleaninstaller: remove files produced by mkinstaller target
      * apps          : compile Yaws applications (chat,mail,wiki,yapp)
      * cleanapps     : remove files produced by apps target
      * installapps   : install Yaws applications
      * fullinstall   : install + installapps
      * fullclean     : clean + cleantest + cleanapps + cleaninstaller
    
      To install an application, run: (cd application/{APP} && make install)
    
    Of course, many things can be customized during configuration and Rebar still
    works as expected. To do an install with (almost) the same tree than with
    previous of Yaws, do:
    
      $> ./configure yawsdir=${prefix}/lib/yaws yappdir=${prefix}/lib/yapp \
            --sysconfdir=/etc --localstatedir=/var
      $> make install
    
    Here is the default installation tree on my debian:
    
       usr
        ├── lib
        │   └── erlang
        │       └── lib
        │           ├── yapp-0.4.2
        │           │   ├── doc/
        │           │   ├── ebin/
        │           │   ├── examples/
        │           │   └── priv/docroot/
        │           └── yaws-1.98
        │               ├── ebin/
        │               ├── include/
        │               └── priv/
        │               ├── examples/
        │
        ├── local/bin/yaws
        │
        ├── local/etc/init.d/yaws
        ├── local/etc/yaws/
        ├── local/etc/mail/yaws-webmail.conf
        │
        ├── local/lib/pkgconfig/yaws.pc
        ├── local/lib/yapp -> /usr/lib/erlang/lib/yapp-0.4.2
        ├── local/lib/yaws -> /usr/lib/erlang/lib/yaws-1.98
        │
        ├── local/share/doc/yaws/yaws.pdf
        ├── local/share/man/{man1,man5}/
        │
        ├── local/var/log/yaws
        ├── local/var/run/yaws
        └── local/var/yaws
            ├── chat/{ebin,www}
            ├── mail/{ebin,www}
            ├── wiki/{ebin,www}
            └── www
Commits on Feb 24, 2014
  1. @vinoski

    replace charset.def with generated yaws_charset.hrl

    vinoski authored
    Richard Carlsson pointed out in a private email that having configure
    generate the priv/charset.def file to be read and interpreted by
    src/mime_type_c.erl was overly complicated.
    
    Modify configure script and rebar.config.script to instead generate
    src/yaws_charset.hrl, and include that into src/mime_type_c.erl. Thanks to
    Richard for suggesting these simplifications.
    
    Also, enhance rebar.config.script to be able to extract the desired charset
    from the YAWS_CHARSET OS environment variable if set, thus providing rebar
    users a way to set the charset, which they couldn't do before.
    
    Fix test/t2/app_test.erl to not fail on Content-Type header tests if the
    header value contains a charset specification.
Commits on Oct 11, 2013
  1. @capflam

    Fix mime_types.erl generation for a local installation of Yaws

    capflam authored
    Without this fix, at the Yaws startup, the mime_types.erl generation fails
    on windows when Yaws is installed using the installer. It also fails for
    Yaws releases built with reltool (using rebar or autotools).
    
    Fix issue #161.
Commits on Nov 29, 2012
  1. @capflam

    Fix compilation of mime_types.erl when working directory is not 'yaws'

    capflam authored
    When mime_types.erl is generated, we must check if it is done during a Yaws
    compilation or a Yaws startup. In the first case, we must use a relative
    path for includes. Else include_lib must be used.
    This issue was reported by Andrei Zavada and avoid a compile error when the
    working directory is not 'yaws'.
    
    The mechanisms to generate and compile this file have also changed.
    
    Then, to centralize calls to yaws_generated:is_local_install/0, following
    functions was added in yaws.erl:
      get_app_dir/0, get_src_dir/0, get_ebin_dir/0, get_priv_dir/0, get_inc_dir/0
Commits on Jul 25, 2012
  1. @capflam

    Make the mime types mappings configurable

    capflam authored capflam committed
    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.
Commits on Jan 9, 2012
  1. fixed warnings about unused imports and export_all

    Richard Carlsson authored
Commits on Sep 23, 2011
  1. @vinoski

    delete chatty messages, make yaws_server upgrade-friendly (Klarna)

    vinoski authored
    Incorporate changes from Klarna (via Richard Carlsson) to delete
    chatty messages in a variety of places. These messages were for
    success cases; they were deleted because success cases should be
    quiet.
    
    Change yaws --check to take an optional --verbose option to allow
    original verbose success messages to be emitted. Also change the yaws
    script so that the --id option works for --check.
    
    Change yaws_server to make fully-qualified calls to gserv_loop to
    ensure code upgrades call into the newly-loaded module version.
Commits on May 7, 2011
  1. @tuncer @vinoski

    add rebar support (Tuncer Ayaz and Steve Vinoski)

    tuncer authored vinoski committed
    Add support for building yaws with rebar. The original configure and
    make support is kept intact.
    
    If you build with rebar you get a local install. The rebar approach
    does not support a regular install, which defaults into /usr/local. If
    you want a regular install, use configure and make.
    
    Create a new top-level contrib directory and move unused src files
    there. Also move src/benchmarks and src/contrib contents there as
    well. Remove the obsolete src/patches directory. This is all to keep
    rebar from compiling this unused code (since by default it compiles
    everything under the src dir).
    
    Move a number of build rules out of Makefiles into separate scripts so
    they can be used by both rebar and make.
    
    Modify yaws version specifier and handling to be amenable to rebar.
    
    Clean up trailing whitespace in a number of scripts and Makefiles.
    
    Use the following environment variables to customize the rebar build
    defaults:
    
    DEFAULT_CHARSET: used in mime type table (default: "")
    ERLBINDIR: e.g. /usr/local/bin
    ETCDIR: etc directory (default: ./etc)
    VARDIR: var directory (default: ./var)
Commits on Apr 20, 2011
  1. @vinoski

    major trailing whitespace cleanup

    vinoski authored
    Remove trailing whitespace in all .erl and .hrl files in the
    repository.
    
    If you're an emacs user, you can easily see trailing whitespace using
    settings like these in your ~/.emacs file:
    
    (setq-default show-trailing-whitespace t)
    (set-face-background 'trailing-whitespace "slate gray")
    
    You can also delete trailing whitespace automatically when you save
    your Erlang sources by setting the emacs before-save-hook in your
    ~/.emacs file like this:
    
    (add-hook 'before-save-hook
              '(lambda () (if (eq major-mode 'erlang-mode)
                              (delete-trailing-whitespace))))
Commits on Jul 10, 2009
  1. cgi support

    authored
Commits on Mar 6, 2009
Commits on Feb 14, 2008
  1. untabified all of yaws

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@1217 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Aug 25, 2006
  1. found errors with xref

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@1001 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Feb 14, 2006
Commits on Oct 11, 2005
  1. bad charset header genererated

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@925 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Dec 29, 2004
Commits on Jun 17, 2004
Commits on Aug 16, 2003
  1. recursion bug

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@480 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Jul 16, 2003
  1. @carsten3347

    Added CGI and PHP support.

    carsten3347 authored
    Also for a request like
         /a/b/c.xxx/d/e
    with xxx being one of `yaws', `cgi' or `php' and c.xxx being a plain
    file, /a/b/c.xxx is called with Arg#arg.pathinfo, respectively the
    environment variable PATH_INFO, set to `/d/e'.
    
    
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@459 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Nov 18, 2002
  1. ""

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@278 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Commits on Sep 2, 2002
  1. ""

    authored
    git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@144 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
Something went wrong with that request. Please try again.