{"push_id":1283284940,"size":5,"distinct_size":0,"ref":"refs/heads/master","head":"51911f2a53b8e99dc9b64ca5b299bb00f61207c0","before":"1208b6891aaba53ec7855b91e784f402dd0f6834","commits":[{"sha":"810bcb6f379c50716b8b847d524f997bc09857d6","author":{"name":"Christopher Faulet","email":"3b8e36f1e7f6424fef3040527dc0a9bf37237787@capflam.org"},"message":"Use MOD:module_info/1 instead of erlang:function_exported/3 in yaws_dynopts\n\nerlang:function_exported/3 doesn't load the requested module. So, it always\nreturns false if the module was not previously loaded. So, in certain\ncircumstances, yaws_dynopts returns the wrong value.\nInstead, we use MOD:module_info/1 to retrieve the same information. So, we are\nsure to load the module.","distinct":false,"url":"https://api.github.com/repos/klacke/yaws/commits/810bcb6f379c50716b8b847d524f997bc09857d6"},{"sha":"96888a99a2e13a88dd7868561156ded57f8bd593","author":{"name":"Christopher Faulet","email":"3b8e36f1e7f6424fef3040527dc0a9bf37237787@capflam.org"},"message":"Check \"Transfer-Encoding\" header first, before \"Content-Length\" header\n\nUsually, when \"Transfer-Encoding\" header is set to \"chunk\", \"Content-Length\"\nheader is not set. So it is safe to check these headers in any order. In Yaws,\n\"Content-Length\" header was checked first.\nBut, some clients (e.g. inets) set the \"Content-Length\" header to 0 when the\nbody is chunked. So, in this situation, the body was skipped by Yaws. And with\npersistant connections, subsequent requests was rejected.\n\nSo, to be compliant with these buggy clients, we check \"Transfer-Encoding\"\nheader first to know if the body is chunked. Then, if not, we check\n\"Content-Length\" header to know the body size.","distinct":false,"url":"https://api.github.com/repos/klacke/yaws/commits/96888a99a2e13a88dd7868561156ded57f8bd593"},{"sha":"df1d7bf67f8afcaef20e8e7af0974e5436a0a863","author":{"name":"Christopher Faulet","email":"3b8e36f1e7f6424fef3040527dc0a9bf37237787@capflam.org"},"message":"Rework how random ports are handled\n\nIt is possible to let Yaws choose the listening port of a server by leaving it\nto 0. Now, this port is chosen during the configuration parsing. There are 2\nreasons to do it this way:\n\n  * First, the #sconf record has the real listening port instead of 0. This\n    avoids the checks to get it. This is also convenient to have it when the\n    configuration is retrieved or dumped.\n\n  * Then, if there are 2 or more servers configured to use a random port, each\n    one will have its own port. Each server will be isolated in its own group.\n    So it is possible to have in same time a HTTP and a HTTPS vhost using a\n    random port.\n\nThere is a drawback when the configuration is reloaded. All servers will be\nrestarted and will use a new listening port. But random ports are used for test\npurposes so this is not really an issue.\n\nWe use IANA range for dynamic or private ports (49152 -> 65535) to choose a\nport. We try to find the first free port in this range. An environment variable\nis used to know the last assigned random port (attached to the kernel\napplication, so it is possible to reserve ports manually before Yaws is\nstarted).\n\nThis new feature is mainly used by the new testsuite.","distinct":false,"url":"https://api.github.com/repos/klacke/yaws/commits/df1d7bf67f8afcaef20e8e7af0974e5436a0a863"},{"sha":"fc7c0deebdd70c9db719c0a5ed4d0b4faba8929c","author":{"name":"Christopher Faulet","email":"3b8e36f1e7f6424fef3040527dc0a9bf37237787@capflam.org"},"message":"Refactor the testsuite to use common_test instead of a in-house framework\n\nThe testsuite has been rewritten to use Erlang common_test framework.\nInternally, eunit is used to check results. The TS can be launched with the\n'make check' command. It is only available with the autotools.\n\ntestsuite/README.md describes how the testsuite works, how to launch specific\nsuites or testcases and how to write new tests.\n\nibrowse dependency has been removed. So it is possible to run the TS without\nconnectivity. We use a custom HTTP client to do checks. So it is easy to adapt\nit when needed. The API to write new tests is in the module\ntestsuite/testsuite.erl.","distinct":false,"url":"https://api.github.com/repos/klacke/yaws/commits/fc7c0deebdd70c9db719c0a5ed4d0b4faba8929c"},{"sha":"51911f2a53b8e99dc9b64ca5b299bb00f61207c0","author":{"name":"Christopher Faulet","email":"3b8e36f1e7f6424fef3040527dc0a9bf37237787@capflam.org"},"message":"Upload build artifacts producted by Travis on external repo\n\nBecause Travis logs are not suffisant to find bugs when the testsuites execution\nfail, we upload build artifcats on an extern repository.\n\nFor now, this is done on github, in the repository\ncapflam/yaws-travis-build-artifacts. There is no versionning, we just create new\nrelease for each travis build and add assets in its release.","distinct":false,"url":"https://api.github.com/repos/klacke/yaws/commits/51911f2a53b8e99dc9b64ca5b299bb00f61207c0"}]}
{"actor":{"display_login":"capflam"}}