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.
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.
R15B includes a fix for receiving HTTP request and header lines longer than Erlang's internal TCP buffer size of 1460 bytes. In the future we might have to allow this limit to be configurable, but for now hard-code a maximum HTTP header line size of 16384 bytes. This will have no effect for Erlang releases older than R15B.
This change allows websocket connections to be set up between browsers and the yaws server. RFC 6455 for WebSocket connections is supported, in addition to the hybi working group RFC drafts 10 to 17. The quickest way to try this out is by compiling yaws as usual, then visiting /websockets_example.yaws at the default local installation host. This can be done using Google Chrome 14+, Firefox 7+ or any other browser supporting WebSocket version 8 or above. Information about getting started with WebSockets using this implementation is given in /websockets.yaws. This drops support for the older draft RFCs, specifically those of the hixie working group which were previously supported by yaws but are significantly different from the hybi working group's specification. The interface for using WebSocket with yaws has changed somewhat. Instead of spawning a websocket owner process which maintains a server loop such as that shown in the old websockets_endpoint.yaws, the application developer now implements a callback module such as those in src/basic_echo_callback.erl or src/advanced_echo_callback.erl -- the difference being that the advanced callback style is only necessary if you need advanced features of WebSocket such as fragmented messages. One suggested way to deploy your callback module and its dependencies is as part of an application in an OTP release, with yaws as a dependency. Rebar can be used to build the dependencies, fetch and build yaws, and create a release which will ensure the modules are in the path of the runtime system. Most behaviour tested by the Autobahn test suite 0.43 pass when configured to connect to the /websockets_autobahn_endpoint.yaws and /websockets_example_endpoint.yaws over an unencrypted connection. Significantly, websocket connection closing is not implemented and the socket is left to be cleaned up by the Runtime System when either the connection is lost or the owning processes dies. Secondly, certain cases where websocket frames are fragmented within UTF-8 code points cause the check for valid text type messages to incorrectly fail the connection. Subprotocols are not currently supported. Augment yaws.tex with a new WebSocket Protocol chapter (Steve Vinoski).
At the suggestion of Tuncer Ayaz, change the return type of set_error_buffer() in the yaws sendfile driver from size_t to ErlDrvSizeT. This makes the code make more sense since the result of set_error_buffer() is sometimes used as the return value for driver callback functions.
The sed commands in yaws.app.src and rebar-pre-script were pretty picky regarding the presence of empty lines or other garbage in the vsn.mk file. Change to make sed operate only on the desired version text.
The CGI 1.1 spec (RFC 3875) requires a server to augment a CGI response with a 302 status code if that responses consists only of a HTTP Location header and optional CGI extension headers, but Yaws was not doing this. Fix this and add a unit test to verify it.
The expires header test was failing because the header time was calculated in a way that failed to account for any daylight savings time issues, specifically when the access time occurs when DST is active but the expiry time occurs after DST has ended (or vice-versa). Fixed.
…xed by per Hedeland
…xed by per Hedeland
When running in embedded mode, this function is used to setup the gconf. Currently, the soap_srv_mods field is not built and is ignored. Correct that by setting the soap_srv_mods field. Signed-off-by: Essien Ita Essien <firstname.lastname@example.org>