From c807880f7ac73f813b2660ea81a00f7712a4e793 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Hoguin?= Date: Mon, 29 Aug 2016 12:39:49 +0200 Subject: Add old mailing list archives --- _build/static/archives/extend/2012-December.txt | 591 +++ .../archives/extend/2012-December/000018.html | 67 + .../archives/extend/2012-December/000019.html | 77 + .../archives/extend/2012-December/000020.html | 78 + .../archives/extend/2012-December/000021.html | 92 + .../archives/extend/2012-December/000022.html | 81 + .../archives/extend/2012-December/000023.html | 95 + .../archives/extend/2012-December/000024.html | 131 + .../archives/extend/2012-December/000025.html | 157 + .../archives/extend/2012-December/000026.html | 206 + .../archives/extend/2012-December/000027.html | 115 + .../archives/extend/2012-December/author.html | 97 + .../static/archives/extend/2012-December/date.html | 97 + .../archives/extend/2012-December/index.html | 1 + .../archives/extend/2012-December/subject.html | 97 + .../archives/extend/2012-December/thread.html | 117 + _build/static/archives/extend/2012-November.txt | 418 +++ .../archives/extend/2012-November/000007.html | 74 + .../archives/extend/2012-November/000008.html | 81 + .../archives/extend/2012-November/000009.html | 88 + .../archives/extend/2012-November/000010.html | 68 + .../archives/extend/2012-November/000011.html | 76 + .../archives/extend/2012-November/000012.html | 73 + .../archives/extend/2012-November/000013.html | 81 + .../archives/extend/2012-November/000014.html | 102 + .../archives/extend/2012-November/000015.html | 110 + .../archives/extend/2012-November/000016.html | 129 + .../archives/extend/2012-November/000017.html | 76 + .../archives/extend/2012-November/author.html | 102 + .../static/archives/extend/2012-November/date.html | 102 + .../archives/extend/2012-November/index.html | 1 + .../archives/extend/2012-November/subject.html | 102 + .../archives/extend/2012-November/thread.html | 121 + _build/static/archives/extend/2012-October.txt | 195 + .../archives/extend/2012-October/000000.html | 77 + .../archives/extend/2012-October/000001.html | 93 + .../archives/extend/2012-October/000002.html | 66 + .../archives/extend/2012-October/000003.html | 74 + .../archives/extend/2012-October/000004.html | 68 + .../archives/extend/2012-October/000005.html | 82 + .../archives/extend/2012-October/000006.html | 93 + .../archives/extend/2012-October/author.html | 82 + .../static/archives/extend/2012-October/date.html | 82 + .../static/archives/extend/2012-October/index.html | 1 + .../archives/extend/2012-October/subject.html | 82 + .../archives/extend/2012-October/thread.html | 97 + _build/static/archives/extend/2013-April.txt | 3953 ++++++++++++++++++++ .../static/archives/extend/2013-April/000073.html | 82 + .../static/archives/extend/2013-April/000074.html | 78 + .../static/archives/extend/2013-April/000075.html | 66 + .../static/archives/extend/2013-April/000076.html | 196 + .../static/archives/extend/2013-April/000077.html | 213 ++ .../static/archives/extend/2013-April/000078.html | 68 + .../static/archives/extend/2013-April/000079.html | 76 + .../static/archives/extend/2013-April/000080.html | 87 + .../static/archives/extend/2013-April/000081.html | 156 + .../static/archives/extend/2013-April/000082.html | 172 + .../static/archives/extend/2013-April/000083.html | 179 + .../static/archives/extend/2013-April/000084.html | 192 + .../static/archives/extend/2013-April/000085.html | 208 + .../static/archives/extend/2013-April/000086.html | 66 + .../static/archives/extend/2013-April/000087.html | 78 + .../static/archives/extend/2013-April/000088.html | 75 + .../static/archives/extend/2013-April/000089.html | 86 + .../static/archives/extend/2013-April/000090.html | 97 + .../static/archives/extend/2013-April/000091.html | 107 + .../static/archives/extend/2013-April/000092.html | 83 + .../static/archives/extend/2013-April/000093.html | 120 + .../static/archives/extend/2013-April/000094.html | 132 + .../static/archives/extend/2013-April/000095.html | 137 + .../static/archives/extend/2013-April/000096.html | 149 + .../static/archives/extend/2013-April/000097.html | 152 + .../static/archives/extend/2013-April/000098.html | 68 + .../static/archives/extend/2013-April/000099.html | 80 + .../static/archives/extend/2013-April/000100.html | 89 + .../static/archives/extend/2013-April/000101.html | 102 + .../static/archives/extend/2013-April/000102.html | 112 + .../static/archives/extend/2013-April/000103.html | 122 + .../static/archives/extend/2013-April/000104.html | 127 + .../static/archives/extend/2013-April/000105.html | 143 + .../static/archives/extend/2013-April/000106.html | 152 + .../static/archives/extend/2013-April/000107.html | 93 + .../static/archives/extend/2013-April/000108.html | 88 + .../static/archives/extend/2013-April/000109.html | 104 + .../static/archives/extend/2013-April/000110.html | 149 + .../static/archives/extend/2013-April/000111.html | 165 + .../static/archives/extend/2013-April/000112.html | 119 + .../static/archives/extend/2013-April/000113.html | 172 + .../static/archives/extend/2013-April/000114.html | 98 + .../static/archives/extend/2013-April/000115.html | 110 + .../static/archives/extend/2013-April/000116.html | 151 + .../static/archives/extend/2013-April/000117.html | 166 + .../static/archives/extend/2013-April/000118.html | 178 + .../static/archives/extend/2013-April/000119.html | 212 ++ .../static/archives/extend/2013-April/000120.html | 229 ++ .../static/archives/extend/2013-April/000121.html | 66 + .../static/archives/extend/2013-April/000122.html | 76 + .../static/archives/extend/2013-April/000123.html | 87 + .../static/archives/extend/2013-April/000124.html | 122 + .../static/archives/extend/2013-April/000125.html | 140 + .../static/archives/extend/2013-April/000126.html | 90 + .../static/archives/extend/2013-April/000127.html | 75 + .../static/archives/extend/2013-April/author.html | 322 ++ _build/static/archives/extend/2013-April/date.html | 322 ++ .../static/archives/extend/2013-April/index.html | 1 + .../static/archives/extend/2013-April/subject.html | 322 ++ .../static/archives/extend/2013-April/thread.html | 431 +++ _build/static/archives/extend/2013-August.txt | 2765 ++++++++++++++ .../static/archives/extend/2013-August/000176.html | 68 + .../static/archives/extend/2013-August/000177.html | 71 + .../static/archives/extend/2013-August/000178.html | 79 + .../static/archives/extend/2013-August/000179.html | 73 + .../static/archives/extend/2013-August/000180.html | 77 + .../static/archives/extend/2013-August/000181.html | 94 + .../static/archives/extend/2013-August/000182.html | 88 + .../static/archives/extend/2013-August/000183.html | 80 + .../static/archives/extend/2013-August/000184.html | 103 + .../static/archives/extend/2013-August/000185.html | 82 + .../static/archives/extend/2013-August/000186.html | 94 + .../static/archives/extend/2013-August/000187.html | 124 + .../static/archives/extend/2013-August/000188.html | 70 + .../static/archives/extend/2013-August/000189.html | 71 + .../static/archives/extend/2013-August/000190.html | 94 + .../static/archives/extend/2013-August/000191.html | 75 + .../static/archives/extend/2013-August/000192.html | 125 + .../static/archives/extend/2013-August/000193.html | 72 + .../static/archives/extend/2013-August/000194.html | 71 + .../static/archives/extend/2013-August/000195.html | 138 + .../static/archives/extend/2013-August/000196.html | 70 + .../static/archives/extend/2013-August/000197.html | 74 + .../static/archives/extend/2013-August/000198.html | 77 + .../static/archives/extend/2013-August/000199.html | 71 + .../static/archives/extend/2013-August/000200.html | 79 + .../static/archives/extend/2013-August/000201.html | 80 + .../static/archives/extend/2013-August/000202.html | 92 + .../static/archives/extend/2013-August/000203.html | 94 + .../static/archives/extend/2013-August/000204.html | 80 + .../static/archives/extend/2013-August/000205.html | 75 + .../static/archives/extend/2013-August/000206.html | 82 + .../static/archives/extend/2013-August/000207.html | 112 + .../static/archives/extend/2013-August/000208.html | 80 + .../static/archives/extend/2013-August/000209.html | 88 + .../static/archives/extend/2013-August/000210.html | 159 + .../static/archives/extend/2013-August/000211.html | 99 + .../static/archives/extend/2013-August/000212.html | 130 + .../static/archives/extend/2013-August/000213.html | 150 + .../static/archives/extend/2013-August/000214.html | 145 + .../static/archives/extend/2013-August/000215.html | 182 + .../static/archives/extend/2013-August/000216.html | 161 + .../static/archives/extend/2013-August/000217.html | 202 + .../static/archives/extend/2013-August/000218.html | 179 + .../static/archives/extend/2013-August/000219.html | 213 ++ .../static/archives/extend/2013-August/000220.html | 228 ++ .../static/archives/extend/2013-August/000221.html | 63 + .../static/archives/extend/2013-August/000222.html | 77 + .../static/archives/extend/2013-August/000223.html | 90 + .../static/archives/extend/2013-August/000224.html | 72 + .../static/archives/extend/2013-August/000225.html | 85 + .../static/archives/extend/2013-August/000226.html | 102 + .../static/archives/extend/2013-August/author.html | 302 ++ .../static/archives/extend/2013-August/date.html | 302 ++ .../static/archives/extend/2013-August/index.html | 1 + .../archives/extend/2013-August/subject.html | 302 ++ .../static/archives/extend/2013-August/thread.html | 385 ++ _build/static/archives/extend/2013-December.txt | 260 ++ .../archives/extend/2013-December/000314.html | 74 + .../archives/extend/2013-December/000315.html | 91 + .../archives/extend/2013-December/000316.html | 79 + .../archives/extend/2013-December/000317.html | 74 + .../archives/extend/2013-December/000318.html | 87 + .../archives/extend/2013-December/000319.html | 155 + .../archives/extend/2013-December/000320.html | 60 + .../archives/extend/2013-December/author.html | 82 + .../static/archives/extend/2013-December/date.html | 82 + .../archives/extend/2013-December/index.html | 1 + .../archives/extend/2013-December/subject.html | 82 + .../archives/extend/2013-December/thread.html | 97 + _build/static/archives/extend/2013-February.txt | 948 +++++ .../archives/extend/2013-February/000043.html | 93 + .../archives/extend/2013-February/000044.html | 115 + .../archives/extend/2013-February/000045.html | 134 + .../archives/extend/2013-February/000046.html | 69 + .../archives/extend/2013-February/000047.html | 77 + .../archives/extend/2013-February/000048.html | 86 + .../archives/extend/2013-February/000049.html | 74 + .../archives/extend/2013-February/000050.html | 100 + .../archives/extend/2013-February/000051.html | 72 + .../archives/extend/2013-February/000052.html | 119 + .../archives/extend/2013-February/000053.html | 131 + .../archives/extend/2013-February/000054.html | 68 + .../archives/extend/2013-February/000055.html | 71 + .../archives/extend/2013-February/000056.html | 131 + .../archives/extend/2013-February/000057.html | 95 + .../archives/extend/2013-February/000058.html | 137 + .../archives/extend/2013-February/000059.html | 77 + .../archives/extend/2013-February/000060.html | 74 + .../archives/extend/2013-February/000061.html | 70 + .../archives/extend/2013-February/000062.html | 65 + .../archives/extend/2013-February/000063.html | 78 + .../archives/extend/2013-February/000064.html | 78 + .../archives/extend/2013-February/000065.html | 119 + .../archives/extend/2013-February/author.html | 162 + .../static/archives/extend/2013-February/date.html | 162 + .../archives/extend/2013-February/index.html | 1 + .../archives/extend/2013-February/subject.html | 162 + .../archives/extend/2013-February/thread.html | 205 + _build/static/archives/extend/2013-January.txt | 1000 +++++ .../archives/extend/2013-January/000028.html | 133 + .../archives/extend/2013-January/000029.html | 154 + .../archives/extend/2013-January/000030.html | 175 + .../archives/extend/2013-January/000031.html | 212 ++ .../archives/extend/2013-January/000032.html | 236 ++ .../archives/extend/2013-January/000033.html | 77 + .../archives/extend/2013-January/000034.html | 79 + .../archives/extend/2013-January/000035.html | 79 + .../archives/extend/2013-January/000036.html | 80 + .../archives/extend/2013-January/000037.html | 74 + .../archives/extend/2013-January/000038.html | 86 + .../archives/extend/2013-January/000039.html | 90 + .../archives/extend/2013-January/000040.html | 77 + .../archives/extend/2013-January/000041.html | 112 + .../archives/extend/2013-January/000042.html | 92 + .../archives/extend/2013-January/author.html | 122 + .../static/archives/extend/2013-January/date.html | 122 + .../static/archives/extend/2013-January/index.html | 1 + .../archives/extend/2013-January/subject.html | 122 + .../archives/extend/2013-January/thread.html | 151 + _build/static/archives/extend/2013-July.txt | 1977 ++++++++++ .../static/archives/extend/2013-July/000152.html | 94 + .../static/archives/extend/2013-July/000153.html | 113 + .../static/archives/extend/2013-July/000154.html | 93 + .../static/archives/extend/2013-July/000155.html | 102 + .../static/archives/extend/2013-July/000156.html | 141 + .../static/archives/extend/2013-July/000157.html | 161 + .../static/archives/extend/2013-July/000158.html | 175 + .../static/archives/extend/2013-July/000159.html | 195 + .../static/archives/extend/2013-July/000160.html | 196 + .../static/archives/extend/2013-July/000161.html | 224 ++ .../static/archives/extend/2013-July/000162.html | 103 + .../static/archives/extend/2013-July/000163.html | 118 + .../static/archives/extend/2013-July/000164.html | 142 + .../static/archives/extend/2013-July/000165.html | 153 + .../static/archives/extend/2013-July/000166.html | 162 + .../static/archives/extend/2013-July/000167.html | 70 + .../static/archives/extend/2013-July/000168.html | 173 + .../static/archives/extend/2013-July/000169.html | 195 + .../static/archives/extend/2013-July/000170.html | 68 + .../static/archives/extend/2013-July/000171.html | 78 + .../static/archives/extend/2013-July/000172.html | 85 + .../static/archives/extend/2013-July/000173.html | 99 + .../static/archives/extend/2013-July/000174.html | 109 + .../static/archives/extend/2013-July/000175.html | 119 + .../static/archives/extend/2013-July/author.html | 167 + _build/static/archives/extend/2013-July/date.html | 167 + _build/static/archives/extend/2013-July/index.html | 1 + .../static/archives/extend/2013-July/subject.html | 167 + .../static/archives/extend/2013-July/thread.html | 211 ++ _build/static/archives/extend/2013-June.txt | 80 + .../static/archives/extend/2013-June/000150.html | 96 + .../static/archives/extend/2013-June/000151.html | 86 + .../static/archives/extend/2013-June/author.html | 57 + _build/static/archives/extend/2013-June/date.html | 57 + _build/static/archives/extend/2013-June/index.html | 1 + .../static/archives/extend/2013-June/subject.html | 57 + .../static/archives/extend/2013-June/thread.html | 59 + _build/static/archives/extend/2013-March.txt | 161 + .../static/archives/extend/2013-March/000066.html | 73 + .../static/archives/extend/2013-March/000067.html | 73 + .../static/archives/extend/2013-March/000068.html | 62 + .../static/archives/extend/2013-March/000069.html | 93 + .../static/archives/extend/2013-March/000070.html | 74 + .../static/archives/extend/2013-March/000071.html | 83 + .../static/archives/extend/2013-March/000072.html | 67 + .../static/archives/extend/2013-March/author.html | 82 + _build/static/archives/extend/2013-March/date.html | 82 + .../static/archives/extend/2013-March/index.html | 1 + .../static/archives/extend/2013-March/subject.html | 82 + .../static/archives/extend/2013-March/thread.html | 93 + _build/static/archives/extend/2013-May.txt | 961 +++++ _build/static/archives/extend/2013-May/000128.html | 63 + _build/static/archives/extend/2013-May/000129.html | 65 + _build/static/archives/extend/2013-May/000130.html | 75 + _build/static/archives/extend/2013-May/000131.html | 92 + _build/static/archives/extend/2013-May/000132.html | 95 + _build/static/archives/extend/2013-May/000133.html | 79 + _build/static/archives/extend/2013-May/000134.html | 95 + _build/static/archives/extend/2013-May/000135.html | 110 + _build/static/archives/extend/2013-May/000136.html | 96 + _build/static/archives/extend/2013-May/000137.html | 69 + _build/static/archives/extend/2013-May/000138.html | 106 + _build/static/archives/extend/2013-May/000139.html | 77 + _build/static/archives/extend/2013-May/000140.html | 134 + _build/static/archives/extend/2013-May/000141.html | 95 + _build/static/archives/extend/2013-May/000142.html | 121 + _build/static/archives/extend/2013-May/000143.html | 102 + _build/static/archives/extend/2013-May/000144.html | 120 + _build/static/archives/extend/2013-May/000145.html | 71 + _build/static/archives/extend/2013-May/000146.html | 80 + _build/static/archives/extend/2013-May/000147.html | 88 + _build/static/archives/extend/2013-May/000148.html | 96 + _build/static/archives/extend/2013-May/000149.html | 141 + _build/static/archives/extend/2013-May/author.html | 157 + _build/static/archives/extend/2013-May/date.html | 157 + _build/static/archives/extend/2013-May/index.html | 1 + .../static/archives/extend/2013-May/subject.html | 157 + _build/static/archives/extend/2013-May/thread.html | 201 + _build/static/archives/extend/2013-November.txt | 619 +++ .../archives/extend/2013-November/000294.html | 111 + .../archives/extend/2013-November/000295.html | 122 + .../archives/extend/2013-November/000296.html | 71 + .../archives/extend/2013-November/000297.html | 80 + .../archives/extend/2013-November/000298.html | 88 + .../archives/extend/2013-November/000299.html | 71 + .../archives/extend/2013-November/000300.html | 71 + .../archives/extend/2013-November/000301.html | 64 + .../archives/extend/2013-November/000302.html | 78 + .../archives/extend/2013-November/000303.html | 70 + .../archives/extend/2013-November/000304.html | 103 + .../archives/extend/2013-November/000305.html | 77 + .../archives/extend/2013-November/000306.html | 92 + .../archives/extend/2013-November/000307.html | 77 + .../archives/extend/2013-November/000308.html | 68 + .../archives/extend/2013-November/000309.html | 98 + .../archives/extend/2013-November/000310.html | 75 + .../archives/extend/2013-November/000311.html | 82 + .../archives/extend/2013-November/000312.html | 76 + .../archives/extend/2013-November/000313.html | 79 + .../archives/extend/2013-November/author.html | 147 + .../static/archives/extend/2013-November/date.html | 147 + .../archives/extend/2013-November/index.html | 1 + .../archives/extend/2013-November/subject.html | 147 + .../archives/extend/2013-November/thread.html | 183 + _build/static/archives/extend/2013-October.txt | 2737 ++++++++++++++ .../archives/extend/2013-October/000255.html | 69 + .../archives/extend/2013-October/000256.html | 82 + .../archives/extend/2013-October/000257.html | 129 + .../archives/extend/2013-October/000258.html | 149 + .../archives/extend/2013-October/000259.html | 165 + .../archives/extend/2013-October/000260.html | 68 + .../archives/extend/2013-October/000261.html | 87 + .../archives/extend/2013-October/000262.html | 95 + .../archives/extend/2013-October/000263.html | 108 + .../archives/extend/2013-October/000264.html | 134 + .../archives/extend/2013-October/000265.html | 132 + .../archives/extend/2013-October/000266.html | 189 + .../archives/extend/2013-October/000267.html | 197 + .../archives/extend/2013-October/000268.html | 100 + .../archives/extend/2013-October/000269.html | 83 + .../archives/extend/2013-October/000270.html | 102 + .../archives/extend/2013-October/000271.html | 113 + .../archives/extend/2013-October/000272.html | 132 + .../archives/extend/2013-October/000273.html | 156 + .../archives/extend/2013-October/000274.html | 183 + .../archives/extend/2013-October/000275.html | 84 + .../archives/extend/2013-October/000276.html | 98 + .../archives/extend/2013-October/000277.html | 118 + .../archives/extend/2013-October/000278.html | 142 + .../archives/extend/2013-October/000279.html | 81 + .../archives/extend/2013-October/000280.html | 91 + .../archives/extend/2013-October/000281.html | 83 + .../archives/extend/2013-October/000282.html | 105 + .../archives/extend/2013-October/000283.html | 87 + .../archives/extend/2013-October/000284.html | 73 + .../archives/extend/2013-October/000285.html | 97 + .../archives/extend/2013-October/000286.html | 117 + .../archives/extend/2013-October/000287.html | 103 + .../archives/extend/2013-October/000288.html | 110 + .../archives/extend/2013-October/000289.html | 154 + .../archives/extend/2013-October/000290.html | 141 + .../archives/extend/2013-October/000291.html | 144 + .../archives/extend/2013-October/000292.html | 173 + .../archives/extend/2013-October/000293.html | 175 + .../archives/extend/2013-October/author.html | 242 ++ .../static/archives/extend/2013-October/date.html | 242 ++ .../static/archives/extend/2013-October/index.html | 1 + .../archives/extend/2013-October/subject.html | 242 ++ .../archives/extend/2013-October/thread.html | 309 ++ _build/static/archives/extend/2013-September.txt | 2240 +++++++++++ .../archives/extend/2013-September/000227.html | 104 + .../archives/extend/2013-September/000228.html | 133 + .../archives/extend/2013-September/000229.html | 143 + .../archives/extend/2013-September/000230.html | 76 + .../archives/extend/2013-September/000231.html | 85 + .../archives/extend/2013-September/000232.html | 99 + .../archives/extend/2013-September/000233.html | 116 + .../archives/extend/2013-September/000234.html | 77 + .../archives/extend/2013-September/000235.html | 97 + .../archives/extend/2013-September/000236.html | 109 + .../archives/extend/2013-September/000237.html | 84 + .../archives/extend/2013-September/000238.html | 105 + .../archives/extend/2013-September/000239.html | 124 + .../archives/extend/2013-September/000240.html | 140 + .../archives/extend/2013-September/000241.html | 163 + .../archives/extend/2013-September/000242.html | 191 + .../archives/extend/2013-September/000243.html | 66 + .../archives/extend/2013-September/000244.html | 99 + .../archives/extend/2013-September/000245.html | 117 + .../archives/extend/2013-September/000246.html | 117 + .../archives/extend/2013-September/000247.html | 134 + .../archives/extend/2013-September/000248.html | 141 + .../archives/extend/2013-September/000249.html | 72 + .../archives/extend/2013-September/000250.html | 155 + .../archives/extend/2013-September/000251.html | 212 ++ .../archives/extend/2013-September/000252.html | 188 + .../archives/extend/2013-September/000253.html | 210 ++ .../archives/extend/2013-September/000254.html | 269 ++ .../archives/extend/2013-September/author.html | 187 + .../archives/extend/2013-September/date.html | 187 + .../archives/extend/2013-September/index.html | 1 + .../archives/extend/2013-September/subject.html | 187 + .../archives/extend/2013-September/thread.html | 243 ++ _build/static/archives/extend/2014-April.txt | 943 +++++ .../static/archives/extend/2014-April/000364.html | 79 + .../static/archives/extend/2014-April/000365.html | 70 + .../static/archives/extend/2014-April/000366.html | 91 + .../static/archives/extend/2014-April/000367.html | 104 + .../static/archives/extend/2014-April/000368.html | 114 + .../static/archives/extend/2014-April/000369.html | 173 + .../static/archives/extend/2014-April/000370.html | 177 + .../static/archives/extend/2014-April/000371.html | 185 + .../static/archives/extend/2014-April/000372.html | 93 + .../static/archives/extend/2014-April/000373.html | 112 + .../static/archives/extend/2014-April/000374.html | 83 + .../static/archives/extend/2014-April/000375.html | 88 + .../static/archives/extend/2014-April/000376.html | 84 + .../static/archives/extend/2014-April/000377.html | 89 + .../static/archives/extend/2014-April/000378.html | 82 + .../static/archives/extend/2014-April/000379.html | 71 + .../static/archives/extend/2014-April/000380.html | 71 + .../static/archives/extend/2014-April/000381.html | 76 + .../static/archives/extend/2014-April/000382.html | 66 + .../static/archives/extend/2014-April/author.html | 142 + _build/static/archives/extend/2014-April/date.html | 142 + .../static/archives/extend/2014-April/index.html | 1 + .../static/archives/extend/2014-April/subject.html | 142 + .../static/archives/extend/2014-April/thread.html | 179 + _build/static/archives/extend/2014-August.txt | 2532 +++++++++++++ .../static/archives/extend/2014-August/000417.html | 88 + .../static/archives/extend/2014-August/000418.html | 105 + .../static/archives/extend/2014-August/000419.html | 114 + .../static/archives/extend/2014-August/000420.html | 121 + .../static/archives/extend/2014-August/000421.html | 128 + .../static/archives/extend/2014-August/000422.html | 137 + .../static/archives/extend/2014-August/000423.html | 149 + .../static/archives/extend/2014-August/000424.html | 78 + .../static/archives/extend/2014-August/000425.html | 89 + .../static/archives/extend/2014-August/000426.html | 119 + .../static/archives/extend/2014-August/000427.html | 68 + .../static/archives/extend/2014-August/000428.html | 138 + .../static/archives/extend/2014-August/000429.html | 143 + .../static/archives/extend/2014-August/000430.html | 119 + .../static/archives/extend/2014-August/000431.html | 132 + .../static/archives/extend/2014-August/000432.html | 155 + .../static/archives/extend/2014-August/000433.html | 181 + .../static/archives/extend/2014-August/000434.html | 72 + .../static/archives/extend/2014-August/000435.html | 100 + .../static/archives/extend/2014-August/000436.html | 73 + .../static/archives/extend/2014-August/000437.html | 86 + .../static/archives/extend/2014-August/000438.html | 84 + .../static/archives/extend/2014-August/000439.html | 103 + .../static/archives/extend/2014-August/000440.html | 120 + .../static/archives/extend/2014-August/000441.html | 139 + .../static/archives/extend/2014-August/000442.html | 135 + .../static/archives/extend/2014-August/000443.html | 85 + .../static/archives/extend/2014-August/000444.html | 126 + .../static/archives/extend/2014-August/000445.html | 88 + .../static/archives/extend/2014-August/000446.html | 99 + .../static/archives/extend/2014-August/000447.html | 130 + .../static/archives/extend/2014-August/000448.html | 142 + .../static/archives/extend/2014-August/000449.html | 167 + .../static/archives/extend/2014-August/000450.html | 168 + .../static/archives/extend/2014-August/000451.html | 86 + .../static/archives/extend/2014-August/000452.html | 96 + .../static/archives/extend/2014-August/000453.html | 90 + .../static/archives/extend/2014-August/000454.html | 114 + .../static/archives/extend/2014-August/000455.html | 78 + .../static/archives/extend/2014-August/000456.html | 94 + .../static/archives/extend/2014-August/000457.html | 111 + .../static/archives/extend/2014-August/author.html | 252 ++ .../static/archives/extend/2014-August/date.html | 252 ++ .../static/archives/extend/2014-August/index.html | 1 + .../archives/extend/2014-August/subject.html | 252 ++ .../static/archives/extend/2014-August/thread.html | 331 ++ _build/static/archives/extend/2014-December.txt | 28 + .../archives/extend/2014-December/000483.html | 77 + .../archives/extend/2014-December/author.html | 52 + .../static/archives/extend/2014-December/date.html | 52 + .../archives/extend/2014-December/index.html | 1 + .../archives/extend/2014-December/subject.html | 52 + .../archives/extend/2014-December/thread.html | 53 + _build/static/archives/extend/2014-February.txt | 1332 +++++++ .../archives/extend/2014-February/000324.html | 106 + .../archives/extend/2014-February/000325.html | 134 + .../archives/extend/2014-February/000326.html | 151 + .../archives/extend/2014-February/000327.html | 167 + .../archives/extend/2014-February/000328.html | 195 + .../archives/extend/2014-February/000329.html | 223 ++ .../archives/extend/2014-February/000330.html | 244 ++ .../archives/extend/2014-February/000331.html | 79 + .../archives/extend/2014-February/000332.html | 94 + .../archives/extend/2014-February/000333.html | 108 + .../archives/extend/2014-February/000334.html | 127 + .../archives/extend/2014-February/000335.html | 74 + .../archives/extend/2014-February/000336.html | 87 + .../archives/extend/2014-February/000337.html | 103 + .../archives/extend/2014-February/000338.html | 109 + .../archives/extend/2014-February/000339.html | 125 + .../archives/extend/2014-February/author.html | 127 + .../static/archives/extend/2014-February/date.html | 127 + .../archives/extend/2014-February/index.html | 1 + .../archives/extend/2014-February/subject.html | 127 + .../archives/extend/2014-February/thread.html | 161 + _build/static/archives/extend/2014-January.txt | 99 + .../archives/extend/2014-January/000321.html | 84 + .../archives/extend/2014-January/000322.html | 92 + .../archives/extend/2014-January/000323.html | 76 + .../archives/extend/2014-January/author.html | 62 + .../static/archives/extend/2014-January/date.html | 62 + .../static/archives/extend/2014-January/index.html | 1 + .../archives/extend/2014-January/subject.html | 62 + .../archives/extend/2014-January/thread.html | 67 + _build/static/archives/extend/2014-July.txt | 545 +++ .../static/archives/extend/2014-July/000405.html | 67 + .../static/archives/extend/2014-July/000406.html | 81 + .../static/archives/extend/2014-July/000407.html | 93 + .../static/archives/extend/2014-July/000408.html | 104 + .../static/archives/extend/2014-July/000409.html | 126 + .../static/archives/extend/2014-July/000410.html | 145 + .../static/archives/extend/2014-July/000411.html | 74 + .../static/archives/extend/2014-July/000412.html | 80 + .../static/archives/extend/2014-July/000413.html | 97 + .../static/archives/extend/2014-July/000414.html | 119 + .../static/archives/extend/2014-July/000415.html | 85 + .../static/archives/extend/2014-July/000416.html | 94 + .../static/archives/extend/2014-July/author.html | 107 + _build/static/archives/extend/2014-July/date.html | 107 + _build/static/archives/extend/2014-July/index.html | 1 + .../static/archives/extend/2014-July/subject.html | 107 + .../static/archives/extend/2014-July/thread.html | 133 + _build/static/archives/extend/2014-June.txt | 870 +++++ .../static/archives/extend/2014-June/000390.html | 76 + .../static/archives/extend/2014-June/000391.html | 96 + .../static/archives/extend/2014-June/000392.html | 107 + .../static/archives/extend/2014-June/000393.html | 82 + .../static/archives/extend/2014-June/000394.html | 94 + .../static/archives/extend/2014-June/000395.html | 125 + .../static/archives/extend/2014-June/000396.html | 94 + .../static/archives/extend/2014-June/000397.html | 124 + .../static/archives/extend/2014-June/000398.html | 143 + .../static/archives/extend/2014-June/000399.html | 168 + .../static/archives/extend/2014-June/000400.html | 189 + .../static/archives/extend/2014-June/000401.html | 101 + .../static/archives/extend/2014-June/000402.html | 77 + .../static/archives/extend/2014-June/000403.html | 89 + .../static/archives/extend/2014-June/000404.html | 91 + .../static/archives/extend/2014-June/author.html | 122 + _build/static/archives/extend/2014-June/date.html | 122 + _build/static/archives/extend/2014-June/index.html | 1 + .../static/archives/extend/2014-June/subject.html | 122 + .../static/archives/extend/2014-June/thread.html | 151 + _build/static/archives/extend/2014-March.txt | 1740 +++++++++ .../static/archives/extend/2014-March/000340.html | 105 + .../static/archives/extend/2014-March/000341.html | 81 + .../static/archives/extend/2014-March/000342.html | 129 + .../static/archives/extend/2014-March/000343.html | 121 + .../static/archives/extend/2014-March/000344.html | 134 + .../static/archives/extend/2014-March/000345.html | 148 + .../static/archives/extend/2014-March/000346.html | 149 + .../static/archives/extend/2014-March/000347.html | 221 ++ .../static/archives/extend/2014-March/000348.html | 70 + .../static/archives/extend/2014-March/000349.html | 87 + .../static/archives/extend/2014-March/000350.html | 115 + .../static/archives/extend/2014-March/000351.html | 131 + .../static/archives/extend/2014-March/000352.html | 157 + .../static/archives/extend/2014-March/000353.html | 159 + .../static/archives/extend/2014-March/000354.html | 180 + .../static/archives/extend/2014-March/000355.html | 186 + .../static/archives/extend/2014-March/000356.html | 96 + .../static/archives/extend/2014-March/000357.html | 125 + .../static/archives/extend/2014-March/000358.html | 78 + .../static/archives/extend/2014-March/000359.html | 76 + .../static/archives/extend/2014-March/000360.html | 80 + .../static/archives/extend/2014-March/000361.html | 95 + .../static/archives/extend/2014-March/000362.html | 106 + .../static/archives/extend/2014-March/000363.html | 116 + .../static/archives/extend/2014-March/author.html | 167 + _build/static/archives/extend/2014-March/date.html | 167 + .../static/archives/extend/2014-March/index.html | 1 + .../static/archives/extend/2014-March/subject.html | 167 + .../static/archives/extend/2014-March/thread.html | 219 ++ _build/static/archives/extend/2014-May.txt | 363 ++ _build/static/archives/extend/2014-May/000383.html | 71 + _build/static/archives/extend/2014-May/000384.html | 105 + _build/static/archives/extend/2014-May/000385.html | 71 + _build/static/archives/extend/2014-May/000386.html | 134 + _build/static/archives/extend/2014-May/000387.html | 83 + _build/static/archives/extend/2014-May/000388.html | 180 + _build/static/archives/extend/2014-May/000389.html | 80 + _build/static/archives/extend/2014-May/author.html | 82 + _build/static/archives/extend/2014-May/date.html | 82 + _build/static/archives/extend/2014-May/index.html | 1 + .../static/archives/extend/2014-May/subject.html | 82 + _build/static/archives/extend/2014-May/thread.html | 95 + _build/static/archives/extend/2014-November.txt | 210 ++ .../archives/extend/2014-November/000474.html | 73 + .../archives/extend/2014-November/000475.html | 66 + .../archives/extend/2014-November/000476.html | 72 + .../archives/extend/2014-November/000477.html | 70 + .../archives/extend/2014-November/000478.html | 82 + .../archives/extend/2014-November/000479.html | 80 + .../archives/extend/2014-November/000480.html | 68 + .../archives/extend/2014-November/000481.html | 86 + .../archives/extend/2014-November/000482.html | 83 + .../archives/extend/2014-November/author.html | 92 + .../static/archives/extend/2014-November/date.html | 92 + .../archives/extend/2014-November/index.html | 1 + .../archives/extend/2014-November/subject.html | 92 + .../archives/extend/2014-November/thread.html | 109 + _build/static/archives/extend/2014-October.txt | 223 ++ .../archives/extend/2014-October/000468.html | 72 + .../archives/extend/2014-October/000469.html | 89 + .../archives/extend/2014-October/000470.html | 95 + .../archives/extend/2014-October/000471.html | 105 + .../archives/extend/2014-October/000472.html | 97 + .../archives/extend/2014-October/000473.html | 78 + .../archives/extend/2014-October/author.html | 77 + .../static/archives/extend/2014-October/date.html | 77 + .../static/archives/extend/2014-October/index.html | 1 + .../archives/extend/2014-October/subject.html | 77 + .../archives/extend/2014-October/thread.html | 87 + _build/static/archives/extend/2014-September.txt | 526 +++ .../archives/extend/2014-September/000458.html | 85 + .../archives/extend/2014-September/000459.html | 81 + .../archives/extend/2014-September/000460.html | 75 + .../archives/extend/2014-September/000461.html | 74 + .../archives/extend/2014-September/000462.html | 101 + .../archives/extend/2014-September/000463.html | 82 + .../archives/extend/2014-September/000464.html | 89 + .../archives/extend/2014-September/000465.html | 137 + .../archives/extend/2014-September/000466.html | 161 + .../archives/extend/2014-September/000467.html | 170 + .../archives/extend/2014-September/author.html | 97 + .../archives/extend/2014-September/date.html | 97 + .../archives/extend/2014-September/index.html | 1 + .../archives/extend/2014-September/subject.html | 97 + .../archives/extend/2014-September/thread.html | 119 + _build/static/archives/extend/2015-April.txt | 134 + .../static/archives/extend/2015-April/000527.html | 80 + .../static/archives/extend/2015-April/000528.html | 78 + .../static/archives/extend/2015-April/000529.html | 85 + .../static/archives/extend/2015-April/000530.html | 93 + .../static/archives/extend/2015-April/author.html | 67 + _build/static/archives/extend/2015-April/date.html | 67 + .../static/archives/extend/2015-April/index.html | 1 + .../static/archives/extend/2015-April/subject.html | 67 + .../static/archives/extend/2015-April/thread.html | 77 + _build/static/archives/extend/2015-August.txt | 124 + .../static/archives/extend/2015-August/000547.html | 100 + .../static/archives/extend/2015-August/000548.html | 86 + .../static/archives/extend/2015-August/000549.html | 91 + .../static/archives/extend/2015-August/author.html | 62 + .../static/archives/extend/2015-August/date.html | 62 + .../static/archives/extend/2015-August/index.html | 1 + .../archives/extend/2015-August/subject.html | 62 + .../static/archives/extend/2015-August/thread.html | 67 + _build/static/archives/extend/2015-February.txt | 233 ++ .../archives/extend/2015-February/000510.html | 83 + .../archives/extend/2015-February/000511.html | 103 + .../archives/extend/2015-February/000512.html | 123 + .../archives/extend/2015-February/000513.html | 130 + .../archives/extend/2015-February/author.html | 67 + .../static/archives/extend/2015-February/date.html | 67 + .../archives/extend/2015-February/index.html | 1 + .../archives/extend/2015-February/subject.html | 67 + .../archives/extend/2015-February/thread.html | 75 + _build/static/archives/extend/2015-January.txt | 1189 ++++++ .../archives/extend/2015-January/000484.html | 110 + .../archives/extend/2015-January/000485.html | 136 + .../archives/extend/2015-January/000486.html | 81 + .../archives/extend/2015-January/000487.html | 90 + .../archives/extend/2015-January/000488.html | 112 + .../archives/extend/2015-January/000489.html | 73 + .../archives/extend/2015-January/000490.html | 90 + .../archives/extend/2015-January/000491.html | 80 + .../archives/extend/2015-January/000492.html | 91 + .../archives/extend/2015-January/000493.html | 98 + .../archives/extend/2015-January/000494.html | 105 + .../archives/extend/2015-January/000495.html | 138 + .../archives/extend/2015-January/000496.html | 86 + .../archives/extend/2015-January/000497.html | 76 + .../archives/extend/2015-January/000498.html | 88 + .../archives/extend/2015-January/000499.html | 153 + .../archives/extend/2015-January/000500.html | 145 + .../archives/extend/2015-January/000501.html | 103 + .../archives/extend/2015-January/000502.html | 79 + .../archives/extend/2015-January/000503.html | 97 + .../archives/extend/2015-January/000504.html | 70 + .../archives/extend/2015-January/000505.html | 82 + .../archives/extend/2015-January/000506.html | 87 + .../archives/extend/2015-January/000507.html | 100 + .../archives/extend/2015-January/000508.html | 69 + .../archives/extend/2015-January/000509.html | 74 + .../archives/extend/2015-January/author.html | 177 + .../static/archives/extend/2015-January/date.html | 177 + .../static/archives/extend/2015-January/index.html | 1 + .../archives/extend/2015-January/subject.html | 177 + .../archives/extend/2015-January/thread.html | 227 ++ _build/static/archives/extend/2015-July.txt | 85 + .../static/archives/extend/2015-July/000545.html | 87 + .../static/archives/extend/2015-July/000546.html | 99 + .../static/archives/extend/2015-July/author.html | 57 + _build/static/archives/extend/2015-July/date.html | 57 + _build/static/archives/extend/2015-July/index.html | 1 + .../static/archives/extend/2015-July/subject.html | 57 + .../static/archives/extend/2015-July/thread.html | 61 + _build/static/archives/extend/2015-June.txt | 2012 ++++++++++ .../static/archives/extend/2015-June/000531.html | 92 + .../static/archives/extend/2015-June/000532.html | 193 + .../static/archives/extend/2015-June/000533.html | 213 ++ .../static/archives/extend/2015-June/000534.html | 234 ++ .../static/archives/extend/2015-June/000535.html | 259 ++ .../static/archives/extend/2015-June/000536.html | 287 ++ .../static/archives/extend/2015-June/000537.html | 276 ++ .../static/archives/extend/2015-June/000538.html | 312 ++ .../static/archives/extend/2015-June/000539.html | 337 ++ .../static/archives/extend/2015-June/000540.html | 90 + .../static/archives/extend/2015-June/000541.html | 118 + .../static/archives/extend/2015-June/000542.html | 93 + .../static/archives/extend/2015-June/000543.html | 105 + .../static/archives/extend/2015-June/000544.html | 119 + .../static/archives/extend/2015-June/author.html | 117 + _build/static/archives/extend/2015-June/date.html | 117 + _build/static/archives/extend/2015-June/index.html | 1 + .../static/archives/extend/2015-June/subject.html | 117 + .../static/archives/extend/2015-June/thread.html | 141 + _build/static/archives/extend/2015-March.txt | 774 ++++ .../static/archives/extend/2015-March/000514.html | 76 + .../static/archives/extend/2015-March/000515.html | 91 + .../static/archives/extend/2015-March/000516.html | 101 + .../static/archives/extend/2015-March/000517.html | 102 + .../static/archives/extend/2015-March/000518.html | 113 + .../static/archives/extend/2015-March/000519.html | 117 + .../static/archives/extend/2015-March/000520.html | 125 + .../static/archives/extend/2015-March/000521.html | 131 + .../static/archives/extend/2015-March/000522.html | 141 + .../static/archives/extend/2015-March/000523.html | 149 + .../static/archives/extend/2015-March/000524.html | 84 + .../static/archives/extend/2015-March/000525.html | 97 + .../static/archives/extend/2015-March/000526.html | 100 + .../static/archives/extend/2015-March/author.html | 112 + _build/static/archives/extend/2015-March/date.html | 112 + .../static/archives/extend/2015-March/index.html | 1 + .../static/archives/extend/2015-March/subject.html | 112 + .../static/archives/extend/2015-March/thread.html | 135 + _build/static/archives/extend/2015-October.txt | 80 + .../archives/extend/2015-October/000557.html | 93 + .../archives/extend/2015-October/000558.html | 87 + .../archives/extend/2015-October/author.html | 57 + .../static/archives/extend/2015-October/date.html | 57 + .../static/archives/extend/2015-October/index.html | 1 + .../archives/extend/2015-October/subject.html | 57 + .../archives/extend/2015-October/thread.html | 61 + _build/static/archives/extend/2015-September.txt | 552 +++ .../archives/extend/2015-September/000550.html | 90 + .../archives/extend/2015-September/000551.html | 108 + .../archives/extend/2015-September/000552.html | 115 + .../archives/extend/2015-September/000553.html | 129 + .../archives/extend/2015-September/000554.html | 137 + .../archives/extend/2015-September/000555.html | 157 + .../archives/extend/2015-September/000556.html | 166 + .../archives/extend/2015-September/author.html | 82 + .../archives/extend/2015-September/date.html | 82 + .../archives/extend/2015-September/index.html | 1 + .../archives/extend/2015-September/subject.html | 82 + .../archives/extend/2015-September/thread.html | 95 + .../attachments/20121030/3de26c28/attachment.html | 9 + .../attachments/20121216/2d0b0da5/attachment.html | 25 + .../attachments/20121220/631f7f13/attachment.html | 6 + .../attachments/20121221/8bfb2f11/attachment.html | 44 + .../attachments/20121221/945f636e/attachment.html | 108 + .../attachments/20130103/bae06e70/attachment.html | 54 + .../attachments/20130103/d9dbc1a5/attachment.html | 157 + .../attachments/20130103/f6c7fd25/attachment.html | 97 + .../attachments/20130117/19bfde40/attachment.html | 20 + .../attachments/20130125/7d0820aa/attachment.html | 35 + .../attachments/20130204/3c258140/attachment.html | 20 + .../attachments/20130204/c34e6aa6/attachment.html | 79 + .../attachments/20130210/1b9560c2/attachment.html | 6 + .../attachments/20130212/09008370/attachment.html | 48 + .../attachments/20130212/dc0291b4/attachment.html | 4 + .../attachments/20130213/41b12a6d/attachment.html | 50 + .../attachments/20130213/a992c0b6/attachment.html | 25 + .../attachments/20130221/fc119c69/attachment.html | 14 + .../attachments/20130317/2ee0bc92/attachment.html | 54 + .../attachments/20130317/2f20f449/attachment.html | 5 + .../attachments/20130413/f1b70800/attachment.html | 13 + .../attachments/20130415/03f35a62/attachment.html | 8 + .../attachments/20130415/59aaeef2/attachment.html | 56 + .../attachments/20130419/383515dd/attachment.html | 213 ++ .../attachments/20130419/bf0e8ef9/attachment.html | 8 + .../attachments/20130425/35ee7614/attachment.html | 4 + .../attachments/20130426/09f3ed34/attachment.html | 20 + .../attachments/20130426/9d234e27/attachment.html | 12 + .../attachments/20130426/b1e8ae7a/attachment.html | 27 + .../attachments/20130430/c86f8fdb/attachment.html | 8 + .../attachments/20130512/65929751/attachment.html | 44 + .../attachments/20130512/dd43116e/attachment.html | 9 + .../attachments/20130517/629071b8/attachment.html | 19 + .../attachments/20130519/db7f08ab/attachment.html | 6 + .../attachments/20130520/3cc045e8/attachment.html | 9 + .../attachments/20130520/5134ba32/attachment.html | 29 + .../attachments/20130605/568478c8/attachment.html | 9 + .../attachments/20130718/79e075b8/attachment.html | 21 + .../attachments/20130718/a3961a6f/attachment.html | 21 + .../attachments/20130718/c50bef17/attachment.html | 21 + .../attachments/20130718/d65f1aaf/attachment.html | 8 + .../attachments/20130723/3e51c337/attachment.html | 6 + .../attachments/20130802/4f7baee0/attachment.html | 12 + .../attachments/20130805/9fd5783b/attachment.html | 6 + .../attachments/20130816/1c70f542/attachment.html | 22 + .../attachments/20130816/1cd82d09/attachment.html | 21 + .../attachments/20130816/4e596577/attachment.html | 218 ++ .../attachments/20130816/8f4a69b4/attachment.html | 77 + .../attachments/20130816/a886396a/attachment.html | 21 + .../attachments/20130816/ff4591a1/attachment.html | 52 + .../attachments/20130820/b203ebe2/attachment.html | 32 + .../attachments/20130915/c9a5340e/attachment.html | 10 + .../attachments/20130916/dedbf486/attachment.html | 6 + .../attachments/20130916/f55d10f5/attachment.html | 29 + .../attachments/20130919/0a4bcb6c/attachment.html | 42 + .../attachments/20130919/9614ef5e/attachment.html | 6 + .../attachments/20130920/32352505/attachment.html | 49 + .../attachments/20130920/4c005881/attachment.html | 85 + .../attachments/20130920/6e3fa036/attachment.html | 7 + .../attachments/20130922/6e925e9d/attachment.html | 12 + .../attachments/20130922/77e355ff/attachment.html | 4 + .../attachments/20130926/28d38e59/attachment.html | 186 + .../attachments/20130926/3a77fe04/attachment.html | 189 + .../attachments/20130926/d34b33e3/attachment.html | 85 + .../attachments/20130928/41b322fd/attachment.html | 253 ++ .../attachments/20130928/b1333ac2/attachment.html | 195 + .../attachments/20131002/4463e3fa/attachment.html | 5 + .../attachments/20131007/863e7358/attachment.html | 75 + .../attachments/20131007/fdef2170/attachment.html | 15 + .../attachments/20131008/8752fdd7/attachment.html | 82 + .../attachments/20131009/7c03cefc/attachment.html | 67 + .../attachments/20131009/cc05d6f5/attachment.html | 67 + .../attachments/20131015/203060cc/attachment.html | 78 + .../attachments/20131015/591e8649/attachment.html | 46 + .../attachments/20131015/94506752/attachment.html | 8 + .../attachments/20131015/bac10460/attachment.html | 9 + .../attachments/20131016/abe38a1a/attachment.html | 9 + .../attachments/20131016/edbc349c/attachment.html | 46 + .../attachments/20131018/00d4df12/attachment.html | 6 + .../attachments/20131029/3df30c1d/attachment.html | 10 + .../attachments/20131029/5fc5da75/attachment.html | 26 + .../attachments/20131029/a9204600/attachment.html | 10 + .../attachments/20131030/0ab7c8ee/attachment.html | 38 + .../attachments/20131030/3ea4ac64/attachment.html | 88 + .../attachments/20131030/460453c8/attachment.html | 23 + .../attachments/20131030/6e8ec2f0/attachment.html | 23 + .../attachments/20131115/79d7b0ce/attachment.html | 45 + .../attachments/20131117/41119d53/attachment.html | 5 + .../attachments/20131120/6c3ab980/attachment.html | 34 + .../attachments/20131120/7808a87a/attachment.html | 8 + .../attachments/20131120/792230f4/attachment.html | 41 + .../attachments/20131120/82981048/attachment.html | 25 + .../attachments/20131121/7d69dbf7/attachment.html | 3 + .../attachments/20131122/11ccc1ef/attachment.html | 13 + .../attachments/20131127/11da2202/attachment.html | 8 + .../attachments/20131127/20905d98/attachment.html | 5 + .../attachments/20131212/2697fbaa/attachment.html | 13 + .../attachments/20131215/7c20ac97/attachment.html | 6 + .../attachments/20131227/35c9f6e5/attachment.html | 3 + .../attachments/20140203/088e7e6a/attachment.html | 120 + .../attachments/20140203/104f8577/attachment.html | 28 + .../attachments/20140203/2982cff3/attachment.html | 82 + .../attachments/20140203/e84f6223/attachment.html | 171 + .../attachments/20140207/904cc7bf/attachment.html | 8 + .../attachments/20140210/1781c9d2/attachment.html | 33 + .../attachments/20140210/2ae635a6/attachment.html | 33 + .../attachments/20140210/a2b35e2f/attachment.html | 6 + .../attachments/20140210/b46e2bab/attachment.html | 15 + .../attachments/20140210/bf26d573/attachment.html | 60 + .../attachments/20140210/fa72e2ba/attachment.html | 41 + .../attachments/20140303/52007acc/attachment.html | 11 + .../attachments/20140306/24422ef2/attachment.html | 19 + .../attachments/20140306/6fa8fe3b/attachment.html | 67 + .../attachments/20140306/a517215b/attachment.html | 7 + .../attachments/20140314/b2f802d3/attachment.html | 31 + .../attachments/20140411/9e3c6c32/attachment.html | 3 + .../20140420/bf45e4d0/attachment-0001.bin | 59 + .../attachments/20140420/bf45e4d0/attachment.bin | 113 + .../attachments/20140520/32454f85/attachment.html | 28 + .../attachments/20140520/699b72b3/attachment.html | 5 + .../attachments/20140520/cf7632e9/attachment.html | 10 + .../20140604/269377d0/attachment-0001.html | 5 + .../attachments/20140604/269377d0/attachment.html | 5 + .../20140604/2bce99e1/attachment-0001.html | 18 + .../attachments/20140604/2bce99e1/attachment.html | 18 + .../20140604/407d3443/attachment-0001.html | 16 + .../attachments/20140604/407d3443/attachment.html | 16 + .../20140605/3ba15fb3/attachment-0001.html | 42 + .../attachments/20140605/3ba15fb3/attachment.html | 42 + .../20140605/46eee3c0/attachment-0001.html | 47 + .../attachments/20140605/46eee3c0/attachment.html | 47 + .../20140606/b992565e/attachment-0001.html | 89 + .../attachments/20140606/b992565e/attachment.html | 89 + .../20140708/35d8806d/attachment-0001.html | 6 + .../attachments/20140708/35d8806d/attachment.html | 6 + .../20140708/497ef9a1/attachment-0001.html | 41 + .../attachments/20140708/497ef9a1/attachment.html | 41 + .../20140805/2c08b12c/attachment-0001.html | 7 + .../attachments/20140805/2c08b12c/attachment.html | 7 + .../20140805/34528764/attachment-0001.html | 80 + .../attachments/20140805/34528764/attachment.html | 80 + .../20140805/a3d520b7/attachment-0001.html | 4 + .../attachments/20140805/a3d520b7/attachment.html | 4 + .../20140805/f3705f7b/attachment-0001.html | 30 + .../attachments/20140805/f3705f7b/attachment.html | 30 + .../20140805/fb1bc75c/attachment-0001.html | 58 + .../attachments/20140805/fb1bc75c/attachment.html | 58 + .../20140813/7903a29a/attachment-0001.html | 6 + .../attachments/20140813/7903a29a/attachment.html | 6 + .../20140814/64f862ef/attachment-0001.html | 3 + .../attachments/20140814/64f862ef/attachment.html | 3 + .../20140823/51e1d345/attachment-0001.html | 30 + .../attachments/20140823/51e1d345/attachment.html | 30 + .../20140824/89d3a7f6/attachment-0001.html | 65 + .../attachments/20140824/89d3a7f6/attachment.html | 65 + .../20140824/f35e1e51/attachment-0001.html | 65 + .../attachments/20140824/f35e1e51/attachment.html | 65 + .../20140827/91c1e017/attachment-0001.html | 54 + .../attachments/20140827/91c1e017/attachment.html | 54 + .../20140915/26d4e023/attachment-0001.html | 12 + .../attachments/20140915/26d4e023/attachment.html | 12 + .../20140915/5f3302e4/attachment-0001.html | 4 + .../attachments/20140915/5f3302e4/attachment.html | 4 + .../20140915/d97a6072/attachment-0001.html | 4 + .../attachments/20140915/d97a6072/attachment.html | 4 + .../20140929/84fe21a4/attachment-0001.html | 5 + .../attachments/20140929/84fe21a4/attachment.html | 5 + .../20140930/6d952ce6/attachment-0001.html | 11 + .../attachments/20140930/6d952ce6/attachment.html | 11 + .../20140930/ef46837f/attachment-0001.html | 13 + .../attachments/20140930/ef46837f/attachment.html | 13 + .../20141014/77f74bf0/attachment-0001.html | 5 + .../attachments/20141014/77f74bf0/attachment.html | 5 + .../20141014/d89bced6/attachment-0001.html | 6 + .../attachments/20141014/d89bced6/attachment.html | 6 + .../20141031/fc6724a7/attachment-0001.html | 67 + .../attachments/20141031/fc6724a7/attachment.html | 67 + .../20141106/85a93e04/attachment-0001.html | 6 + .../attachments/20141106/85a93e04/attachment.html | 6 + .../20141110/a4b469a5/attachment-0001.html | 13 + .../attachments/20141110/a4b469a5/attachment.html | 13 + .../20141122/bcb1d17c/attachment-0001.html | 4 + .../attachments/20141122/bcb1d17c/attachment.html | 4 + .../20141124/9ceef28a/attachment-0001.html | 4 + .../attachments/20141124/9ceef28a/attachment.html | 4 + .../20141225/ff94953b/attachment-0001.html | 4 + .../attachments/20141225/ff94953b/attachment.html | 4 + .../20150114/3267f73e/attachment-0001.html | 4 + .../attachments/20150114/3267f73e/attachment.html | 4 + .../20150125/370811e4/attachment-0001.html | 25 + .../attachments/20150125/370811e4/attachment.html | 25 + .../20150127/1916d612/attachment-0001.html | 29 + .../attachments/20150127/1916d612/attachment.html | 29 + .../20150215/9d2f5de1/attachment-0001.html | 25 + .../attachments/20150215/9d2f5de1/attachment.html | 25 + .../20150623/3556788c/attachment-0001.html | 203 + .../attachments/20150623/3556788c/attachment.html | 203 + .../20150623/69dfc8e4/attachment-0001.html | 4 + .../attachments/20150623/69dfc8e4/attachment.html | 4 + .../20150623/dd7366a3/attachment-0001.html | 160 + .../attachments/20150623/dd7366a3/attachment.html | 160 + .../20150623/f7c19f68/attachment-0001.html | 256 ++ .../attachments/20150623/f7c19f68/attachment.html | 256 ++ .../20150623/fcdb2d7b/attachment-0001.html | 203 + .../attachments/20150623/fcdb2d7b/attachment.html | 203 + .../20150624/204c1308/attachment-0001.html | 4 + .../attachments/20150624/204c1308/attachment.html | 4 + .../20150624/6d15706e/attachment-0001.html | 9 + .../attachments/20150624/6d15706e/attachment.html | 9 + .../20150624/72689ab9/attachment-0001.html | 72 + .../attachments/20150624/72689ab9/attachment.html | 72 + .../20150624/b67122b6/attachment-0001.html | 77 + .../attachments/20150624/b67122b6/attachment.html | 77 + .../20150713/eb33ab46/attachment-0001.html | 4 + .../attachments/20150713/eb33ab46/attachment.html | 4 + .../20150824/7576a7ab/attachment-0001.html | 4 + .../attachments/20150824/7576a7ab/attachment.html | 4 + .../20150923/fc8e4ef7/attachment-0001.html | 4 + .../attachments/20150923/fc8e4ef7/attachment.html | 4 + .../20150924/6a9add86/attachment-0001.html | 61 + .../attachments/20150924/6a9add86/attachment.html | 61 + .../20150930/7f5e7422/attachment-0001.html | 101 + .../attachments/20150930/7f5e7422/attachment.html | 101 + .../20150930/ee98f926/attachment-0001.html | 62 + .../attachments/20150930/ee98f926/attachment.html | 62 + _build/static/archives/extend/index.html | 455 +++ 1001 files changed, 123933 insertions(+) create mode 100644 _build/static/archives/extend/2012-December.txt create mode 100644 _build/static/archives/extend/2012-December/000018.html create mode 100644 _build/static/archives/extend/2012-December/000019.html create mode 100644 _build/static/archives/extend/2012-December/000020.html create mode 100644 _build/static/archives/extend/2012-December/000021.html create mode 100644 _build/static/archives/extend/2012-December/000022.html create mode 100644 _build/static/archives/extend/2012-December/000023.html create mode 100644 _build/static/archives/extend/2012-December/000024.html create mode 100644 _build/static/archives/extend/2012-December/000025.html create mode 100644 _build/static/archives/extend/2012-December/000026.html create mode 100644 _build/static/archives/extend/2012-December/000027.html create mode 100644 _build/static/archives/extend/2012-December/author.html create mode 100644 _build/static/archives/extend/2012-December/date.html create mode 120000 _build/static/archives/extend/2012-December/index.html create mode 100644 _build/static/archives/extend/2012-December/subject.html create mode 100644 _build/static/archives/extend/2012-December/thread.html create mode 100644 _build/static/archives/extend/2012-November.txt create mode 100644 _build/static/archives/extend/2012-November/000007.html create mode 100644 _build/static/archives/extend/2012-November/000008.html create mode 100644 _build/static/archives/extend/2012-November/000009.html create mode 100644 _build/static/archives/extend/2012-November/000010.html create mode 100644 _build/static/archives/extend/2012-November/000011.html create mode 100644 _build/static/archives/extend/2012-November/000012.html create mode 100644 _build/static/archives/extend/2012-November/000013.html create mode 100644 _build/static/archives/extend/2012-November/000014.html create mode 100644 _build/static/archives/extend/2012-November/000015.html create mode 100644 _build/static/archives/extend/2012-November/000016.html create mode 100644 _build/static/archives/extend/2012-November/000017.html create mode 100644 _build/static/archives/extend/2012-November/author.html create mode 100644 _build/static/archives/extend/2012-November/date.html create mode 120000 _build/static/archives/extend/2012-November/index.html create mode 100644 _build/static/archives/extend/2012-November/subject.html create mode 100644 _build/static/archives/extend/2012-November/thread.html create mode 100644 _build/static/archives/extend/2012-October.txt create mode 100644 _build/static/archives/extend/2012-October/000000.html create mode 100644 _build/static/archives/extend/2012-October/000001.html create mode 100644 _build/static/archives/extend/2012-October/000002.html create mode 100644 _build/static/archives/extend/2012-October/000003.html create mode 100644 _build/static/archives/extend/2012-October/000004.html create mode 100644 _build/static/archives/extend/2012-October/000005.html create mode 100644 _build/static/archives/extend/2012-October/000006.html create mode 100644 _build/static/archives/extend/2012-October/author.html create mode 100644 _build/static/archives/extend/2012-October/date.html create mode 120000 _build/static/archives/extend/2012-October/index.html create mode 100644 _build/static/archives/extend/2012-October/subject.html create mode 100644 _build/static/archives/extend/2012-October/thread.html create mode 100644 _build/static/archives/extend/2013-April.txt create mode 100644 _build/static/archives/extend/2013-April/000073.html create mode 100644 _build/static/archives/extend/2013-April/000074.html create mode 100644 _build/static/archives/extend/2013-April/000075.html create mode 100644 _build/static/archives/extend/2013-April/000076.html create mode 100644 _build/static/archives/extend/2013-April/000077.html create mode 100644 _build/static/archives/extend/2013-April/000078.html create mode 100644 _build/static/archives/extend/2013-April/000079.html create mode 100644 _build/static/archives/extend/2013-April/000080.html create mode 100644 _build/static/archives/extend/2013-April/000081.html create mode 100644 _build/static/archives/extend/2013-April/000082.html create mode 100644 _build/static/archives/extend/2013-April/000083.html create mode 100644 _build/static/archives/extend/2013-April/000084.html create mode 100644 _build/static/archives/extend/2013-April/000085.html create mode 100644 _build/static/archives/extend/2013-April/000086.html create mode 100644 _build/static/archives/extend/2013-April/000087.html create mode 100644 _build/static/archives/extend/2013-April/000088.html create mode 100644 _build/static/archives/extend/2013-April/000089.html create mode 100644 _build/static/archives/extend/2013-April/000090.html create mode 100644 _build/static/archives/extend/2013-April/000091.html create mode 100644 _build/static/archives/extend/2013-April/000092.html create mode 100644 _build/static/archives/extend/2013-April/000093.html create mode 100644 _build/static/archives/extend/2013-April/000094.html create mode 100644 _build/static/archives/extend/2013-April/000095.html create mode 100644 _build/static/archives/extend/2013-April/000096.html create mode 100644 _build/static/archives/extend/2013-April/000097.html create mode 100644 _build/static/archives/extend/2013-April/000098.html create mode 100644 _build/static/archives/extend/2013-April/000099.html create mode 100644 _build/static/archives/extend/2013-April/000100.html create mode 100644 _build/static/archives/extend/2013-April/000101.html create mode 100644 _build/static/archives/extend/2013-April/000102.html create mode 100644 _build/static/archives/extend/2013-April/000103.html create mode 100644 _build/static/archives/extend/2013-April/000104.html create mode 100644 _build/static/archives/extend/2013-April/000105.html create mode 100644 _build/static/archives/extend/2013-April/000106.html create mode 100644 _build/static/archives/extend/2013-April/000107.html create mode 100644 _build/static/archives/extend/2013-April/000108.html create mode 100644 _build/static/archives/extend/2013-April/000109.html create mode 100644 _build/static/archives/extend/2013-April/000110.html create mode 100644 _build/static/archives/extend/2013-April/000111.html create mode 100644 _build/static/archives/extend/2013-April/000112.html create mode 100644 _build/static/archives/extend/2013-April/000113.html create mode 100644 _build/static/archives/extend/2013-April/000114.html create mode 100644 _build/static/archives/extend/2013-April/000115.html create mode 100644 _build/static/archives/extend/2013-April/000116.html create mode 100644 _build/static/archives/extend/2013-April/000117.html create mode 100644 _build/static/archives/extend/2013-April/000118.html create mode 100644 _build/static/archives/extend/2013-April/000119.html create mode 100644 _build/static/archives/extend/2013-April/000120.html create mode 100644 _build/static/archives/extend/2013-April/000121.html create mode 100644 _build/static/archives/extend/2013-April/000122.html create mode 100644 _build/static/archives/extend/2013-April/000123.html create mode 100644 _build/static/archives/extend/2013-April/000124.html create mode 100644 _build/static/archives/extend/2013-April/000125.html create mode 100644 _build/static/archives/extend/2013-April/000126.html create mode 100644 _build/static/archives/extend/2013-April/000127.html create mode 100644 _build/static/archives/extend/2013-April/author.html create mode 100644 _build/static/archives/extend/2013-April/date.html create mode 120000 _build/static/archives/extend/2013-April/index.html create mode 100644 _build/static/archives/extend/2013-April/subject.html create mode 100644 _build/static/archives/extend/2013-April/thread.html create mode 100644 _build/static/archives/extend/2013-August.txt create mode 100644 _build/static/archives/extend/2013-August/000176.html create mode 100644 _build/static/archives/extend/2013-August/000177.html create mode 100644 _build/static/archives/extend/2013-August/000178.html create mode 100644 _build/static/archives/extend/2013-August/000179.html create mode 100644 _build/static/archives/extend/2013-August/000180.html create mode 100644 _build/static/archives/extend/2013-August/000181.html create mode 100644 _build/static/archives/extend/2013-August/000182.html create mode 100644 _build/static/archives/extend/2013-August/000183.html create mode 100644 _build/static/archives/extend/2013-August/000184.html create mode 100644 _build/static/archives/extend/2013-August/000185.html create mode 100644 _build/static/archives/extend/2013-August/000186.html create mode 100644 _build/static/archives/extend/2013-August/000187.html create mode 100644 _build/static/archives/extend/2013-August/000188.html create mode 100644 _build/static/archives/extend/2013-August/000189.html create mode 100644 _build/static/archives/extend/2013-August/000190.html create mode 100644 _build/static/archives/extend/2013-August/000191.html create mode 100644 _build/static/archives/extend/2013-August/000192.html create mode 100644 _build/static/archives/extend/2013-August/000193.html create mode 100644 _build/static/archives/extend/2013-August/000194.html create mode 100644 _build/static/archives/extend/2013-August/000195.html create mode 100644 _build/static/archives/extend/2013-August/000196.html create mode 100644 _build/static/archives/extend/2013-August/000197.html create mode 100644 _build/static/archives/extend/2013-August/000198.html create mode 100644 _build/static/archives/extend/2013-August/000199.html create mode 100644 _build/static/archives/extend/2013-August/000200.html create mode 100644 _build/static/archives/extend/2013-August/000201.html create mode 100644 _build/static/archives/extend/2013-August/000202.html create mode 100644 _build/static/archives/extend/2013-August/000203.html create mode 100644 _build/static/archives/extend/2013-August/000204.html create mode 100644 _build/static/archives/extend/2013-August/000205.html create mode 100644 _build/static/archives/extend/2013-August/000206.html create mode 100644 _build/static/archives/extend/2013-August/000207.html create mode 100644 _build/static/archives/extend/2013-August/000208.html create mode 100644 _build/static/archives/extend/2013-August/000209.html create mode 100644 _build/static/archives/extend/2013-August/000210.html create mode 100644 _build/static/archives/extend/2013-August/000211.html create mode 100644 _build/static/archives/extend/2013-August/000212.html create mode 100644 _build/static/archives/extend/2013-August/000213.html create mode 100644 _build/static/archives/extend/2013-August/000214.html create mode 100644 _build/static/archives/extend/2013-August/000215.html create mode 100644 _build/static/archives/extend/2013-August/000216.html create mode 100644 _build/static/archives/extend/2013-August/000217.html create mode 100644 _build/static/archives/extend/2013-August/000218.html create mode 100644 _build/static/archives/extend/2013-August/000219.html create mode 100644 _build/static/archives/extend/2013-August/000220.html create mode 100644 _build/static/archives/extend/2013-August/000221.html create mode 100644 _build/static/archives/extend/2013-August/000222.html create mode 100644 _build/static/archives/extend/2013-August/000223.html create mode 100644 _build/static/archives/extend/2013-August/000224.html create mode 100644 _build/static/archives/extend/2013-August/000225.html create mode 100644 _build/static/archives/extend/2013-August/000226.html create mode 100644 _build/static/archives/extend/2013-August/author.html create mode 100644 _build/static/archives/extend/2013-August/date.html create mode 120000 _build/static/archives/extend/2013-August/index.html create mode 100644 _build/static/archives/extend/2013-August/subject.html create mode 100644 _build/static/archives/extend/2013-August/thread.html create mode 100644 _build/static/archives/extend/2013-December.txt create mode 100644 _build/static/archives/extend/2013-December/000314.html create mode 100644 _build/static/archives/extend/2013-December/000315.html create mode 100644 _build/static/archives/extend/2013-December/000316.html create mode 100644 _build/static/archives/extend/2013-December/000317.html create mode 100644 _build/static/archives/extend/2013-December/000318.html create mode 100644 _build/static/archives/extend/2013-December/000319.html create mode 100644 _build/static/archives/extend/2013-December/000320.html create mode 100644 _build/static/archives/extend/2013-December/author.html create mode 100644 _build/static/archives/extend/2013-December/date.html create mode 120000 _build/static/archives/extend/2013-December/index.html create mode 100644 _build/static/archives/extend/2013-December/subject.html create mode 100644 _build/static/archives/extend/2013-December/thread.html create mode 100644 _build/static/archives/extend/2013-February.txt create mode 100644 _build/static/archives/extend/2013-February/000043.html create mode 100644 _build/static/archives/extend/2013-February/000044.html create mode 100644 _build/static/archives/extend/2013-February/000045.html create mode 100644 _build/static/archives/extend/2013-February/000046.html create mode 100644 _build/static/archives/extend/2013-February/000047.html create mode 100644 _build/static/archives/extend/2013-February/000048.html create mode 100644 _build/static/archives/extend/2013-February/000049.html create mode 100644 _build/static/archives/extend/2013-February/000050.html create mode 100644 _build/static/archives/extend/2013-February/000051.html create mode 100644 _build/static/archives/extend/2013-February/000052.html create mode 100644 _build/static/archives/extend/2013-February/000053.html create mode 100644 _build/static/archives/extend/2013-February/000054.html create mode 100644 _build/static/archives/extend/2013-February/000055.html create mode 100644 _build/static/archives/extend/2013-February/000056.html create mode 100644 _build/static/archives/extend/2013-February/000057.html create mode 100644 _build/static/archives/extend/2013-February/000058.html create mode 100644 _build/static/archives/extend/2013-February/000059.html create mode 100644 _build/static/archives/extend/2013-February/000060.html create mode 100644 _build/static/archives/extend/2013-February/000061.html create mode 100644 _build/static/archives/extend/2013-February/000062.html create mode 100644 _build/static/archives/extend/2013-February/000063.html create mode 100644 _build/static/archives/extend/2013-February/000064.html create mode 100644 _build/static/archives/extend/2013-February/000065.html create mode 100644 _build/static/archives/extend/2013-February/author.html create mode 100644 _build/static/archives/extend/2013-February/date.html create mode 120000 _build/static/archives/extend/2013-February/index.html create mode 100644 _build/static/archives/extend/2013-February/subject.html create mode 100644 _build/static/archives/extend/2013-February/thread.html create mode 100644 _build/static/archives/extend/2013-January.txt create mode 100644 _build/static/archives/extend/2013-January/000028.html create mode 100644 _build/static/archives/extend/2013-January/000029.html create mode 100644 _build/static/archives/extend/2013-January/000030.html create mode 100644 _build/static/archives/extend/2013-January/000031.html create mode 100644 _build/static/archives/extend/2013-January/000032.html create mode 100644 _build/static/archives/extend/2013-January/000033.html create mode 100644 _build/static/archives/extend/2013-January/000034.html create mode 100644 _build/static/archives/extend/2013-January/000035.html create mode 100644 _build/static/archives/extend/2013-January/000036.html create mode 100644 _build/static/archives/extend/2013-January/000037.html create mode 100644 _build/static/archives/extend/2013-January/000038.html create mode 100644 _build/static/archives/extend/2013-January/000039.html create mode 100644 _build/static/archives/extend/2013-January/000040.html create mode 100644 _build/static/archives/extend/2013-January/000041.html create mode 100644 _build/static/archives/extend/2013-January/000042.html create mode 100644 _build/static/archives/extend/2013-January/author.html create mode 100644 _build/static/archives/extend/2013-January/date.html create mode 120000 _build/static/archives/extend/2013-January/index.html create mode 100644 _build/static/archives/extend/2013-January/subject.html create mode 100644 _build/static/archives/extend/2013-January/thread.html create mode 100644 _build/static/archives/extend/2013-July.txt create mode 100644 _build/static/archives/extend/2013-July/000152.html create mode 100644 _build/static/archives/extend/2013-July/000153.html create mode 100644 _build/static/archives/extend/2013-July/000154.html create mode 100644 _build/static/archives/extend/2013-July/000155.html create mode 100644 _build/static/archives/extend/2013-July/000156.html create mode 100644 _build/static/archives/extend/2013-July/000157.html create mode 100644 _build/static/archives/extend/2013-July/000158.html create mode 100644 _build/static/archives/extend/2013-July/000159.html create mode 100644 _build/static/archives/extend/2013-July/000160.html create mode 100644 _build/static/archives/extend/2013-July/000161.html create mode 100644 _build/static/archives/extend/2013-July/000162.html create mode 100644 _build/static/archives/extend/2013-July/000163.html create mode 100644 _build/static/archives/extend/2013-July/000164.html create mode 100644 _build/static/archives/extend/2013-July/000165.html create mode 100644 _build/static/archives/extend/2013-July/000166.html create mode 100644 _build/static/archives/extend/2013-July/000167.html create mode 100644 _build/static/archives/extend/2013-July/000168.html create mode 100644 _build/static/archives/extend/2013-July/000169.html create mode 100644 _build/static/archives/extend/2013-July/000170.html create mode 100644 _build/static/archives/extend/2013-July/000171.html create mode 100644 _build/static/archives/extend/2013-July/000172.html create mode 100644 _build/static/archives/extend/2013-July/000173.html create mode 100644 _build/static/archives/extend/2013-July/000174.html create mode 100644 _build/static/archives/extend/2013-July/000175.html create mode 100644 _build/static/archives/extend/2013-July/author.html create mode 100644 _build/static/archives/extend/2013-July/date.html create mode 120000 _build/static/archives/extend/2013-July/index.html create mode 100644 _build/static/archives/extend/2013-July/subject.html create mode 100644 _build/static/archives/extend/2013-July/thread.html create mode 100644 _build/static/archives/extend/2013-June.txt create mode 100644 _build/static/archives/extend/2013-June/000150.html create mode 100644 _build/static/archives/extend/2013-June/000151.html create mode 100644 _build/static/archives/extend/2013-June/author.html create mode 100644 _build/static/archives/extend/2013-June/date.html create mode 120000 _build/static/archives/extend/2013-June/index.html create mode 100644 _build/static/archives/extend/2013-June/subject.html create mode 100644 _build/static/archives/extend/2013-June/thread.html create mode 100644 _build/static/archives/extend/2013-March.txt create mode 100644 _build/static/archives/extend/2013-March/000066.html create mode 100644 _build/static/archives/extend/2013-March/000067.html create mode 100644 _build/static/archives/extend/2013-March/000068.html create mode 100644 _build/static/archives/extend/2013-March/000069.html create mode 100644 _build/static/archives/extend/2013-March/000070.html create mode 100644 _build/static/archives/extend/2013-March/000071.html create mode 100644 _build/static/archives/extend/2013-March/000072.html create mode 100644 _build/static/archives/extend/2013-March/author.html create mode 100644 _build/static/archives/extend/2013-March/date.html create mode 120000 _build/static/archives/extend/2013-March/index.html create mode 100644 _build/static/archives/extend/2013-March/subject.html create mode 100644 _build/static/archives/extend/2013-March/thread.html create mode 100644 _build/static/archives/extend/2013-May.txt create mode 100644 _build/static/archives/extend/2013-May/000128.html create mode 100644 _build/static/archives/extend/2013-May/000129.html create mode 100644 _build/static/archives/extend/2013-May/000130.html create mode 100644 _build/static/archives/extend/2013-May/000131.html create mode 100644 _build/static/archives/extend/2013-May/000132.html create mode 100644 _build/static/archives/extend/2013-May/000133.html create mode 100644 _build/static/archives/extend/2013-May/000134.html create mode 100644 _build/static/archives/extend/2013-May/000135.html create mode 100644 _build/static/archives/extend/2013-May/000136.html create mode 100644 _build/static/archives/extend/2013-May/000137.html create mode 100644 _build/static/archives/extend/2013-May/000138.html create mode 100644 _build/static/archives/extend/2013-May/000139.html create mode 100644 _build/static/archives/extend/2013-May/000140.html create mode 100644 _build/static/archives/extend/2013-May/000141.html create mode 100644 _build/static/archives/extend/2013-May/000142.html create mode 100644 _build/static/archives/extend/2013-May/000143.html create mode 100644 _build/static/archives/extend/2013-May/000144.html create mode 100644 _build/static/archives/extend/2013-May/000145.html create mode 100644 _build/static/archives/extend/2013-May/000146.html create mode 100644 _build/static/archives/extend/2013-May/000147.html create mode 100644 _build/static/archives/extend/2013-May/000148.html create mode 100644 _build/static/archives/extend/2013-May/000149.html create mode 100644 _build/static/archives/extend/2013-May/author.html create mode 100644 _build/static/archives/extend/2013-May/date.html create mode 120000 _build/static/archives/extend/2013-May/index.html create mode 100644 _build/static/archives/extend/2013-May/subject.html create mode 100644 _build/static/archives/extend/2013-May/thread.html create mode 100644 _build/static/archives/extend/2013-November.txt create mode 100644 _build/static/archives/extend/2013-November/000294.html create mode 100644 _build/static/archives/extend/2013-November/000295.html create mode 100644 _build/static/archives/extend/2013-November/000296.html create mode 100644 _build/static/archives/extend/2013-November/000297.html create mode 100644 _build/static/archives/extend/2013-November/000298.html create mode 100644 _build/static/archives/extend/2013-November/000299.html create mode 100644 _build/static/archives/extend/2013-November/000300.html create mode 100644 _build/static/archives/extend/2013-November/000301.html create mode 100644 _build/static/archives/extend/2013-November/000302.html create mode 100644 _build/static/archives/extend/2013-November/000303.html create mode 100644 _build/static/archives/extend/2013-November/000304.html create mode 100644 _build/static/archives/extend/2013-November/000305.html create mode 100644 _build/static/archives/extend/2013-November/000306.html create mode 100644 _build/static/archives/extend/2013-November/000307.html create mode 100644 _build/static/archives/extend/2013-November/000308.html create mode 100644 _build/static/archives/extend/2013-November/000309.html create mode 100644 _build/static/archives/extend/2013-November/000310.html create mode 100644 _build/static/archives/extend/2013-November/000311.html create mode 100644 _build/static/archives/extend/2013-November/000312.html create mode 100644 _build/static/archives/extend/2013-November/000313.html create mode 100644 _build/static/archives/extend/2013-November/author.html create mode 100644 _build/static/archives/extend/2013-November/date.html create mode 120000 _build/static/archives/extend/2013-November/index.html create mode 100644 _build/static/archives/extend/2013-November/subject.html create mode 100644 _build/static/archives/extend/2013-November/thread.html create mode 100644 _build/static/archives/extend/2013-October.txt create mode 100644 _build/static/archives/extend/2013-October/000255.html create mode 100644 _build/static/archives/extend/2013-October/000256.html create mode 100644 _build/static/archives/extend/2013-October/000257.html create mode 100644 _build/static/archives/extend/2013-October/000258.html create mode 100644 _build/static/archives/extend/2013-October/000259.html create mode 100644 _build/static/archives/extend/2013-October/000260.html create mode 100644 _build/static/archives/extend/2013-October/000261.html create mode 100644 _build/static/archives/extend/2013-October/000262.html create mode 100644 _build/static/archives/extend/2013-October/000263.html create mode 100644 _build/static/archives/extend/2013-October/000264.html create mode 100644 _build/static/archives/extend/2013-October/000265.html create mode 100644 _build/static/archives/extend/2013-October/000266.html create mode 100644 _build/static/archives/extend/2013-October/000267.html create mode 100644 _build/static/archives/extend/2013-October/000268.html create mode 100644 _build/static/archives/extend/2013-October/000269.html create mode 100644 _build/static/archives/extend/2013-October/000270.html create mode 100644 _build/static/archives/extend/2013-October/000271.html create mode 100644 _build/static/archives/extend/2013-October/000272.html create mode 100644 _build/static/archives/extend/2013-October/000273.html create mode 100644 _build/static/archives/extend/2013-October/000274.html create mode 100644 _build/static/archives/extend/2013-October/000275.html create mode 100644 _build/static/archives/extend/2013-October/000276.html create mode 100644 _build/static/archives/extend/2013-October/000277.html create mode 100644 _build/static/archives/extend/2013-October/000278.html create mode 100644 _build/static/archives/extend/2013-October/000279.html create mode 100644 _build/static/archives/extend/2013-October/000280.html create mode 100644 _build/static/archives/extend/2013-October/000281.html create mode 100644 _build/static/archives/extend/2013-October/000282.html create mode 100644 _build/static/archives/extend/2013-October/000283.html create mode 100644 _build/static/archives/extend/2013-October/000284.html create mode 100644 _build/static/archives/extend/2013-October/000285.html create mode 100644 _build/static/archives/extend/2013-October/000286.html create mode 100644 _build/static/archives/extend/2013-October/000287.html create mode 100644 _build/static/archives/extend/2013-October/000288.html create mode 100644 _build/static/archives/extend/2013-October/000289.html create mode 100644 _build/static/archives/extend/2013-October/000290.html create mode 100644 _build/static/archives/extend/2013-October/000291.html create mode 100644 _build/static/archives/extend/2013-October/000292.html create mode 100644 _build/static/archives/extend/2013-October/000293.html create mode 100644 _build/static/archives/extend/2013-October/author.html create mode 100644 _build/static/archives/extend/2013-October/date.html create mode 120000 _build/static/archives/extend/2013-October/index.html create mode 100644 _build/static/archives/extend/2013-October/subject.html create mode 100644 _build/static/archives/extend/2013-October/thread.html create mode 100644 _build/static/archives/extend/2013-September.txt create mode 100644 _build/static/archives/extend/2013-September/000227.html create mode 100644 _build/static/archives/extend/2013-September/000228.html create mode 100644 _build/static/archives/extend/2013-September/000229.html create mode 100644 _build/static/archives/extend/2013-September/000230.html create mode 100644 _build/static/archives/extend/2013-September/000231.html create mode 100644 _build/static/archives/extend/2013-September/000232.html create mode 100644 _build/static/archives/extend/2013-September/000233.html create mode 100644 _build/static/archives/extend/2013-September/000234.html create mode 100644 _build/static/archives/extend/2013-September/000235.html create mode 100644 _build/static/archives/extend/2013-September/000236.html create mode 100644 _build/static/archives/extend/2013-September/000237.html create mode 100644 _build/static/archives/extend/2013-September/000238.html create mode 100644 _build/static/archives/extend/2013-September/000239.html create mode 100644 _build/static/archives/extend/2013-September/000240.html create mode 100644 _build/static/archives/extend/2013-September/000241.html create mode 100644 _build/static/archives/extend/2013-September/000242.html create mode 100644 _build/static/archives/extend/2013-September/000243.html create mode 100644 _build/static/archives/extend/2013-September/000244.html create mode 100644 _build/static/archives/extend/2013-September/000245.html create mode 100644 _build/static/archives/extend/2013-September/000246.html create mode 100644 _build/static/archives/extend/2013-September/000247.html create mode 100644 _build/static/archives/extend/2013-September/000248.html create mode 100644 _build/static/archives/extend/2013-September/000249.html create mode 100644 _build/static/archives/extend/2013-September/000250.html create mode 100644 _build/static/archives/extend/2013-September/000251.html create mode 100644 _build/static/archives/extend/2013-September/000252.html create mode 100644 _build/static/archives/extend/2013-September/000253.html create mode 100644 _build/static/archives/extend/2013-September/000254.html create mode 100644 _build/static/archives/extend/2013-September/author.html create mode 100644 _build/static/archives/extend/2013-September/date.html create mode 120000 _build/static/archives/extend/2013-September/index.html create mode 100644 _build/static/archives/extend/2013-September/subject.html create mode 100644 _build/static/archives/extend/2013-September/thread.html create mode 100644 _build/static/archives/extend/2014-April.txt create mode 100644 _build/static/archives/extend/2014-April/000364.html create mode 100644 _build/static/archives/extend/2014-April/000365.html create mode 100644 _build/static/archives/extend/2014-April/000366.html create mode 100644 _build/static/archives/extend/2014-April/000367.html create mode 100644 _build/static/archives/extend/2014-April/000368.html create mode 100644 _build/static/archives/extend/2014-April/000369.html create mode 100644 _build/static/archives/extend/2014-April/000370.html create mode 100644 _build/static/archives/extend/2014-April/000371.html create mode 100644 _build/static/archives/extend/2014-April/000372.html create mode 100644 _build/static/archives/extend/2014-April/000373.html create mode 100644 _build/static/archives/extend/2014-April/000374.html create mode 100644 _build/static/archives/extend/2014-April/000375.html create mode 100644 _build/static/archives/extend/2014-April/000376.html create mode 100644 _build/static/archives/extend/2014-April/000377.html create mode 100644 _build/static/archives/extend/2014-April/000378.html create mode 100644 _build/static/archives/extend/2014-April/000379.html create mode 100644 _build/static/archives/extend/2014-April/000380.html create mode 100644 _build/static/archives/extend/2014-April/000381.html create mode 100644 _build/static/archives/extend/2014-April/000382.html create mode 100644 _build/static/archives/extend/2014-April/author.html create mode 100644 _build/static/archives/extend/2014-April/date.html create mode 120000 _build/static/archives/extend/2014-April/index.html create mode 100644 _build/static/archives/extend/2014-April/subject.html create mode 100644 _build/static/archives/extend/2014-April/thread.html create mode 100644 _build/static/archives/extend/2014-August.txt create mode 100644 _build/static/archives/extend/2014-August/000417.html create mode 100644 _build/static/archives/extend/2014-August/000418.html create mode 100644 _build/static/archives/extend/2014-August/000419.html create mode 100644 _build/static/archives/extend/2014-August/000420.html create mode 100644 _build/static/archives/extend/2014-August/000421.html create mode 100644 _build/static/archives/extend/2014-August/000422.html create mode 100644 _build/static/archives/extend/2014-August/000423.html create mode 100644 _build/static/archives/extend/2014-August/000424.html create mode 100644 _build/static/archives/extend/2014-August/000425.html create mode 100644 _build/static/archives/extend/2014-August/000426.html create mode 100644 _build/static/archives/extend/2014-August/000427.html create mode 100644 _build/static/archives/extend/2014-August/000428.html create mode 100644 _build/static/archives/extend/2014-August/000429.html create mode 100644 _build/static/archives/extend/2014-August/000430.html create mode 100644 _build/static/archives/extend/2014-August/000431.html create mode 100644 _build/static/archives/extend/2014-August/000432.html create mode 100644 _build/static/archives/extend/2014-August/000433.html create mode 100644 _build/static/archives/extend/2014-August/000434.html create mode 100644 _build/static/archives/extend/2014-August/000435.html create mode 100644 _build/static/archives/extend/2014-August/000436.html create mode 100644 _build/static/archives/extend/2014-August/000437.html create mode 100644 _build/static/archives/extend/2014-August/000438.html create mode 100644 _build/static/archives/extend/2014-August/000439.html create mode 100644 _build/static/archives/extend/2014-August/000440.html create mode 100644 _build/static/archives/extend/2014-August/000441.html create mode 100644 _build/static/archives/extend/2014-August/000442.html create mode 100644 _build/static/archives/extend/2014-August/000443.html create mode 100644 _build/static/archives/extend/2014-August/000444.html create mode 100644 _build/static/archives/extend/2014-August/000445.html create mode 100644 _build/static/archives/extend/2014-August/000446.html create mode 100644 _build/static/archives/extend/2014-August/000447.html create mode 100644 _build/static/archives/extend/2014-August/000448.html create mode 100644 _build/static/archives/extend/2014-August/000449.html create mode 100644 _build/static/archives/extend/2014-August/000450.html create mode 100644 _build/static/archives/extend/2014-August/000451.html create mode 100644 _build/static/archives/extend/2014-August/000452.html create mode 100644 _build/static/archives/extend/2014-August/000453.html create mode 100644 _build/static/archives/extend/2014-August/000454.html create mode 100644 _build/static/archives/extend/2014-August/000455.html create mode 100644 _build/static/archives/extend/2014-August/000456.html create mode 100644 _build/static/archives/extend/2014-August/000457.html create mode 100644 _build/static/archives/extend/2014-August/author.html create mode 100644 _build/static/archives/extend/2014-August/date.html create mode 120000 _build/static/archives/extend/2014-August/index.html create mode 100644 _build/static/archives/extend/2014-August/subject.html create mode 100644 _build/static/archives/extend/2014-August/thread.html create mode 100644 _build/static/archives/extend/2014-December.txt create mode 100644 _build/static/archives/extend/2014-December/000483.html create mode 100644 _build/static/archives/extend/2014-December/author.html create mode 100644 _build/static/archives/extend/2014-December/date.html create mode 120000 _build/static/archives/extend/2014-December/index.html create mode 100644 _build/static/archives/extend/2014-December/subject.html create mode 100644 _build/static/archives/extend/2014-December/thread.html create mode 100644 _build/static/archives/extend/2014-February.txt create mode 100644 _build/static/archives/extend/2014-February/000324.html create mode 100644 _build/static/archives/extend/2014-February/000325.html create mode 100644 _build/static/archives/extend/2014-February/000326.html create mode 100644 _build/static/archives/extend/2014-February/000327.html create mode 100644 _build/static/archives/extend/2014-February/000328.html create mode 100644 _build/static/archives/extend/2014-February/000329.html create mode 100644 _build/static/archives/extend/2014-February/000330.html create mode 100644 _build/static/archives/extend/2014-February/000331.html create mode 100644 _build/static/archives/extend/2014-February/000332.html create mode 100644 _build/static/archives/extend/2014-February/000333.html create mode 100644 _build/static/archives/extend/2014-February/000334.html create mode 100644 _build/static/archives/extend/2014-February/000335.html create mode 100644 _build/static/archives/extend/2014-February/000336.html create mode 100644 _build/static/archives/extend/2014-February/000337.html create mode 100644 _build/static/archives/extend/2014-February/000338.html create mode 100644 _build/static/archives/extend/2014-February/000339.html create mode 100644 _build/static/archives/extend/2014-February/author.html create mode 100644 _build/static/archives/extend/2014-February/date.html create mode 120000 _build/static/archives/extend/2014-February/index.html create mode 100644 _build/static/archives/extend/2014-February/subject.html create mode 100644 _build/static/archives/extend/2014-February/thread.html create mode 100644 _build/static/archives/extend/2014-January.txt create mode 100644 _build/static/archives/extend/2014-January/000321.html create mode 100644 _build/static/archives/extend/2014-January/000322.html create mode 100644 _build/static/archives/extend/2014-January/000323.html create mode 100644 _build/static/archives/extend/2014-January/author.html create mode 100644 _build/static/archives/extend/2014-January/date.html create mode 120000 _build/static/archives/extend/2014-January/index.html create mode 100644 _build/static/archives/extend/2014-January/subject.html create mode 100644 _build/static/archives/extend/2014-January/thread.html create mode 100644 _build/static/archives/extend/2014-July.txt create mode 100644 _build/static/archives/extend/2014-July/000405.html create mode 100644 _build/static/archives/extend/2014-July/000406.html create mode 100644 _build/static/archives/extend/2014-July/000407.html create mode 100644 _build/static/archives/extend/2014-July/000408.html create mode 100644 _build/static/archives/extend/2014-July/000409.html create mode 100644 _build/static/archives/extend/2014-July/000410.html create mode 100644 _build/static/archives/extend/2014-July/000411.html create mode 100644 _build/static/archives/extend/2014-July/000412.html create mode 100644 _build/static/archives/extend/2014-July/000413.html create mode 100644 _build/static/archives/extend/2014-July/000414.html create mode 100644 _build/static/archives/extend/2014-July/000415.html create mode 100644 _build/static/archives/extend/2014-July/000416.html create mode 100644 _build/static/archives/extend/2014-July/author.html create mode 100644 _build/static/archives/extend/2014-July/date.html create mode 120000 _build/static/archives/extend/2014-July/index.html create mode 100644 _build/static/archives/extend/2014-July/subject.html create mode 100644 _build/static/archives/extend/2014-July/thread.html create mode 100644 _build/static/archives/extend/2014-June.txt create mode 100644 _build/static/archives/extend/2014-June/000390.html create mode 100644 _build/static/archives/extend/2014-June/000391.html create mode 100644 _build/static/archives/extend/2014-June/000392.html create mode 100644 _build/static/archives/extend/2014-June/000393.html create mode 100644 _build/static/archives/extend/2014-June/000394.html create mode 100644 _build/static/archives/extend/2014-June/000395.html create mode 100644 _build/static/archives/extend/2014-June/000396.html create mode 100644 _build/static/archives/extend/2014-June/000397.html create mode 100644 _build/static/archives/extend/2014-June/000398.html create mode 100644 _build/static/archives/extend/2014-June/000399.html create mode 100644 _build/static/archives/extend/2014-June/000400.html create mode 100644 _build/static/archives/extend/2014-June/000401.html create mode 100644 _build/static/archives/extend/2014-June/000402.html create mode 100644 _build/static/archives/extend/2014-June/000403.html create mode 100644 _build/static/archives/extend/2014-June/000404.html create mode 100644 _build/static/archives/extend/2014-June/author.html create mode 100644 _build/static/archives/extend/2014-June/date.html create mode 120000 _build/static/archives/extend/2014-June/index.html create mode 100644 _build/static/archives/extend/2014-June/subject.html create mode 100644 _build/static/archives/extend/2014-June/thread.html create mode 100644 _build/static/archives/extend/2014-March.txt create mode 100644 _build/static/archives/extend/2014-March/000340.html create mode 100644 _build/static/archives/extend/2014-March/000341.html create mode 100644 _build/static/archives/extend/2014-March/000342.html create mode 100644 _build/static/archives/extend/2014-March/000343.html create mode 100644 _build/static/archives/extend/2014-March/000344.html create mode 100644 _build/static/archives/extend/2014-March/000345.html create mode 100644 _build/static/archives/extend/2014-March/000346.html create mode 100644 _build/static/archives/extend/2014-March/000347.html create mode 100644 _build/static/archives/extend/2014-March/000348.html create mode 100644 _build/static/archives/extend/2014-March/000349.html create mode 100644 _build/static/archives/extend/2014-March/000350.html create mode 100644 _build/static/archives/extend/2014-March/000351.html create mode 100644 _build/static/archives/extend/2014-March/000352.html create mode 100644 _build/static/archives/extend/2014-March/000353.html create mode 100644 _build/static/archives/extend/2014-March/000354.html create mode 100644 _build/static/archives/extend/2014-March/000355.html create mode 100644 _build/static/archives/extend/2014-March/000356.html create mode 100644 _build/static/archives/extend/2014-March/000357.html create mode 100644 _build/static/archives/extend/2014-March/000358.html create mode 100644 _build/static/archives/extend/2014-March/000359.html create mode 100644 _build/static/archives/extend/2014-March/000360.html create mode 100644 _build/static/archives/extend/2014-March/000361.html create mode 100644 _build/static/archives/extend/2014-March/000362.html create mode 100644 _build/static/archives/extend/2014-March/000363.html create mode 100644 _build/static/archives/extend/2014-March/author.html create mode 100644 _build/static/archives/extend/2014-March/date.html create mode 120000 _build/static/archives/extend/2014-March/index.html create mode 100644 _build/static/archives/extend/2014-March/subject.html create mode 100644 _build/static/archives/extend/2014-March/thread.html create mode 100644 _build/static/archives/extend/2014-May.txt create mode 100644 _build/static/archives/extend/2014-May/000383.html create mode 100644 _build/static/archives/extend/2014-May/000384.html create mode 100644 _build/static/archives/extend/2014-May/000385.html create mode 100644 _build/static/archives/extend/2014-May/000386.html create mode 100644 _build/static/archives/extend/2014-May/000387.html create mode 100644 _build/static/archives/extend/2014-May/000388.html create mode 100644 _build/static/archives/extend/2014-May/000389.html create mode 100644 _build/static/archives/extend/2014-May/author.html create mode 100644 _build/static/archives/extend/2014-May/date.html create mode 120000 _build/static/archives/extend/2014-May/index.html create mode 100644 _build/static/archives/extend/2014-May/subject.html create mode 100644 _build/static/archives/extend/2014-May/thread.html create mode 100644 _build/static/archives/extend/2014-November.txt create mode 100644 _build/static/archives/extend/2014-November/000474.html create mode 100644 _build/static/archives/extend/2014-November/000475.html create mode 100644 _build/static/archives/extend/2014-November/000476.html create mode 100644 _build/static/archives/extend/2014-November/000477.html create mode 100644 _build/static/archives/extend/2014-November/000478.html create mode 100644 _build/static/archives/extend/2014-November/000479.html create mode 100644 _build/static/archives/extend/2014-November/000480.html create mode 100644 _build/static/archives/extend/2014-November/000481.html create mode 100644 _build/static/archives/extend/2014-November/000482.html create mode 100644 _build/static/archives/extend/2014-November/author.html create mode 100644 _build/static/archives/extend/2014-November/date.html create mode 120000 _build/static/archives/extend/2014-November/index.html create mode 100644 _build/static/archives/extend/2014-November/subject.html create mode 100644 _build/static/archives/extend/2014-November/thread.html create mode 100644 _build/static/archives/extend/2014-October.txt create mode 100644 _build/static/archives/extend/2014-October/000468.html create mode 100644 _build/static/archives/extend/2014-October/000469.html create mode 100644 _build/static/archives/extend/2014-October/000470.html create mode 100644 _build/static/archives/extend/2014-October/000471.html create mode 100644 _build/static/archives/extend/2014-October/000472.html create mode 100644 _build/static/archives/extend/2014-October/000473.html create mode 100644 _build/static/archives/extend/2014-October/author.html create mode 100644 _build/static/archives/extend/2014-October/date.html create mode 120000 _build/static/archives/extend/2014-October/index.html create mode 100644 _build/static/archives/extend/2014-October/subject.html create mode 100644 _build/static/archives/extend/2014-October/thread.html create mode 100644 _build/static/archives/extend/2014-September.txt create mode 100644 _build/static/archives/extend/2014-September/000458.html create mode 100644 _build/static/archives/extend/2014-September/000459.html create mode 100644 _build/static/archives/extend/2014-September/000460.html create mode 100644 _build/static/archives/extend/2014-September/000461.html create mode 100644 _build/static/archives/extend/2014-September/000462.html create mode 100644 _build/static/archives/extend/2014-September/000463.html create mode 100644 _build/static/archives/extend/2014-September/000464.html create mode 100644 _build/static/archives/extend/2014-September/000465.html create mode 100644 _build/static/archives/extend/2014-September/000466.html create mode 100644 _build/static/archives/extend/2014-September/000467.html create mode 100644 _build/static/archives/extend/2014-September/author.html create mode 100644 _build/static/archives/extend/2014-September/date.html create mode 120000 _build/static/archives/extend/2014-September/index.html create mode 100644 _build/static/archives/extend/2014-September/subject.html create mode 100644 _build/static/archives/extend/2014-September/thread.html create mode 100644 _build/static/archives/extend/2015-April.txt create mode 100644 _build/static/archives/extend/2015-April/000527.html create mode 100644 _build/static/archives/extend/2015-April/000528.html create mode 100644 _build/static/archives/extend/2015-April/000529.html create mode 100644 _build/static/archives/extend/2015-April/000530.html create mode 100644 _build/static/archives/extend/2015-April/author.html create mode 100644 _build/static/archives/extend/2015-April/date.html create mode 120000 _build/static/archives/extend/2015-April/index.html create mode 100644 _build/static/archives/extend/2015-April/subject.html create mode 100644 _build/static/archives/extend/2015-April/thread.html create mode 100644 _build/static/archives/extend/2015-August.txt create mode 100644 _build/static/archives/extend/2015-August/000547.html create mode 100644 _build/static/archives/extend/2015-August/000548.html create mode 100644 _build/static/archives/extend/2015-August/000549.html create mode 100644 _build/static/archives/extend/2015-August/author.html create mode 100644 _build/static/archives/extend/2015-August/date.html create mode 120000 _build/static/archives/extend/2015-August/index.html create mode 100644 _build/static/archives/extend/2015-August/subject.html create mode 100644 _build/static/archives/extend/2015-August/thread.html create mode 100644 _build/static/archives/extend/2015-February.txt create mode 100644 _build/static/archives/extend/2015-February/000510.html create mode 100644 _build/static/archives/extend/2015-February/000511.html create mode 100644 _build/static/archives/extend/2015-February/000512.html create mode 100644 _build/static/archives/extend/2015-February/000513.html create mode 100644 _build/static/archives/extend/2015-February/author.html create mode 100644 _build/static/archives/extend/2015-February/date.html create mode 120000 _build/static/archives/extend/2015-February/index.html create mode 100644 _build/static/archives/extend/2015-February/subject.html create mode 100644 _build/static/archives/extend/2015-February/thread.html create mode 100644 _build/static/archives/extend/2015-January.txt create mode 100644 _build/static/archives/extend/2015-January/000484.html create mode 100644 _build/static/archives/extend/2015-January/000485.html create mode 100644 _build/static/archives/extend/2015-January/000486.html create mode 100644 _build/static/archives/extend/2015-January/000487.html create mode 100644 _build/static/archives/extend/2015-January/000488.html create mode 100644 _build/static/archives/extend/2015-January/000489.html create mode 100644 _build/static/archives/extend/2015-January/000490.html create mode 100644 _build/static/archives/extend/2015-January/000491.html create mode 100644 _build/static/archives/extend/2015-January/000492.html create mode 100644 _build/static/archives/extend/2015-January/000493.html create mode 100644 _build/static/archives/extend/2015-January/000494.html create mode 100644 _build/static/archives/extend/2015-January/000495.html create mode 100644 _build/static/archives/extend/2015-January/000496.html create mode 100644 _build/static/archives/extend/2015-January/000497.html create mode 100644 _build/static/archives/extend/2015-January/000498.html create mode 100644 _build/static/archives/extend/2015-January/000499.html create mode 100644 _build/static/archives/extend/2015-January/000500.html create mode 100644 _build/static/archives/extend/2015-January/000501.html create mode 100644 _build/static/archives/extend/2015-January/000502.html create mode 100644 _build/static/archives/extend/2015-January/000503.html create mode 100644 _build/static/archives/extend/2015-January/000504.html create mode 100644 _build/static/archives/extend/2015-January/000505.html create mode 100644 _build/static/archives/extend/2015-January/000506.html create mode 100644 _build/static/archives/extend/2015-January/000507.html create mode 100644 _build/static/archives/extend/2015-January/000508.html create mode 100644 _build/static/archives/extend/2015-January/000509.html create mode 100644 _build/static/archives/extend/2015-January/author.html create mode 100644 _build/static/archives/extend/2015-January/date.html create mode 120000 _build/static/archives/extend/2015-January/index.html create mode 100644 _build/static/archives/extend/2015-January/subject.html create mode 100644 _build/static/archives/extend/2015-January/thread.html create mode 100644 _build/static/archives/extend/2015-July.txt create mode 100644 _build/static/archives/extend/2015-July/000545.html create mode 100644 _build/static/archives/extend/2015-July/000546.html create mode 100644 _build/static/archives/extend/2015-July/author.html create mode 100644 _build/static/archives/extend/2015-July/date.html create mode 120000 _build/static/archives/extend/2015-July/index.html create mode 100644 _build/static/archives/extend/2015-July/subject.html create mode 100644 _build/static/archives/extend/2015-July/thread.html create mode 100644 _build/static/archives/extend/2015-June.txt create mode 100644 _build/static/archives/extend/2015-June/000531.html create mode 100644 _build/static/archives/extend/2015-June/000532.html create mode 100644 _build/static/archives/extend/2015-June/000533.html create mode 100644 _build/static/archives/extend/2015-June/000534.html create mode 100644 _build/static/archives/extend/2015-June/000535.html create mode 100644 _build/static/archives/extend/2015-June/000536.html create mode 100644 _build/static/archives/extend/2015-June/000537.html create mode 100644 _build/static/archives/extend/2015-June/000538.html create mode 100644 _build/static/archives/extend/2015-June/000539.html create mode 100644 _build/static/archives/extend/2015-June/000540.html create mode 100644 _build/static/archives/extend/2015-June/000541.html create mode 100644 _build/static/archives/extend/2015-June/000542.html create mode 100644 _build/static/archives/extend/2015-June/000543.html create mode 100644 _build/static/archives/extend/2015-June/000544.html create mode 100644 _build/static/archives/extend/2015-June/author.html create mode 100644 _build/static/archives/extend/2015-June/date.html create mode 120000 _build/static/archives/extend/2015-June/index.html create mode 100644 _build/static/archives/extend/2015-June/subject.html create mode 100644 _build/static/archives/extend/2015-June/thread.html create mode 100644 _build/static/archives/extend/2015-March.txt create mode 100644 _build/static/archives/extend/2015-March/000514.html create mode 100644 _build/static/archives/extend/2015-March/000515.html create mode 100644 _build/static/archives/extend/2015-March/000516.html create mode 100644 _build/static/archives/extend/2015-March/000517.html create mode 100644 _build/static/archives/extend/2015-March/000518.html create mode 100644 _build/static/archives/extend/2015-March/000519.html create mode 100644 _build/static/archives/extend/2015-March/000520.html create mode 100644 _build/static/archives/extend/2015-March/000521.html create mode 100644 _build/static/archives/extend/2015-March/000522.html create mode 100644 _build/static/archives/extend/2015-March/000523.html create mode 100644 _build/static/archives/extend/2015-March/000524.html create mode 100644 _build/static/archives/extend/2015-March/000525.html create mode 100644 _build/static/archives/extend/2015-March/000526.html create mode 100644 _build/static/archives/extend/2015-March/author.html create mode 100644 _build/static/archives/extend/2015-March/date.html create mode 120000 _build/static/archives/extend/2015-March/index.html create mode 100644 _build/static/archives/extend/2015-March/subject.html create mode 100644 _build/static/archives/extend/2015-March/thread.html create mode 100644 _build/static/archives/extend/2015-October.txt create mode 100644 _build/static/archives/extend/2015-October/000557.html create mode 100644 _build/static/archives/extend/2015-October/000558.html create mode 100644 _build/static/archives/extend/2015-October/author.html create mode 100644 _build/static/archives/extend/2015-October/date.html create mode 120000 _build/static/archives/extend/2015-October/index.html create mode 100644 _build/static/archives/extend/2015-October/subject.html create mode 100644 _build/static/archives/extend/2015-October/thread.html create mode 100644 _build/static/archives/extend/2015-September.txt create mode 100644 _build/static/archives/extend/2015-September/000550.html create mode 100644 _build/static/archives/extend/2015-September/000551.html create mode 100644 _build/static/archives/extend/2015-September/000552.html create mode 100644 _build/static/archives/extend/2015-September/000553.html create mode 100644 _build/static/archives/extend/2015-September/000554.html create mode 100644 _build/static/archives/extend/2015-September/000555.html create mode 100644 _build/static/archives/extend/2015-September/000556.html create mode 100644 _build/static/archives/extend/2015-September/author.html create mode 100644 _build/static/archives/extend/2015-September/date.html create mode 120000 _build/static/archives/extend/2015-September/index.html create mode 100644 _build/static/archives/extend/2015-September/subject.html create mode 100644 _build/static/archives/extend/2015-September/thread.html create mode 100644 _build/static/archives/extend/attachments/20121030/3de26c28/attachment.html create mode 100644 _build/static/archives/extend/attachments/20121216/2d0b0da5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20121220/631f7f13/attachment.html create mode 100644 _build/static/archives/extend/attachments/20121221/8bfb2f11/attachment.html create mode 100644 _build/static/archives/extend/attachments/20121221/945f636e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130103/bae06e70/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130103/d9dbc1a5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130103/f6c7fd25/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130117/19bfde40/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130125/7d0820aa/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130204/3c258140/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130204/c34e6aa6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130210/1b9560c2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130212/09008370/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130212/dc0291b4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130213/41b12a6d/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130213/a992c0b6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130221/fc119c69/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130317/2ee0bc92/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130317/2f20f449/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130413/f1b70800/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130415/03f35a62/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130415/59aaeef2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130419/383515dd/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130419/bf0e8ef9/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130425/35ee7614/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130426/09f3ed34/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130426/9d234e27/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130426/b1e8ae7a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130430/c86f8fdb/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130512/65929751/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130512/dd43116e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130517/629071b8/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130519/db7f08ab/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130520/3cc045e8/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130520/5134ba32/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130605/568478c8/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130718/79e075b8/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130718/a3961a6f/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130718/c50bef17/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130718/d65f1aaf/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130723/3e51c337/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130802/4f7baee0/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130805/9fd5783b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/1c70f542/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/1cd82d09/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/4e596577/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/8f4a69b4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/a886396a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130816/ff4591a1/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130820/b203ebe2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130915/c9a5340e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130916/dedbf486/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130916/f55d10f5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130919/0a4bcb6c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130919/9614ef5e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130920/32352505/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130920/4c005881/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130920/6e3fa036/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130922/6e925e9d/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130922/77e355ff/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130926/28d38e59/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130926/3a77fe04/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130926/d34b33e3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130928/41b322fd/attachment.html create mode 100644 _build/static/archives/extend/attachments/20130928/b1333ac2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131002/4463e3fa/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131007/863e7358/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131007/fdef2170/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131008/8752fdd7/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131009/7c03cefc/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131009/cc05d6f5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131015/203060cc/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131015/591e8649/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131015/94506752/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131015/bac10460/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131016/abe38a1a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131016/edbc349c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131018/00d4df12/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131029/3df30c1d/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131029/5fc5da75/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131029/a9204600/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131030/0ab7c8ee/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131030/3ea4ac64/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131030/460453c8/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131030/6e8ec2f0/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131115/79d7b0ce/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131117/41119d53/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131120/6c3ab980/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131120/7808a87a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131120/792230f4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131120/82981048/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131121/7d69dbf7/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131122/11ccc1ef/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131127/11da2202/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131127/20905d98/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131212/2697fbaa/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131215/7c20ac97/attachment.html create mode 100644 _build/static/archives/extend/attachments/20131227/35c9f6e5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140203/088e7e6a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140203/104f8577/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140203/2982cff3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140203/e84f6223/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140207/904cc7bf/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/1781c9d2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/2ae635a6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/a2b35e2f/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/b46e2bab/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/bf26d573/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140210/fa72e2ba/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140303/52007acc/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140306/24422ef2/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140306/6fa8fe3b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140306/a517215b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140314/b2f802d3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140411/9e3c6c32/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140420/bf45e4d0/attachment-0001.bin create mode 100644 _build/static/archives/extend/attachments/20140420/bf45e4d0/attachment.bin create mode 100644 _build/static/archives/extend/attachments/20140520/32454f85/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140520/699b72b3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140520/cf7632e9/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140604/269377d0/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140604/269377d0/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140604/2bce99e1/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140604/2bce99e1/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140604/407d3443/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140604/407d3443/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140605/3ba15fb3/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140605/3ba15fb3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140605/46eee3c0/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140605/46eee3c0/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140606/b992565e/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140606/b992565e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140708/35d8806d/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140708/35d8806d/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140708/497ef9a1/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140708/497ef9a1/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140805/2c08b12c/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140805/2c08b12c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140805/34528764/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140805/34528764/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140805/a3d520b7/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140805/a3d520b7/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140805/f3705f7b/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140805/f3705f7b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140805/fb1bc75c/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140805/fb1bc75c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140813/7903a29a/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140813/7903a29a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140814/64f862ef/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140814/64f862ef/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140823/51e1d345/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140823/51e1d345/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140824/89d3a7f6/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140824/89d3a7f6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140824/f35e1e51/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140824/f35e1e51/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140827/91c1e017/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140827/91c1e017/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140915/26d4e023/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140915/26d4e023/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140915/5f3302e4/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140915/5f3302e4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140915/d97a6072/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140915/d97a6072/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140929/84fe21a4/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140929/84fe21a4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140930/6d952ce6/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140930/6d952ce6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20140930/ef46837f/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20140930/ef46837f/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141014/77f74bf0/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141014/77f74bf0/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141014/d89bced6/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141014/d89bced6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141031/fc6724a7/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141031/fc6724a7/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141106/85a93e04/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141106/85a93e04/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141110/a4b469a5/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141110/a4b469a5/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141122/bcb1d17c/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141122/bcb1d17c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141124/9ceef28a/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141124/9ceef28a/attachment.html create mode 100644 _build/static/archives/extend/attachments/20141225/ff94953b/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20141225/ff94953b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150114/3267f73e/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150114/3267f73e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150125/370811e4/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150125/370811e4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150127/1916d612/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150127/1916d612/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150215/9d2f5de1/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150215/9d2f5de1/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150623/3556788c/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150623/3556788c/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150623/69dfc8e4/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150623/69dfc8e4/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150623/dd7366a3/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150623/dd7366a3/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150623/f7c19f68/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150623/f7c19f68/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150623/fcdb2d7b/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150623/fcdb2d7b/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150624/204c1308/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150624/204c1308/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150624/6d15706e/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150624/6d15706e/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150624/72689ab9/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150624/72689ab9/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150624/b67122b6/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150624/b67122b6/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150713/eb33ab46/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150713/eb33ab46/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150824/7576a7ab/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150824/7576a7ab/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150923/fc8e4ef7/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150923/fc8e4ef7/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150924/6a9add86/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150924/6a9add86/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150930/7f5e7422/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150930/7f5e7422/attachment.html create mode 100644 _build/static/archives/extend/attachments/20150930/ee98f926/attachment-0001.html create mode 100644 _build/static/archives/extend/attachments/20150930/ee98f926/attachment.html create mode 100644 _build/static/archives/extend/index.html (limited to '_build/static') diff --git a/_build/static/archives/extend/2012-December.txt b/_build/static/archives/extend/2012-December.txt new file mode 100644 index 00000000..a6c891cb --- /dev/null +++ b/_build/static/archives/extend/2012-December.txt @@ -0,0 +1,591 @@ +From list1 at gjunka.com Wed Dec 12 22:14:50 2012 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Wed, 12 Dec 2012 21:14:50 +0000 +Subject: [99s-extend] Streaming response in cowboy question +Message-ID: <50C8F3CA.7040002@gjunka.com> + +I am implementing a proxy on top of Cowboy. Is it possible to stream the +response back to Cowboy as I receive it from the destination server? + +I am thinking about something like specifying a fun instead of Response +Body when sending the reply so that Cowboy could call it to receive the +response in chunks (see send_req in +https://github.com/cmullaparthi/ibrowse/blob/master/src/ibrowse.erl). + + + +From essen at ninenines.eu Wed Dec 12 22:30:46 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 12 Dec 2012 22:30:46 +0100 +Subject: [99s-extend] Streaming response in cowboy question +In-Reply-To: <50C8F3CA.7040002@gjunka.com> +References: <50C8F3CA.7040002@gjunka.com> +Message-ID: <50C8F786.9070109@ninenines.eu> + +On 12/12/2012 10:14 PM, Grzegorz Junka wrote: +> I am implementing a proxy on top of Cowboy. Is it possible to stream the +> response back to Cowboy as I receive it from the destination server? +> +> I am thinking about something like specifying a fun instead of Response +> Body when sending the reply so that Cowboy could call it to receive the +> response in chunks (see send_req in +> https://github.com/cmullaparthi/ibrowse/blob/master/src/ibrowse.erl). + +Lookup cowboy_req:set_resp_body_fun? Tell me if that fits your needs. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Sun Dec 16 19:24:00 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 16 Dec 2012 19:24:00 +0100 +Subject: [99s-extend] Nine Nines IRC Channel +Message-ID: <50CE11C0.5040505@ninenines.eu> + +Hello, + +I have started the #ninenines IRC Channel on irc.freenode.net for anyone +looking for quick help or willing to participate in Cowboy development +or any other related project (Ranch, Bullet, Sheriff and upcoming projects). + +Discussions will be centered about these projects and related subjects. + +Repositories will soon be updated with information about this IRC channel. + +Feel free to come and hang out. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From jeremy at playmesh.com Sun Dec 16 20:10:16 2012 +From: jeremy at playmesh.com (Jeremy Ong) +Date: Sun, 16 Dec 2012 11:10:16 -0800 +Subject: [99s-extend] Nine Nines IRC Channel +In-Reply-To: <50CE11C0.5040505@ninenines.eu> +References: <50CE11C0.5040505@ninenines.eu> +Message-ID: + +See you there! + +Jeremy (banachtarski) + + +On Sun, Dec 16, 2012 at 10:24 AM, Lo?c Hoguin wrote: + +> Hello, +> +> I have started the #ninenines IRC Channel on irc.freenode.net for anyone +> looking for quick help or willing to participate in Cowboy development or +> any other related project (Ranch, Bullet, Sheriff and upcoming projects). +> +> Discussions will be centered about these projects and related subjects. +> +> Repositories will soon be updated with information about this IRC channel. +> +> Feel free to come and hang out. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/**listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From erlang at rambocoder.com Fri Dec 21 04:34:23 2012 +From: erlang at rambocoder.com (rambocoder) +Date: Thu, 20 Dec 2012 22:34:23 -0500 +Subject: [99s-extend] Cowboy HTTPS connection memory usage +Message-ID: + +Does anybody know either from benchmarks or real world data what is the +average memory footprint of each concurrent HTTPS connection to cowboy? + +SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache +Bench I test with reuses the session id or it does not. + +BTW, what makes an erlang api "documented" vs "undocumented". For example +ssl:session_info/1 function here ( +https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411 ) has a +spec and a short doc, but session_info is not described +http://www.erlang.org/doc/man/ssl.html .ssl:session_info/1 is a useful +function to be able to track if the load generator is reusing the SSL +session_id or it is generating new one, because that would make all the +difference during measurement due to Erlang caching SSL sessions by default. + +Sincerely, + +rambocoder +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Dec 21 12:45:23 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 21 Dec 2012 12:45:23 +0100 +Subject: [99s-extend] Cowboy HTTPS connection memory usage +In-Reply-To: +References: +Message-ID: <50D44BD3.4030008@ninenines.eu> + +On 12/21/2012 04:34 AM, rambocoder wrote: +> Does anybody know either from benchmarks or real world data what is the +> average memory footprint of each concurrent HTTPS connection to cowboy? + +I don't have anything, sorry. I'm guessing it consumes a lot more than +TCP though. + +> SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache +> Bench I test with reuses the session id or it does not. + +I wouldn't know, but I wouldn't trust Apache Bench doing the right +thing. Any other benchmark tool usually works better in my experience. + +> BTW, what makes an erlang api "documented" vs "undocumented". For +> example ssl:session_info/1 function here ( +> https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411 ) has +> a spec and a short doc, but session_info is not described +> http://www.erlang.org/doc/man/ssl.html .ssl:session_info/1 is a useful +> function to be able to track if the load generator is reusing the SSL +> session_id or it is generating new one, because that would make all the +> difference during measurement due to Erlang caching SSL sessions by default. + +The documentation is separate (they're not using edoc). It's perhaps not +deemed useful enough for documenting it. I wouldn't worry about using it +for measurements though. + +Try asking Ingela on the ML about it, perhaps they just forgot to +document it. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From erlang at rambocoder.com Fri Dec 21 17:49:37 2012 +From: erlang at rambocoder.com (rambocoder) +Date: Fri, 21 Dec 2012 11:49:37 -0500 +Subject: [99s-extend] Cowboy HTTPS connection memory usage +In-Reply-To: <50D44BD3.4030008@ninenines.eu> +References: + <50D44BD3.4030008@ninenines.eu> +Message-ID: + +In my preliminary testing, I used Jmeter this morning since it's an +easy GUI load testing app and this is what I am seeing: + +With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true], when +I establish 1K concurrent connections via HTTPS, each connection takes up +about 68K of memory. + +Unfortunately, after about 1050-1200 connections, on my test server the +Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers, while +up to that point the scheduler's load was oscillating up and down. Using +the Observer, there is only 1 ssl_connection_sup in the ssl application, +having to deal with 1000+ gen_fsm workers, so that might be the bottleneck. +Since the ulimit on my server is 50000 I don't think I am hitting any type +of file handler's limit. + +Lo?c and the group, am I missing some setting that is causing the scheduler +to go to 100% CPU and the run que in observer to be 99? + +Sincerely, + +rambocoder + + +On Fri, Dec 21, 2012 at 6:45 AM, Lo?c Hoguin wrote: + +> On 12/21/2012 04:34 AM, rambocoder wrote: +> +>> Does anybody know either from benchmarks or real world data what is the +>> average memory footprint of each concurrent HTTPS connection to cowboy? +>> +> +> I don't have anything, sorry. I'm guessing it consumes a lot more than TCP +> though. +> +> +> SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache +>> Bench I test with reuses the session id or it does not. +>> +> +> I wouldn't know, but I wouldn't trust Apache Bench doing the right thing. +> Any other benchmark tool usually works better in my experience. +> +> +> BTW, what makes an erlang api "documented" vs "undocumented". For +>> example ssl:session_info/1 function here ( +>> https://github.com/erlang/otp/**blob/maint/lib/ssl/src/ssl.**erl#L411) has +>> a spec and a short doc, but session_info is not described +>> http://www.erlang.org/doc/man/**ssl.html.ssl:session_info/1 is a useful +>> function to be able to track if the load generator is reusing the SSL +>> session_id or it is generating new one, because that would make all the +>> difference during measurement due to Erlang caching SSL sessions by +>> default. +>> +> +> The documentation is separate (they're not using edoc). It's perhaps not +> deemed useful enough for documenting it. I wouldn't worry about using it +> for measurements though. +> +> Try asking Ingela on the ML about it, perhaps they just forgot to document +> it. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Dec 21 17:51:14 2012 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 21 Dec 2012 17:51:14 +0100 +Subject: [99s-extend] Cowboy HTTPS connection memory usage +In-Reply-To: +References: + <50D44BD3.4030008@ninenines.eu> + +Message-ID: <50D49382.7020309@ninenines.eu> + +Can you try enabling eprof to see where the VM spends its time? + +On 12/21/2012 05:49 PM, rambocoder wrote: +> In my preliminary testing, I used Jmeter this morning since it's an +> easy GUI load testing app and this is what I am seeing: +> +> With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true], +> when I establish 1K concurrent connections via HTTPS, each connection +> takes up about 68K of memory. +> +> Unfortunately, after about 1050-1200 connections, on my test server the +> Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers, +> while up to that point the scheduler's load was oscillating up and down. +> Using the Observer, there is only 1 ssl_connection_sup in the ssl +> application, having to deal with 1000+ gen_fsm workers, so that might be +> the bottleneck. Since the ulimit on my server is 50000 I don't think I +> am hitting any type of file handler's limit. +> +> Lo?c and the group, am I missing some setting that is causing the +> scheduler to go to 100% CPU and the run que in observer to be 99? +> +> Sincerely, +> +> rambocoder +> +> +> +> On Fri, Dec 21, 2012 at 6:45 AM, Lo?c Hoguin > wrote: +> +> On 12/21/2012 04:34 AM, rambocoder wrote: +> +> Does anybody know either from benchmarks or real world data what +> is the +> average memory footprint of each concurrent HTTPS connection to +> cowboy? +> +> +> I don't have anything, sorry. I'm guessing it consumes a lot more +> than TCP though. +> +> +> SSL app in Erlang reuses SSL session-ids so I am not sure if the +> Apache +> Bench I test with reuses the session id or it does not. +> +> +> I wouldn't know, but I wouldn't trust Apache Bench doing the right +> thing. Any other benchmark tool usually works better in my experience. +> +> +> BTW, what makes an erlang api "documented" vs "undocumented". For +> example ssl:session_info/1 function here ( +> https://github.com/erlang/otp/__blob/maint/lib/ssl/src/ssl.__erl#L411 +> +> ) has +> a spec and a short doc, but session_info is not described +> http://www.erlang.org/doc/man/__ssl.html +> .ssl:session_info/1 is +> a useful +> function to be able to track if the load generator is reusing +> the SSL +> session_id or it is generating new one, because that would make +> all the +> difference during measurement due to Erlang caching SSL sessions +> by default. +> +> +> The documentation is separate (they're not using edoc). It's perhaps +> not deemed useful enough for documenting it. I wouldn't worry about +> using it for measurements though. +> +> Try asking Ingela on the ML about it, perhaps they just forgot to +> document it. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From erlang at rambocoder.com Fri Dec 21 20:25:10 2012 +From: erlang at rambocoder.com (rambocoder) +Date: Fri, 21 Dec 2012 14:25:10 -0500 +Subject: [99s-extend] Cowboy HTTPS connection memory usage +In-Reply-To: <50D49382.7020309@ninenines.eu> +References: + <50D44BD3.4030008@ninenines.eu> + + <50D49382.7020309@ninenines.eu> +Message-ID: + +Long story short, I solved the problem by adding {max_connections, 50000} +to cowboy:start_https because it default to 1024 at +https://github.com/extend/ranch/blob/master/src/ranch_listener_sup.erl#L30 + +However, before I figured out that setting, I did run eprof and these are +the function calls it was spending most of it's time on + + +FUNCTION CALLS % TIME [uS / +CALLS] +-------- ----- --- ---- + [----------] +dict:get_slot/2 174 1.73 1658 [ + 9.53] +dict:on_bucket/3 171 1.77 1701 [ + 9.95] +erlang:setelement/3 684 3.23 3098 [ + 4.53] +dict:store_bkt_val/3 600 5.24 5028 [ + 8.38] + +Then I ran etop and it showed that ranch_acceptor:maybe_wait had the most +reductions were, so I looked at the code in that +https://github.com/extend/ranch/blob/master/src/ranch_acceptor.erl#L72 and +realized that like a newb I did not set the maximum connections for the +listener :) + +Problem solved. Looks like I won't need to put HAProxy in front of Cowboy +after all. + +Thank you, + +rambocoder + +On Fri, Dec 21, 2012 at 11:51 AM, Lo?c Hoguin wrote: + +> Can you try enabling eprof to see where the VM spends its time? +> +> +> On 12/21/2012 05:49 PM, rambocoder wrote: +> +>> In my preliminary testing, I used Jmeter this morning since it's an +>> easy GUI load testing app and this is what I am seeing: +>> +>> With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true], +>> when I establish 1K concurrent connections via HTTPS, each connection +>> takes up about 68K of memory. +>> +>> Unfortunately, after about 1050-1200 connections, on my test server the +>> Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers, +>> while up to that point the scheduler's load was oscillating up and down. +>> Using the Observer, there is only 1 ssl_connection_sup in the ssl +>> application, having to deal with 1000+ gen_fsm workers, so that might be +>> the bottleneck. Since the ulimit on my server is 50000 I don't think I +>> am hitting any type of file handler's limit. +>> +>> Lo?c and the group, am I missing some setting that is causing the +>> scheduler to go to 100% CPU and the run que in observer to be 99? +>> +>> Sincerely, +>> +>> rambocoder +>> +>> +>> +>> On Fri, Dec 21, 2012 at 6:45 AM, Lo?c Hoguin > > wrote: +>> +>> On 12/21/2012 04:34 AM, rambocoder wrote: +>> +>> Does anybody know either from benchmarks or real world data what +>> is the +>> average memory footprint of each concurrent HTTPS connection to +>> cowboy? +>> +>> +>> I don't have anything, sorry. I'm guessing it consumes a lot more +>> than TCP though. +>> +>> +>> SSL app in Erlang reuses SSL session-ids so I am not sure if the +>> Apache +>> Bench I test with reuses the session id or it does not. +>> +>> +>> I wouldn't know, but I wouldn't trust Apache Bench doing the right +>> thing. Any other benchmark tool usually works better in my experience. +>> +>> +>> BTW, what makes an erlang api "documented" vs "undocumented". For +>> example ssl:session_info/1 function here ( +>> https://github.com/erlang/otp/**__blob/maint/lib/ssl/src/ssl._** +>> _erl#L411 +>> +>> > ssl.erl#L411 +>> > +>> ) has +>> a spec and a short doc, but session_info is not described +>> http://www.erlang.org/doc/man/**__ssl.html +>> +>> > +>> .ssl:session_info/1 is +>> a useful +>> function to be able to track if the load generator is reusing +>> the SSL +>> session_id or it is generating new one, because that would make +>> all the +>> difference during measurement due to Erlang caching SSL sessions +>> by default. +>> +>> +>> The documentation is separate (they're not using edoc). It's perhaps +>> not deemed useful enough for documenting it. I wouldn't worry about +>> using it for measurements though. +>> +>> Try asking Ingela on the ML about it, perhaps they just forgot to +>> document it. +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> +>> +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Dec 24 23:42:43 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 24 Dec 2012 23:42:43 +0100 +Subject: [99s-extend] [ANN] Ranch 0.6.0 Xmas Edition Released +Message-ID: <50D8DA63.2060600@ninenines.eu> + +Ho ho ho! + +I have just tagged version 0.6.0 of the Ranch project! + +Ranch is a socket acceptor pool for TCP protocols. + + https://github.com/extend/ranch + +Ranch is used by the next version of Cowboy, 0.8.0, set to be released +early February, but also in Basho's Riak multi-data center replication +amongst others. + +All tickets have been resolved. A significant contribution was made by +Andrew Majorov to improve the fault tolerance capabilities of the +application, making sure it always restarts properly when things go +wrong. This has been made possible thanks to the amazing project from +Daniel Luna, chaos_monkey (https://github.com/dluna/chaos_monkey). + +The guide has also been improved and completed. + + http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction + +If the guide isn't enough, drop by our new IRC channel dedicated to +Cowboy, Ranch and all our other projects! #ninenines on Freenode. + +Following is the list of change since last time: + + * Improve fault tolerance thanks to chaos_monkey testing + * Add 'nodelay' option to transports + * Add 'verify' option to ranch_ssl transport + * Add 'socket' option to pass an already open socket to the listener + * Add Transport:sendfile/2 function (uses a fallback if unavailable) + * Allow IP tuples in Transport:connect/3 + * Add ranch:set_max_connections/2 to update the value live + * Add ranch:get_max_connections/1 to retrieve it + +We are always looking for feedback, especially now that there is no +ticket left open on this project. If you are using Ranch and have +questions or needs that it doesn't cover, please send them to us. + +Commercial support will be available starting from January, ping me if +you are interested. Details will be announced at a later time on the +ninenines.eu mailing list. + +I want to thank all contributors for helping this project by opening +tickets, sending patches and offering feedback. I am as always very +grateful for any and all contributions. I wouldn't have made it this far +without the tremendous help I receive everyday. + +Thanks to all and have a nice holiday! + +-- +Lo?c Hoguin +Erlang Santa +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2012-December/000018.html b/_build/static/archives/extend/2012-December/000018.html new file mode 100644 index 00000000..815316af --- /dev/null +++ b/_build/static/archives/extend/2012-December/000018.html @@ -0,0 +1,67 @@ + + + + [99s-extend] Streaming response in cowboy question + + + + + + + + + + +

[99s-extend] Streaming response in cowboy question

+ Grzegorz Junka + list1 at gjunka.com +
+ Wed Dec 12 22:14:50 CET 2012 +

+
+ +
I am implementing a proxy on top of Cowboy. Is it possible to stream the 
+response back to Cowboy as I receive it from the destination server?
+
+I am thinking about something like specifying a fun instead of Response 
+Body when sending the reply so that Cowboy could call it to receive the 
+response in chunks (see send_req in 
+https://github.com/cmullaparthi/ibrowse/blob/master/src/ibrowse.erl).
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000019.html b/_build/static/archives/extend/2012-December/000019.html new file mode 100644 index 00000000..910bc5d4 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000019.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Streaming response in cowboy question + + + + + + + + + + +

[99s-extend] Streaming response in cowboy question

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Dec 12 22:30:46 CET 2012 +

+
+ +
On 12/12/2012 10:14 PM, Grzegorz Junka wrote:
+> I am implementing a proxy on top of Cowboy. Is it possible to stream the
+> response back to Cowboy as I receive it from the destination server?
+>
+> I am thinking about something like specifying a fun instead of Response
+> Body when sending the reply so that Cowboy could call it to receive the
+> response in chunks (see send_req in
+> https://github.com/cmullaparthi/ibrowse/blob/master/src/ibrowse.erl).
+
+Lookup cowboy_req:set_resp_body_fun? Tell me if that fits your needs.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000020.html b/_build/static/archives/extend/2012-December/000020.html new file mode 100644 index 00000000..fb1ba508 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000020.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Nine Nines IRC Channel + + + + + + + + + + +

[99s-extend] Nine Nines IRC Channel

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Dec 16 19:24:00 CET 2012 +

+
+ +
Hello,
+
+I have started the #ninenines IRC Channel on irc.freenode.net for anyone 
+looking for quick help or willing to participate in Cowboy development 
+or any other related project (Ranch, Bullet, Sheriff and upcoming projects).
+
+Discussions will be centered about these projects and related subjects.
+
+Repositories will soon be updated with information about this IRC channel.
+
+Feel free to come and hang out.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000021.html b/_build/static/archives/extend/2012-December/000021.html new file mode 100644 index 00000000..6ae59076 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000021.html @@ -0,0 +1,92 @@ + + + + [99s-extend] Nine Nines IRC Channel + + + + + + + + + + +

[99s-extend] Nine Nines IRC Channel

+ Jeremy Ong + jeremy at playmesh.com +
+ Sun Dec 16 20:10:16 CET 2012 +

+
+ +
See you there!
+
+Jeremy (banachtarski)
+
+
+On Sun, Dec 16, 2012 at 10:24 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Hello,
+>
+> I have started the #ninenines IRC Channel on irc.freenode.net for anyone
+> looking for quick help or willing to participate in Cowboy development or
+> any other related project (Ranch, Bullet, Sheriff and upcoming projects).
+>
+> Discussions will be centered about these projects and related subjects.
+>
+> Repositories will soon be updated with information about this IRC channel.
+>
+> Feel free to come and hang out.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20121216/2d0b0da5/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000022.html b/_build/static/archives/extend/2012-December/000022.html new file mode 100644 index 00000000..5ac89e23 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000022.html @@ -0,0 +1,81 @@ + + + + [99s-extend] Cowboy HTTPS connection memory usage + + + + + + + + + + +

[99s-extend] Cowboy HTTPS connection memory usage

+ rambocoder + erlang at rambocoder.com +
+ Fri Dec 21 04:34:23 CET 2012 +

+
+ +
Does anybody know either from benchmarks or real world data what is the
+average memory footprint of each concurrent HTTPS connection to cowboy?
+
+SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache
+Bench I test with reuses the session id or it does not.
+
+BTW, what makes an erlang api "documented" vs "undocumented". For example
+ssl:session_info/1 function here (
+https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411 ) has a
+spec and a short doc, but session_info is not described
+http://www.erlang.org/doc/man/ssl.html .ssl:session_info/1 is a useful
+function to be able to track if the load generator is reusing the SSL
+session_id or it is generating new one, because that would make all the
+difference during measurement due to Erlang caching SSL sessions by default.
+
+Sincerely,
+
+rambocoder
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20121220/631f7f13/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000023.html b/_build/static/archives/extend/2012-December/000023.html new file mode 100644 index 00000000..c1214eef --- /dev/null +++ b/_build/static/archives/extend/2012-December/000023.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy HTTPS connection memory usage + + + + + + + + + + +

[99s-extend] Cowboy HTTPS connection memory usage

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Dec 21 12:45:23 CET 2012 +

+
+ +
On 12/21/2012 04:34 AM, rambocoder wrote:
+> Does anybody know either from benchmarks or real world data what is the
+> average memory footprint of each concurrent HTTPS connection to cowboy?
+
+I don't have anything, sorry. I'm guessing it consumes a lot more than 
+TCP though.
+
+> SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache
+> Bench I test with reuses the session id or it does not.
+
+I wouldn't know, but I wouldn't trust Apache Bench doing the right 
+thing. Any other benchmark tool usually works better in my experience.
+
+> BTW, what makes an erlang api "documented" vs "undocumented". For
+> example ssl:session_info/1 function here (
+> https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411 ) has
+> a spec and a short doc, but session_info is not described
+> http://www.erlang.org/doc/man/ssl.html .ssl:session_info/1 is a useful
+> function to be able to track if the load generator is reusing the SSL
+> session_id or it is generating new one, because that would make all the
+> difference during measurement due to Erlang caching SSL sessions by default.
+
+The documentation is separate (they're not using edoc). It's perhaps not 
+deemed useful enough for documenting it. I wouldn't worry about using it 
+for measurements though.
+
+Try asking Ingela on the ML about it, perhaps they just forgot to 
+document it.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000024.html b/_build/static/archives/extend/2012-December/000024.html new file mode 100644 index 00000000..f55a4f92 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000024.html @@ -0,0 +1,131 @@ + + + + [99s-extend] Cowboy HTTPS connection memory usage + + + + + + + + + + +

[99s-extend] Cowboy HTTPS connection memory usage

+ rambocoder + erlang at rambocoder.com +
+ Fri Dec 21 17:49:37 CET 2012 +

+
+ +
In my preliminary testing, I used Jmeter this morning since it's an
+easy GUI load testing app and this is what I am seeing:
+
+With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true], when
+I establish 1K concurrent connections via HTTPS, each connection takes up
+about 68K of memory.
+
+Unfortunately, after about 1050-1200 connections, on my test server the
+Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers, while
+up to that point the scheduler's load was oscillating up and down. Using
+the Observer, there is only 1 ssl_connection_sup  in the ssl application,
+having to deal with 1000+ gen_fsm workers, so that might be the bottleneck.
+Since the ulimit on my server is 50000 I don't think I am hitting any type
+of file handler's limit.
+
+Loïc and the group, am I missing some setting that is causing the scheduler
+to go to 100% CPU and the run que in observer to be 99?
+
+Sincerely,
+
+rambocoder
+
+
+On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 12/21/2012 04:34 AM, rambocoder wrote:
+>
+>> Does anybody know either from benchmarks or real world data what is the
+>> average memory footprint of each concurrent HTTPS connection to cowboy?
+>>
+>
+> I don't have anything, sorry. I'm guessing it consumes a lot more than TCP
+> though.
+>
+>
+>  SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache
+>> Bench I test with reuses the session id or it does not.
+>>
+>
+> I wouldn't know, but I wouldn't trust Apache Bench doing the right thing.
+> Any other benchmark tool usually works better in my experience.
+>
+>
+>  BTW, what makes an erlang api "documented" vs "undocumented". For
+>> example ssl:session_info/1 function here (
+>> https://github.com/erlang/otp/**blob/maint/lib/ssl/src/ssl.**erl#L411<https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411>) has
+>> a spec and a short doc, but session_info is not described
+>> http://www.erlang.org/doc/man/**ssl.html<http://www.erlang.org/doc/man/ssl.html>.ssl:session_info/1 is a useful
+>> function to be able to track if the load generator is reusing the SSL
+>> session_id or it is generating new one, because that would make all the
+>> difference during measurement due to Erlang caching SSL sessions by
+>> default.
+>>
+>
+> The documentation is separate (they're not using edoc). It's perhaps not
+> deemed useful enough for documenting it. I wouldn't worry about using it
+> for measurements though.
+>
+> Try asking Ingela on the ML about it, perhaps they just forgot to document
+> it.
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20121221/8bfb2f11/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000025.html b/_build/static/archives/extend/2012-December/000025.html new file mode 100644 index 00000000..498da5e8 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000025.html @@ -0,0 +1,157 @@ + + + + [99s-extend] Cowboy HTTPS connection memory usage + + + + + + + + + + +

[99s-extend] Cowboy HTTPS connection memory usage

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Dec 21 17:51:14 CET 2012 +

+
+ +
Can you try enabling eprof to see where the VM spends its time?
+
+On 12/21/2012 05:49 PM, rambocoder wrote:
+> In my preliminary testing, I used Jmeter this morning since it's an
+> easy GUI load testing app and this is what I am seeing:
+>
+> With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true],
+> when I establish 1K concurrent connections via HTTPS, each connection
+> takes up about 68K of memory.
+>
+> Unfortunately, after about 1050-1200 connections, on my test server the
+> Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers,
+> while up to that point the scheduler's load was oscillating up and down.
+> Using the Observer, there is only 1 ssl_connection_sup  in the ssl
+> application, having to deal with 1000+ gen_fsm workers, so that might be
+> the bottleneck. Since the ulimit on my server is 50000 I don't think I
+> am hitting any type of file handler's limit.
+>
+> Loïc and the group, am I missing some setting that is causing the
+> scheduler to go to 100% CPU and the run que in observer to be 99?
+>
+> Sincerely,
+>
+> rambocoder
+>
+>
+>
+> On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     On 12/21/2012 04:34 AM, rambocoder wrote:
+>
+>         Does anybody know either from benchmarks or real world data what
+>         is the
+>         average memory footprint of each concurrent HTTPS connection to
+>         cowboy?
+>
+>
+>     I don't have anything, sorry. I'm guessing it consumes a lot more
+>     than TCP though.
+>
+>
+>         SSL app in Erlang reuses SSL session-ids so I am not sure if the
+>         Apache
+>         Bench I test with reuses the session id or it does not.
+>
+>
+>     I wouldn't know, but I wouldn't trust Apache Bench doing the right
+>     thing. Any other benchmark tool usually works better in my experience.
+>
+>
+>         BTW, what makes an erlang api "documented" vs "undocumented". For
+>         example ssl:session_info/1 function here (
+>         https://github.com/erlang/otp/__blob/maint/lib/ssl/src/ssl.__erl#L411
+>         <https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411>
+>         ) has
+>         a spec and a short doc, but session_info is not described
+>         http://www.erlang.org/doc/man/__ssl.html
+>         <http://www.erlang.org/doc/man/ssl.html> .ssl:session_info/1 is
+>         a useful
+>         function to be able to track if the load generator is reusing
+>         the SSL
+>         session_id or it is generating new one, because that would make
+>         all the
+>         difference during measurement due to Erlang caching SSL sessions
+>         by default.
+>
+>
+>     The documentation is separate (they're not using edoc). It's perhaps
+>     not deemed useful enough for documenting it. I wouldn't worry about
+>     using it for measurements though.
+>
+>     Try asking Ingela on the ML about it, perhaps they just forgot to
+>     document it.
+>
+>     --
+>     Loďc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000026.html b/_build/static/archives/extend/2012-December/000026.html new file mode 100644 index 00000000..fcb9a5c6 --- /dev/null +++ b/_build/static/archives/extend/2012-December/000026.html @@ -0,0 +1,206 @@ + + + + [99s-extend] Cowboy HTTPS connection memory usage + + + + + + + + + + +

[99s-extend] Cowboy HTTPS connection memory usage

+ rambocoder + erlang at rambocoder.com +
+ Fri Dec 21 20:25:10 CET 2012 +

+
+ +
Long story short, I solved the problem by adding {max_connections, 50000}
+to cowboy:start_https because it default to 1024 at
+https://github.com/extend/ranch/blob/master/src/ranch_listener_sup.erl#L30
+
+However, before I figured out that setting, I did run eprof and these are
+the function calls it was spending most of it's time on
+
+
+FUNCTION                                    CALLS      %   TIME  [uS /
+CALLS]
+--------                                    -----    ---   ----
+ [----------]
+dict:get_slot/2                               174   1.73   1658  [
+ 9.53]
+dict:on_bucket/3                              171   1.77   1701  [
+ 9.95]
+erlang:setelement/3                           684   3.23   3098  [
+ 4.53]
+dict:store_bkt_val/3                          600   5.24   5028  [
+ 8.38]
+
+Then I ran etop and it showed that ranch_acceptor:maybe_wait had the most
+reductions were, so I looked at the code in that
+https://github.com/extend/ranch/blob/master/src/ranch_acceptor.erl#L72 and
+realized that like a newb I did not set the maximum connections for the
+listener :)
+
+Problem solved. Looks like I won't need to put HAProxy in front of Cowboy
+after all.
+
+Thank you,
+
+rambocoder
+
+On Fri, Dec 21, 2012 at 11:51 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Can you try enabling eprof to see where the VM spends its time?
+>
+>
+> On 12/21/2012 05:49 PM, rambocoder wrote:
+>
+>> In my preliminary testing, I used Jmeter this morning since it's an
+>> easy GUI load testing app and this is what I am seeing:
+>>
+>> With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true],
+>> when I establish 1K concurrent connections via HTTPS, each connection
+>> takes up about 68K of memory.
+>>
+>> Unfortunately, after about 1050-1200 connections, on my test server the
+>> Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers,
+>> while up to that point the scheduler's load was oscillating up and down.
+>> Using the Observer, there is only 1 ssl_connection_sup  in the ssl
+>> application, having to deal with 1000+ gen_fsm workers, so that might be
+>> the bottleneck. Since the ulimit on my server is 50000 I don't think I
+>> am hitting any type of file handler's limit.
+>>
+>> Loïc and the group, am I missing some setting that is causing the
+>> scheduler to go to 100% CPU and the run que in observer to be 99?
+>>
+>> Sincerely,
+>>
+>> rambocoder
+>>
+>>
+>>
+>> On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     On 12/21/2012 04:34 AM, rambocoder wrote:
+>>
+>>         Does anybody know either from benchmarks or real world data what
+>>         is the
+>>         average memory footprint of each concurrent HTTPS connection to
+>>         cowboy?
+>>
+>>
+>>     I don't have anything, sorry. I'm guessing it consumes a lot more
+>>     than TCP though.
+>>
+>>
+>>         SSL app in Erlang reuses SSL session-ids so I am not sure if the
+>>         Apache
+>>         Bench I test with reuses the session id or it does not.
+>>
+>>
+>>     I wouldn't know, but I wouldn't trust Apache Bench doing the right
+>>     thing. Any other benchmark tool usually works better in my experience.
+>>
+>>
+>>         BTW, what makes an erlang api "documented" vs "undocumented". For
+>>         example ssl:session_info/1 function here (
+>>         https://github.com/erlang/otp/**__blob/maint/lib/ssl/src/ssl._**
+>> _erl#L411<https://github.com/erlang/otp/__blob/maint/lib/ssl/src/ssl.__erl#L411>
+>>
+>>         <https://github.com/erlang/**otp/blob/maint/lib/ssl/src/**
+>> ssl.erl#L411<https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411>
+>> >
+>>         ) has
+>>         a spec and a short doc, but session_info is not described
+>>         http://www.erlang.org/doc/man/**__ssl.html<http://www.erlang.org/doc/man/__ssl.html>
+>>
+>>         <http://www.erlang.org/doc/**man/ssl.html<http://www.erlang.org/doc/man/ssl.html>>
+>> .ssl:session_info/1 is
+>>         a useful
+>>         function to be able to track if the load generator is reusing
+>>         the SSL
+>>         session_id or it is generating new one, because that would make
+>>         all the
+>>         difference during measurement due to Erlang caching SSL sessions
+>>         by default.
+>>
+>>
+>>     The documentation is separate (they're not using edoc). It's perhaps
+>>     not deemed useful enough for documenting it. I wouldn't worry about
+>>     using it for measurements though.
+>>
+>>     Try asking Ingela on the ML about it, perhaps they just forgot to
+>>     document it.
+>>
+>>     --
+>>     Loďc Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>
+>>
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loïc Hoguin
+>
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20121221/945f636e/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/000027.html b/_build/static/archives/extend/2012-December/000027.html new file mode 100644 index 00000000..37cf6add --- /dev/null +++ b/_build/static/archives/extend/2012-December/000027.html @@ -0,0 +1,115 @@ + + + + [99s-extend] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Dec 24 23:42:43 CET 2012 +

+
+ +
Ho ho ho!
+
+I have just tagged version 0.6.0 of the Ranch project!
+
+Ranch is a socket acceptor pool for TCP protocols.
+
+   https://github.com/extend/ranch
+
+Ranch is used by the next version of Cowboy, 0.8.0, set to be released 
+early February, but also in Basho's Riak multi-data center replication 
+amongst others.
+
+All tickets have been resolved. A significant contribution was made by 
+Andrew Majorov to improve the fault tolerance capabilities of the 
+application, making sure it always restarts properly when things go 
+wrong. This has been made possible thanks to the amazing project from 
+Daniel Luna, chaos_monkey (https://github.com/dluna/chaos_monkey).
+
+The guide has also been improved and completed.
+
+   http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction
+
+If the guide isn't enough, drop by our new IRC channel dedicated to 
+Cowboy, Ranch and all our other projects! #ninenines on Freenode.
+
+Following is the list of change since last time:
+
+  *  Improve fault tolerance thanks to chaos_monkey testing
+  *  Add 'nodelay' option to transports
+  *  Add 'verify' option to ranch_ssl transport
+  *  Add 'socket' option to pass an already open socket to the listener
+  *  Add Transport:sendfile/2 function (uses a fallback if unavailable)
+  *  Allow IP tuples in Transport:connect/3
+  *  Add ranch:set_max_connections/2 to update the value live
+  *  Add ranch:get_max_connections/1 to retrieve it
+
+We are always looking for feedback, especially now that there is no 
+ticket left open on this project. If you are using Ranch and have 
+questions or needs that it doesn't cover, please send them to us.
+
+Commercial support will be available starting from January, ping me if 
+you are interested. Details will be announced at a later time on the 
+ninenines.eu mailing list.
+
+I want to thank all contributors for helping this project by opening 
+tickets, sending patches and offering feedback. I am as always very 
+grateful for any and all contributions. I wouldn't have made it this far 
+without the tremendous help I receive everyday.
+
+Thanks to all and have a nice holiday!
+
+-- 
+Loïc Hoguin
+Erlang Santa
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-December/author.html b/_build/static/archives/extend/2012-December/author.html new file mode 100644 index 00000000..485a6f0b --- /dev/null +++ b/_build/static/archives/extend/2012-December/author.html @@ -0,0 +1,97 @@ + + + + The Extend December 2012 Archive by author + + + + + +

December 2012 Archives by author

+ +

Starting: Wed Dec 12 22:14:50 CET 2012
+ Ending: Mon Dec 24 23:42:43 CET 2012
+ Messages: 10

+

+

+ Last message date: + Mon Dec 24 23:42:43 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-December/date.html b/_build/static/archives/extend/2012-December/date.html new file mode 100644 index 00000000..c6482ffb --- /dev/null +++ b/_build/static/archives/extend/2012-December/date.html @@ -0,0 +1,97 @@ + + + + The Extend December 2012 Archive by date + + + + + +

December 2012 Archives by date

+ +

Starting: Wed Dec 12 22:14:50 CET 2012
+ Ending: Mon Dec 24 23:42:43 CET 2012
+ Messages: 10

+

+

+ Last message date: + Mon Dec 24 23:42:43 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-December/index.html b/_build/static/archives/extend/2012-December/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2012-December/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2012-December/subject.html b/_build/static/archives/extend/2012-December/subject.html new file mode 100644 index 00000000..4b1b63ee --- /dev/null +++ b/_build/static/archives/extend/2012-December/subject.html @@ -0,0 +1,97 @@ + + + + The Extend December 2012 Archive by subject + + + + + +

December 2012 Archives by subject

+ +

Starting: Wed Dec 12 22:14:50 CET 2012
+ Ending: Mon Dec 24 23:42:43 CET 2012
+ Messages: 10

+

+

+ Last message date: + Mon Dec 24 23:42:43 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-December/thread.html b/_build/static/archives/extend/2012-December/thread.html new file mode 100644 index 00000000..5658bece --- /dev/null +++ b/_build/static/archives/extend/2012-December/thread.html @@ -0,0 +1,117 @@ + + + + The Extend December 2012 Archive by thread + + + + + +

December 2012 Archives by thread

+ +

Starting: Wed Dec 12 22:14:50 CET 2012
+ Ending: Mon Dec 24 23:42:43 CET 2012
+ Messages: 10

+

+

+ Last message date: + Mon Dec 24 23:42:43 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-November.txt b/_build/static/archives/extend/2012-November.txt new file mode 100644 index 00000000..dedac05f --- /dev/null +++ b/_build/static/archives/extend/2012-November.txt @@ -0,0 +1,418 @@ +From essen at ninenines.eu Tue Nov 13 10:04:17 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 13 Nov 2012 10:04:17 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +Message-ID: <50A20D11.9020504@ninenines.eu> + +Hello! + +I have put my thoughts on routing at the following gist: + + https://gist.github.com/4064759 + +Please comment or cry in terror if you're against it! + +Thanks. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Tue Nov 13 15:12:59 2012 +From: thomas at oinksoft.com (Thomas Allen) +Date: Tue, 13 Nov 2012 09:12:59 -0500 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A20D11.9020504@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> +Message-ID: <20121113141259.GB17626@members.linode.com> + +On Tue, Nov 13, 2012 at 10:04:17AM +0100, Lo?c Hoguin wrote: +> Hello! +> +> I have put my thoughts on routing at the following gist: +> +> https://gist.github.com/4064759 +> +> Please comment or cry in terror if you're against it! + +I think that this looks very good. The current router handles all of my +use cases, and this bit of sugar will definitely help to speed up +development. + +As an aside, have you considered adding optional slash-add +functionality, so that /a/b will match "/a/b/"? This is pretty easy to +set up at the server level, but the front-line server doesn't know about +our dispatch rules and so it doesn't know if there is a matching +dispatch rule for the slash-added version of a given URL. + +Thomas + + +From essen at ninenines.eu Tue Nov 13 15:14:03 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 13 Nov 2012 15:14:03 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <20121113141259.GB17626@members.linode.com> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> +Message-ID: <50A255AB.8090207@ninenines.eu> + +On 11/13/2012 03:12 PM, Thomas Allen wrote: +> On Tue, Nov 13, 2012 at 10:04:17AM +0100, Lo?c Hoguin wrote: +>> Hello! +>> +>> I have put my thoughts on routing at the following gist: +>> +>> https://gist.github.com/4064759 +>> +>> Please comment or cry in terror if you're against it! +> +> I think that this looks very good. The current router handles all of my +> use cases, and this bit of sugar will definitely help to speed up +> development. +> +> As an aside, have you considered adding optional slash-add +> functionality, so that /a/b will match "/a/b/"? This is pretty easy to +> set up at the server level, but the front-line server doesn't know about +> our dispatch rules and so it doesn't know if there is a matching +> dispatch rule for the slash-added version of a given URL. + +/a/b already matches /a/b/. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Tue Nov 13 15:35:29 2012 +From: thomas at oinksoft.com (Thomas Allen) +Date: Tue, 13 Nov 2012 09:35:29 -0500 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A255AB.8090207@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> + <50A255AB.8090207@ninenines.eu> +Message-ID: <20121113143529.GC17626@members.linode.com> + +On Tue, Nov 13, 2012 at 03:14:03PM +0100, Lo?c Hoguin wrote: +> /a/b already matches /a/b/. + +Sorry for not being more precise: /a/b would result in a 301 redirect to +/a/b/ + +Thomas + + +From essen at ninenines.eu Tue Nov 13 15:41:35 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 13 Nov 2012 15:41:35 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <20121113143529.GC17626@members.linode.com> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> <50A255AB.8090207@ninenines.eu> + <20121113143529.GC17626@members.linode.com> +Message-ID: <50A25C1F.1050804@ninenines.eu> + +On 11/13/2012 03:35 PM, Thomas Allen wrote: +> On Tue, Nov 13, 2012 at 03:14:03PM +0100, Lo?c Hoguin wrote: +>> /a/b already matches /a/b/. +> +> Sorry for not being more precise: /a/b would result in a 301 redirect to +> /a/b/ + +Oh alright. Well they are equivalent URLs, so if you really need to +redirect I would do so in the handler directly, or through a request hook. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Tue Nov 13 16:12:14 2012 +From: thomas at oinksoft.com (Thomas Allen) +Date: Tue, 13 Nov 2012 10:12:14 -0500 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A25C1F.1050804@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> + <50A255AB.8090207@ninenines.eu> + <20121113143529.GC17626@members.linode.com> + <50A25C1F.1050804@ninenines.eu> +Message-ID: <20121113151214.GE17626@members.linode.com> + +On Tue, Nov 13, 2012 at 03:41:35PM +0100, Lo?c Hoguin wrote: +> Oh alright. Well they are equivalent URLs, so if you really need to +> redirect I would do so in the handler directly, or through a request +> hook. + +I suppose this suggests my next question ... how would one accomplish +this right now in Cowboy? I hope I'm correct in assuming that this will +involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not +understand how I will use match/3 with what I get from +cowboy_req:path/1. + +Thomas + + +From essen at ninenines.eu Tue Nov 13 16:22:48 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 13 Nov 2012 16:22:48 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <20121113151214.GE17626@members.linode.com> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> <50A255AB.8090207@ninenines.eu> + <20121113143529.GC17626@members.linode.com> <50A25C1F.1050804@ninenines.eu> + <20121113151214.GE17626@members.linode.com> +Message-ID: <50A265C8.8060505@ninenines.eu> + +On 11/13/2012 04:12 PM, Thomas Allen wrote: +> On Tue, Nov 13, 2012 at 03:41:35PM +0100, Lo?c Hoguin wrote: +>> Oh alright. Well they are equivalent URLs, so if you really need to +>> redirect I would do so in the handler directly, or through a request +>> hook. +> +> I suppose this suggests my next question ... how would one accomplish +> this right now in Cowboy? I hope I'm correct in assuming that this will +> involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not +> understand how I will use match/3 with what I get from +> cowboy_req:path/1. + +No, just check that cowboy_req:path/1 ends with $/, and if it doesn't +then redirect. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From dch at jsonified.com Tue Nov 13 16:42:53 2012 +From: dch at jsonified.com (Dave Cottlehuber) +Date: Tue, 13 Nov 2012 16:42:53 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A20D11.9020504@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> +Message-ID: + +On 13 November 2012 10:04, Lo?c Hoguin wrote: +> Hello! +> +> I have put my thoughts on routing at the following gist: +> +> https://gist.github.com/4064759 +> +> Please comment or cry in terror if you're against it! +> +> Thanks. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + +I actually commented on the gist, here's a copy for the ML: + +== dch == + +Looks very useful for me. I've not heard of imbrication until today, I +assume it is closest to nested optional components as used above. + +Having regex capability in the constraints would be great: + +{"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler, +Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red | +pink)$", [other_re_parameters]) , Handler, Opts} for example. + +== Lo?c == + +Yes, regex will be a possible constraint. Also checking for integer +value. Not sure what else we'll want. + +A+ +Dave + + +From essen at ninenines.eu Tue Nov 13 16:46:15 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 13 Nov 2012 16:46:15 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: +References: <50A20D11.9020504@ninenines.eu> + +Message-ID: <50A26B47.20001@ninenines.eu> + +On 11/13/2012 04:42 PM, Dave Cottlehuber wrote: +> On 13 November 2012 10:04, Lo?c Hoguin wrote: +>> Hello! +>> +>> I have put my thoughts on routing at the following gist: +>> +>> https://gist.github.com/4064759 +>> +>> Please comment or cry in terror if you're against it! +>> +>> Thanks. +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> I actually commented on the gist, here's a copy for the ML: +> +> == dch == +> +> Looks very useful for me. I've not heard of imbrication until today, I +> assume it is closest to nested optional components as used above. +> +> Having regex capability in the constraints would be great: +> +> {"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler, +> Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red | +> pink)$", [other_re_parameters]) , Handler, Opts} for example. +> +> == Lo?c == +> +> Yes, regex will be a possible constraint. Also checking for integer +> value. Not sure what else we'll want. + +I'll add to that that in the case of integer, we could very well bind +the value as an integer instead of as a binary, and avoid all these +pesky list_to_integer(binary_to_list(Value)). + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Tue Nov 13 17:10:04 2012 +From: thomas at oinksoft.com (Thomas Allen) +Date: Tue, 13 Nov 2012 11:10:04 -0500 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A265C8.8060505@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> + <20121113141259.GB17626@members.linode.com> + <50A255AB.8090207@ninenines.eu> + <20121113143529.GC17626@members.linode.com> + <50A25C1F.1050804@ninenines.eu> + <20121113151214.GE17626@members.linode.com> + <50A265C8.8060505@ninenines.eu> +Message-ID: <20121113161004.GF17626@members.linode.com> + +On Tue, Nov 13, 2012 at 04:22:48PM +0100, Lo?c Hoguin wrote: +> No, just check that cowboy_req:path/1 ends with $/, and if it +> doesn't then redirect. + +OK, so what I'm going for is to actually check for a valid URL with the +slash. I got it to work in current cowboy, but shield your eyes ... + +I do this "middleware" thing often ... this might be a misnomer as I +think some definitions of middleware specify that it be able to wrap the +request *and* the response. I digress ... + + %%% foo_app.erl: + + {ok, _} = cowboy:start_http(http, ?ACCEPTORS, + [{port, ?PORT}], + [{dispatch, Dispatch}, + {onrequest, fun(Req) -> + foo_middleware:all(Dispatch, Req) + end}] + ), + + + %% foo_middleware.erl: + + -define(MIDDLEWARE, [ + fun foo_middleware:slash/2, + fun foo_middleware:session/2, + fun foo_middleware:user/2 + ]). + + all(Dispatch, Req) -> + lists:foldl(fun(F, CurReq) -> F(Dispatch, CurReq) end, Req, + ?MIDDLEWARE). + + %% ... + + slash(Dispatch, Req) -> + {Path, _} = cowboy_req:path(Req), + case binary:last(Path) of + $/ -> Req; + _ -> + SlashPath = <>, + {Host, _} = cowboy_req:host(Req), + Match = cowboy_dispatcher:match(Dispatch, Host, + SlashPath), + case element(1, Match) of + ok -> + cowboy_req:reply(301, + [{<<"Location">>, SlashPath}], <<>>, Req); + error -> Req + end + end. + +So, I assume that any path not ending in "/" won't match. Another +version of this could toss that assumption, but then you're performing +an extra match on every request ... much better to use a '_' rule in +that case. + +One thing that is icky about using a fallback '_' handler, and the +reason I've elected to use onrequest for this example, is that I do not +see a way to access cowboy_protocol's state.dispatch to access these +rules. So, I enclose them in my `onrequest` fun. Would it be possible to +expose Dispatch? This has many applications, particularly for URL +reversing. + +Perhaps I am missing several things ;^) + +Thomas + + +From essen at ninenines.eu Thu Nov 29 11:46:10 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 29 Nov 2012 11:46:10 +0100 +Subject: [99s-extend] Proposal for Cowboy Routing +In-Reply-To: <50A20D11.9020504@ninenines.eu> +References: <50A20D11.9020504@ninenines.eu> +Message-ID: <50B73CF2.1010208@ninenines.eu> + +On 11/13/2012 10:04 AM, Lo?c Hoguin wrote: +> Hello! +> +> I have put my thoughts on routing at the following gist: +> +> https://gist.github.com/4064759 +> +> Please comment or cry in terror if you're against it! + +I have added more infos and changes as you can see in the comments here: +https://gist.github.com/4064759#comments Please feedback. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2012-November/000007.html b/_build/static/archives/extend/2012-November/000007.html new file mode 100644 index 00000000..8645ab93 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000007.html @@ -0,0 +1,74 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 13 10:04:17 CET 2012 +

+
+ +
Hello!
+
+I have put my thoughts on routing at the following gist:
+
+   https://gist.github.com/4064759
+
+Please comment or cry in terror if you're against it!
+
+Thanks.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000008.html b/_build/static/archives/extend/2012-November/000008.html new file mode 100644 index 00000000..8d97ff69 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000008.html @@ -0,0 +1,81 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Thomas Allen + thomas at oinksoft.com +
+ Tue Nov 13 15:12:59 CET 2012 +

+
+ +
On Tue, Nov 13, 2012 at 10:04:17AM +0100, Loïc Hoguin wrote:
+> Hello!
+> 
+> I have put my thoughts on routing at the following gist:
+> 
+>   https://gist.github.com/4064759
+> 
+> Please comment or cry in terror if you're against it!
+
+I think that this looks very good. The current router handles all of my
+use cases, and this bit of sugar will definitely help to speed up
+development.
+
+As an aside, have you considered adding optional slash-add
+functionality, so that /a/b will match "/a/b/"? This is pretty easy to
+set up at the server level, but the front-line server doesn't know about
+our dispatch rules and so it doesn't know if there is a matching
+dispatch rule for the slash-added version of a given URL.
+
+Thomas
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000009.html b/_build/static/archives/extend/2012-November/000009.html new file mode 100644 index 00000000..4acec8be --- /dev/null +++ b/_build/static/archives/extend/2012-November/000009.html @@ -0,0 +1,88 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 13 15:14:03 CET 2012 +

+
+ +
On 11/13/2012 03:12 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 10:04:17AM +0100, Loïc Hoguin wrote:
+>> Hello!
+>>
+>> I have put my thoughts on routing at the following gist:
+>>
+>>    https://gist.github.com/4064759
+>>
+>> Please comment or cry in terror if you're against it!
+>
+> I think that this looks very good. The current router handles all of my
+> use cases, and this bit of sugar will definitely help to speed up
+> development.
+>
+> As an aside, have you considered adding optional slash-add
+> functionality, so that /a/b will match "/a/b/"? This is pretty easy to
+> set up at the server level, but the front-line server doesn't know about
+> our dispatch rules and so it doesn't know if there is a matching
+> dispatch rule for the slash-added version of a given URL.
+
+/a/b already matches /a/b/.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000010.html b/_build/static/archives/extend/2012-November/000010.html new file mode 100644 index 00000000..0aea70b4 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000010.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Thomas Allen + thomas at oinksoft.com +
+ Tue Nov 13 15:35:29 CET 2012 +

+
+ +
On Tue, Nov 13, 2012 at 03:14:03PM +0100, Loïc Hoguin wrote:
+> /a/b already matches /a/b/.
+
+Sorry for not being more precise: /a/b would result in a 301 redirect to
+/a/b/
+
+Thomas
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000011.html b/_build/static/archives/extend/2012-November/000011.html new file mode 100644 index 00000000..d41b8146 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000011.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 13 15:41:35 CET 2012 +

+
+ +
On 11/13/2012 03:35 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 03:14:03PM +0100, Loïc Hoguin wrote:
+>> /a/b already matches /a/b/.
+>
+> Sorry for not being more precise: /a/b would result in a 301 redirect to
+> /a/b/
+
+Oh alright. Well they are equivalent URLs, so if you really need to 
+redirect I would do so in the handler directly, or through a request hook.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000012.html b/_build/static/archives/extend/2012-November/000012.html new file mode 100644 index 00000000..69f9c341 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000012.html @@ -0,0 +1,73 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Thomas Allen + thomas at oinksoft.com +
+ Tue Nov 13 16:12:14 CET 2012 +

+
+ +
On Tue, Nov 13, 2012 at 03:41:35PM +0100, Loïc Hoguin wrote:
+> Oh alright. Well they are equivalent URLs, so if you really need to
+> redirect I would do so in the handler directly, or through a request
+> hook.
+
+I suppose this suggests my next question ... how would one accomplish
+this right now in Cowboy? I hope I'm correct in assuming that this will
+involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not
+understand how I will use match/3 with what I get from
+cowboy_req:path/1.
+
+Thomas
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000013.html b/_build/static/archives/extend/2012-November/000013.html new file mode 100644 index 00000000..228a13af --- /dev/null +++ b/_build/static/archives/extend/2012-November/000013.html @@ -0,0 +1,81 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 13 16:22:48 CET 2012 +

+
+ +
On 11/13/2012 04:12 PM, Thomas Allen wrote:
+> On Tue, Nov 13, 2012 at 03:41:35PM +0100, Loïc Hoguin wrote:
+>> Oh alright. Well they are equivalent URLs, so if you really need to
+>> redirect I would do so in the handler directly, or through a request
+>> hook.
+>
+> I suppose this suggests my next question ... how would one accomplish
+> this right now in Cowboy? I hope I'm correct in assuming that this will
+> involve cowboy_dispatcher:match/3 in an onrequest fun, but I do not
+> understand how I will use match/3 with what I get from
+> cowboy_req:path/1.
+
+No, just check that cowboy_req:path/1 ends with $/, and if it doesn't 
+then redirect.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000014.html b/_build/static/archives/extend/2012-November/000014.html new file mode 100644 index 00000000..6db60e4a --- /dev/null +++ b/_build/static/archives/extend/2012-November/000014.html @@ -0,0 +1,102 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Dave Cottlehuber + dch at jsonified.com +
+ Tue Nov 13 16:42:53 CET 2012 +

+
+ +
On 13 November 2012 10:04, Loïc Hoguin <essen at ninenines.eu> wrote:
+> Hello!
+>
+> I have put my thoughts on routing at the following gist:
+>
+>   https://gist.github.com/4064759
+>
+> Please comment or cry in terror if you're against it!
+>
+> Thanks.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+I actually commented on the gist, here's a copy for the ML:
+
+== dch ==
+
+Looks very useful for me. I've not heard of imbrication until today, I
+assume it is closest to nested optional components as used above.
+
+Having regex capability in the constraints would be great:
+
+{"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler,
+Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red |
+pink)$", [other_re_parameters]) , Handler, Opts} for example.
+
+== Loïc ==
+
+Yes, regex will be a possible constraint. Also checking for integer
+value. Not sure what else we'll want.
+
+A+
+Dave
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000015.html b/_build/static/archives/extend/2012-November/000015.html new file mode 100644 index 00000000..5b48a7db --- /dev/null +++ b/_build/static/archives/extend/2012-November/000015.html @@ -0,0 +1,110 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 13 16:46:15 CET 2012 +

+
+ +
On 11/13/2012 04:42 PM, Dave Cottlehuber wrote:
+> On 13 November 2012 10:04, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> Hello!
+>>
+>> I have put my thoughts on routing at the following gist:
+>>
+>>    https://gist.github.com/4064759
+>>
+>> Please comment or cry in terror if you're against it!
+>>
+>> Thanks.
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>
+> I actually commented on the gist, here's a copy for the ML:
+>
+> == dch ==
+>
+> Looks very useful for me. I've not heard of imbrication until today, I
+> assume it is closest to nested optional components as used above.
+>
+> Having regex capability in the constraints would be great:
+>
+> {"/cars/:name/:color", [{color, in, [blue, red, pink]}], Handler,
+> Opts} might be {"/cars/:name/:color", [{color, regex, "^(blue | red |
+> pink)$", [other_re_parameters]) , Handler, Opts} for example.
+>
+> == Loïc ==
+>
+> Yes, regex will be a possible constraint. Also checking for integer
+> value. Not sure what else we'll want.
+
+I'll add to that that in the case of integer, we could very well bind 
+the value as an integer instead of as a binary, and avoid all these 
+pesky list_to_integer(binary_to_list(Value)).
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000016.html b/_build/static/archives/extend/2012-November/000016.html new file mode 100644 index 00000000..d87a2074 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000016.html @@ -0,0 +1,129 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Thomas Allen + thomas at oinksoft.com +
+ Tue Nov 13 17:10:04 CET 2012 +

+
+ +
On Tue, Nov 13, 2012 at 04:22:48PM +0100, Loïc Hoguin wrote:
+> No, just check that cowboy_req:path/1 ends with $/, and if it
+> doesn't then redirect.
+
+OK, so what I'm going for is to actually check for a valid URL with the
+slash. I got it to work in current cowboy, but shield your eyes ...
+
+I do this "middleware" thing often ... this might be a misnomer as I
+think some definitions of middleware specify that it be able to wrap the
+request *and* the response. I digress ...
+
+    %%% foo_app.erl:
+
+    {ok, _} = cowboy:start_http(http, ?ACCEPTORS,
+        [{port, ?PORT}],
+        [{dispatch, Dispatch},
+         {onrequest, fun(Req) ->
+             foo_middleware:all(Dispatch, Req)
+          end}]
+    ),
+
+
+    %% foo_middleware.erl:
+
+    -define(MIDDLEWARE, [
+        fun foo_middleware:slash/2,
+        fun foo_middleware:session/2,
+        fun foo_middleware:user/2
+    ]).
+
+    all(Dispatch, Req) ->
+        lists:foldl(fun(F, CurReq) -> F(Dispatch, CurReq) end, Req,
+            ?MIDDLEWARE).
+
+    %% ...
+
+    slash(Dispatch, Req) ->
+        {Path, _} = cowboy_req:path(Req),
+        case binary:last(Path) of
+            $/ -> Req;
+            _ ->
+                SlashPath = <<Path/bitstring, "/">>,
+                {Host, _} = cowboy_req:host(Req),
+                Match = cowboy_dispatcher:match(Dispatch, Host,
+                    SlashPath),
+                case element(1, Match) of
+                    ok ->
+                        cowboy_req:reply(301,
+                            [{<<"Location">>, SlashPath}], <<>>, Req);
+                    error -> Req
+                end
+        end.
+
+So, I assume that any path not ending in "/" won't match. Another
+version of this could toss that assumption, but then you're performing
+an extra match on every request ... much better to use a '_' rule in
+that case.
+
+One thing that is icky about using a fallback '_' handler, and the
+reason I've elected to use onrequest for this example, is that I do not
+see a way to access cowboy_protocol's state.dispatch to access these
+rules. So, I enclose them in my `onrequest` fun. Would it be possible to
+expose Dispatch? This has many applications, particularly for URL
+reversing.
+
+Perhaps I am missing several things ;^)
+
+Thomas
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/000017.html b/_build/static/archives/extend/2012-November/000017.html new file mode 100644 index 00000000..f9c420d1 --- /dev/null +++ b/_build/static/archives/extend/2012-November/000017.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Proposal for Cowboy Routing + + + + + + + + + + +

[99s-extend] Proposal for Cowboy Routing

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Nov 29 11:46:10 CET 2012 +

+
+ +
On 11/13/2012 10:04 AM, Loïc Hoguin wrote:
+> Hello!
+>
+> I have put my thoughts on routing at the following gist:
+>
+>    https://gist.github.com/4064759
+>
+> Please comment or cry in terror if you're against it!
+
+I have added more infos and changes as you can see in the comments here: 
+https://gist.github.com/4064759#comments Please feedback.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-November/author.html b/_build/static/archives/extend/2012-November/author.html new file mode 100644 index 00000000..67657d1c --- /dev/null +++ b/_build/static/archives/extend/2012-November/author.html @@ -0,0 +1,102 @@ + + + + The Extend November 2012 Archive by author + + + + + +

November 2012 Archives by author

+ +

Starting: Tue Nov 13 10:04:17 CET 2012
+ Ending: Thu Nov 29 11:46:10 CET 2012
+ Messages: 11

+

+

+ Last message date: + Thu Nov 29 11:46:10 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-November/date.html b/_build/static/archives/extend/2012-November/date.html new file mode 100644 index 00000000..07dc5d70 --- /dev/null +++ b/_build/static/archives/extend/2012-November/date.html @@ -0,0 +1,102 @@ + + + + The Extend November 2012 Archive by date + + + + + +

November 2012 Archives by date

+ +

Starting: Tue Nov 13 10:04:17 CET 2012
+ Ending: Thu Nov 29 11:46:10 CET 2012
+ Messages: 11

+

+

+ Last message date: + Thu Nov 29 11:46:10 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-November/index.html b/_build/static/archives/extend/2012-November/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2012-November/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2012-November/subject.html b/_build/static/archives/extend/2012-November/subject.html new file mode 100644 index 00000000..0f7a6665 --- /dev/null +++ b/_build/static/archives/extend/2012-November/subject.html @@ -0,0 +1,102 @@ + + + + The Extend November 2012 Archive by subject + + + + + +

November 2012 Archives by subject

+ +

Starting: Tue Nov 13 10:04:17 CET 2012
+ Ending: Thu Nov 29 11:46:10 CET 2012
+ Messages: 11

+

+

+ Last message date: + Thu Nov 29 11:46:10 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-November/thread.html b/_build/static/archives/extend/2012-November/thread.html new file mode 100644 index 00000000..3baf49e7 --- /dev/null +++ b/_build/static/archives/extend/2012-November/thread.html @@ -0,0 +1,121 @@ + + + + The Extend November 2012 Archive by thread + + + + + +

November 2012 Archives by thread

+ +

Starting: Tue Nov 13 10:04:17 CET 2012
+ Ending: Thu Nov 29 11:46:10 CET 2012
+ Messages: 11

+

+

+ Last message date: + Thu Nov 29 11:46:10 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-October.txt b/_build/static/archives/extend/2012-October.txt new file mode 100644 index 00000000..f264c905 --- /dev/null +++ b/_build/static/archives/extend/2012-October.txt @@ -0,0 +1,195 @@ +From essen at ninenines.eu Wed Oct 17 12:16:51 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 17 Oct 2012 12:16:51 +0200 +Subject: [99s-extend] Welcome! +Message-ID: <507E8593.8020404@ninenines.eu> + +Hello everyone and welcome to the only mailing list dedicated to the +Nine Nines projects including Cowboy, Ranch, Bullet, Sheriff, Farwest +and more! + +Feel free to ask any question or request support from the community +directly on this mailing list and we will try to help you as quickly as +possible. + +Mailing lists for French and Japanese speakers will be created at a +later date. + +Thanks for subscribing! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Wed Oct 17 13:51:55 2012 +From: thomas at oinksoft.com (Thomas Allen) +Date: Wed, 17 Oct 2012 07:51:55 -0400 +Subject: [99s-extend] Welcome! +In-Reply-To: <507E8593.8020404@ninenines.eu> +References: <507E8593.8020404@ninenines.eu> +Message-ID: <4bcaad4d34881502b48a91fcb1384de4.squirrel@oinksoft.com> + +Very exciting! Now there's no excuse for asking about Cowboy on the +`erlang-questions' list ;^) + +Thomas Allen + + +On Wed, October 17, 2012 6:16 am, Lo?c Hoguin wrote: +> Hello everyone and welcome to the only mailing list dedicated to the +> Nine Nines projects including Cowboy, Ranch, Bullet, Sheriff, Farwest +> and more! +> +> Feel free to ask any question or request support from the community +> directly on this mailing list and we will try to help you as quickly as +> possible. +> +> Mailing lists for French and Japanese speakers will be created at a +> later date. +> +> Thanks for subscribing! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + + + +From zabrane3 at gmail.com Tue Oct 30 21:34:35 2012 +From: zabrane3 at gmail.com (Zabrane Mickael) +Date: Tue, 30 Oct 2012 21:34:35 +0100 +Subject: [99s-extend] Congrats for the new mailinglist +Message-ID: <8C60E8B8-8A20-4553-BCC7-9735C46446B5@gmail.com> + +Bravo Lo?c, + +Regards, +Zabrane + + + +From essen at ninenines.eu Tue Oct 30 21:37:07 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 30 Oct 2012 21:37:07 +0100 +Subject: [99s-extend] Congrats for the new mailinglist +In-Reply-To: <8C60E8B8-8A20-4553-BCC7-9735C46446B5@gmail.com> +References: <8C60E8B8-8A20-4553-BCC7-9735C46446B5@gmail.com> +Message-ID: <50903A73.1060809@ninenines.eu> + +On 10/30/2012 09:34 PM, Zabrane Mickael wrote: +> Bravo Lo?c, + +Thanks. + +I feel obligated to tell you I started calling you the "congrats guy" +since you congratulate every progress everywhere. :) + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From zabrane3 at gmail.com Tue Oct 30 21:40:27 2012 +From: zabrane3 at gmail.com (Zabrane Mickael) +Date: Tue, 30 Oct 2012 21:40:27 +0100 +Subject: [99s-extend] Congrats for the new mailinglist +In-Reply-To: <50903A73.1060809@ninenines.eu> +References: <8C60E8B8-8A20-4553-BCC7-9735C46446B5@gmail.com> + <50903A73.1060809@ninenines.eu> +Message-ID: + +> I feel obligated to tell you I started calling you the "congrats guy" since you congratulate every progress everywhere. :) + +well, you're right ;-) + +Regards, +Zabrane + + + +From erlang at rambocoder.com Wed Oct 31 00:38:40 2012 +From: erlang at rambocoder.com (rambocoder) +Date: Tue, 30 Oct 2012 19:38:40 -0400 +Subject: [99s-extend] cowboy_http_handler type spec +Message-ID: + +Hi everyone, newb questions here: + +Is the reason why the type specification for the init callback lists +various "{loop,..." tuples, because a single module can implement +cowboy_loop_handler and cowboy_http_handler? +And this way, a dializier warning will not be triggered? +https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39 + +Because looking at the handler code, +https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473 if +the {loop, * is returned from init, then the handle(Req, State) will not be +processed. + +Also, is it safe to say that Handler:init is like "before" in lot's of web +frameworks. I can place validation\authentication logic there. + +Sincerely, + +-rambocoder +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 31 00:43:06 2012 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 31 Oct 2012 00:43:06 +0100 +Subject: [99s-extend] cowboy_http_handler type spec +In-Reply-To: +References: +Message-ID: <5090660A.2000301@ninenines.eu> + +On 10/31/2012 12:38 AM, rambocoder wrote: +> Hi everyone, newb questions here: +> +> Is the reason why the type specification for the init callback lists +> various "{loop,..." tuples, because a single module can implement +> cowboy_loop_handler and cowboy_http_handler? +> And this way, a dializier warning will not be triggered? +> https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39 + +Yes that's exactly why. Not the best solution but good enough. + +> Because looking at the handler code, +> https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473 if +> the {loop, * is returned from init, then the handle(Req,State) will not +> be processed. + +You have this one if you just want loops: + +https://github.com/extend/cowboy/blob/master/src/cowboy_loop_handler.erl + +Having an identical init in both allows us to use the 2 handlers without +Dialyzer complaining. + +> Also, is it safe to say that Handler:init is like "before" in lot's of +> web frameworks. I can place validation\authentication logic there. + +Definitely, prepare what you need in init, do what you need to do in +handle and clean up in terminate if needed. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2012-October/000000.html b/_build/static/archives/extend/2012-October/000000.html new file mode 100644 index 00000000..35b502a0 --- /dev/null +++ b/_build/static/archives/extend/2012-October/000000.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Welcome! + + + + + + + + + + +

[99s-extend] Welcome!

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 17 12:16:51 CEST 2012 +

+
+ +
Hello everyone and welcome to the only mailing list dedicated to the 
+Nine Nines projects including Cowboy, Ranch, Bullet, Sheriff, Farwest 
+and more!
+
+Feel free to ask any question or request support from the community 
+directly on this mailing list and we will try to help you as quickly as 
+possible.
+
+Mailing lists for French and Japanese speakers will be created at a 
+later date.
+
+Thanks for subscribing!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000001.html b/_build/static/archives/extend/2012-October/000001.html new file mode 100644 index 00000000..edbfcdad --- /dev/null +++ b/_build/static/archives/extend/2012-October/000001.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Welcome! + + + + + + + + + + +

[99s-extend] Welcome!

+ Thomas Allen + thomas at oinksoft.com +
+ Wed Oct 17 13:51:55 CEST 2012 +

+
+ +
Very exciting! Now there's no excuse for asking about Cowboy on the
+`erlang-questions' list ;^)
+
+Thomas Allen
+
+
+On Wed, October 17, 2012 6:16 am, Loïc Hoguin wrote:
+> Hello everyone and welcome to the only mailing list dedicated to the
+> Nine Nines projects including Cowboy, Ranch, Bullet, Sheriff, Farwest
+> and more!
+>
+> Feel free to ask any question or request support from the community
+> directly on this mailing list and we will try to help you as quickly as
+> possible.
+>
+> Mailing lists for French and Japanese speakers will be created at a
+> later date.
+>
+> Thanks for subscribing!
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000002.html b/_build/static/archives/extend/2012-October/000002.html new file mode 100644 index 00000000..d40005ce --- /dev/null +++ b/_build/static/archives/extend/2012-October/000002.html @@ -0,0 +1,66 @@ + + + + [99s-extend] Congrats for the new mailinglist + + + + + + + + + + +

[99s-extend] Congrats for the new mailinglist

+ Zabrane Mickael + zabrane3 at gmail.com +
+ Tue Oct 30 21:34:35 CET 2012 +

+
+ +
Bravo Loïc,
+
+Regards,
+Zabrane
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000003.html b/_build/static/archives/extend/2012-October/000003.html new file mode 100644 index 00000000..8cd8e899 --- /dev/null +++ b/_build/static/archives/extend/2012-October/000003.html @@ -0,0 +1,74 @@ + + + + [99s-extend] Congrats for the new mailinglist + + + + + + + + + + +

[99s-extend] Congrats for the new mailinglist

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Oct 30 21:37:07 CET 2012 +

+
+ +
On 10/30/2012 09:34 PM, Zabrane Mickael wrote:
+> Bravo Loïc,
+
+Thanks.
+
+I feel obligated to tell you I started calling you the "congrats guy" 
+since you congratulate every progress everywhere. :)
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000004.html b/_build/static/archives/extend/2012-October/000004.html new file mode 100644 index 00000000..c2b86626 --- /dev/null +++ b/_build/static/archives/extend/2012-October/000004.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Congrats for the new mailinglist + + + + + + + + + + +

[99s-extend] Congrats for the new mailinglist

+ Zabrane Mickael + zabrane3 at gmail.com +
+ Tue Oct 30 21:40:27 CET 2012 +

+
+ +
> I feel obligated to tell you I started calling you the "congrats guy" since you congratulate every progress everywhere. :)
+
+well, you're right ;-)
+
+Regards,
+Zabrane
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000005.html b/_build/static/archives/extend/2012-October/000005.html new file mode 100644 index 00000000..4909d0f2 --- /dev/null +++ b/_build/static/archives/extend/2012-October/000005.html @@ -0,0 +1,82 @@ + + + + [99s-extend] cowboy_http_handler type spec + + + + + + + + + + +

[99s-extend] cowboy_http_handler type spec

+ rambocoder + erlang at rambocoder.com +
+ Wed Oct 31 00:38:40 CET 2012 +

+
+ +
Hi everyone, newb questions here:
+
+Is the reason why the type specification for the init callback lists
+various "{loop,..." tuples, because a single module can implement
+cowboy_loop_handler and cowboy_http_handler?
+And this way, a dializier warning will not be triggered?
+https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39
+
+Because looking at the handler code,
+https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473 if
+the {loop, * is returned from init, then the handle(Req, State) will not be
+processed.
+
+Also, is it safe to say that Handler:init is like "before" in lot's of web
+frameworks. I can place validation\authentication logic there.
+
+Sincerely,
+
+-rambocoder
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20121030/3de26c28/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/000006.html b/_build/static/archives/extend/2012-October/000006.html new file mode 100644 index 00000000..2e8610ec --- /dev/null +++ b/_build/static/archives/extend/2012-October/000006.html @@ -0,0 +1,93 @@ + + + + [99s-extend] cowboy_http_handler type spec + + + + + + + + + + +

[99s-extend] cowboy_http_handler type spec

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 31 00:43:06 CET 2012 +

+
+ +
On 10/31/2012 12:38 AM, rambocoder wrote:
+> Hi everyone, newb questions here:
+>
+> Is the reason why the type specification for the init callback lists
+> various "{loop,..." tuples, because a single module can implement
+> cowboy_loop_handler and cowboy_http_handler?
+> And this way, a dializier warning will not be triggered?
+> https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39
+
+Yes that's exactly why. Not the best solution but good enough.
+
+> Because looking at the handler code,
+> https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473 if
+> the {loop, * is returned from init, then the handle(Req,State) will not
+> be processed.
+
+You have this one if you just want loops:
+
+https://github.com/extend/cowboy/blob/master/src/cowboy_loop_handler.erl
+
+Having an identical init in both allows us to use the 2 handlers without 
+Dialyzer complaining.
+
+> Also, is it safe to say that Handler:init is like "before" in lot's of
+> web frameworks. I can place validation\authentication logic there.
+
+Definitely, prepare what you need in init, do what you need to do in 
+handle and clean up in terminate if needed.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2012-October/author.html b/_build/static/archives/extend/2012-October/author.html new file mode 100644 index 00000000..0a2894ea --- /dev/null +++ b/_build/static/archives/extend/2012-October/author.html @@ -0,0 +1,82 @@ + + + + The Extend October 2012 Archive by author + + + + + +

October 2012 Archives by author

+ +

Starting: Wed Oct 17 12:16:51 CEST 2012
+ Ending: Wed Oct 31 00:43:06 CET 2012
+ Messages: 7

+

+

+ Last message date: + Wed Oct 31 00:43:06 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-October/date.html b/_build/static/archives/extend/2012-October/date.html new file mode 100644 index 00000000..70ea0f0d --- /dev/null +++ b/_build/static/archives/extend/2012-October/date.html @@ -0,0 +1,82 @@ + + + + The Extend October 2012 Archive by date + + + + + +

October 2012 Archives by date

+ +

Starting: Wed Oct 17 12:16:51 CEST 2012
+ Ending: Wed Oct 31 00:43:06 CET 2012
+ Messages: 7

+

+

+ Last message date: + Wed Oct 31 00:43:06 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-October/index.html b/_build/static/archives/extend/2012-October/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2012-October/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2012-October/subject.html b/_build/static/archives/extend/2012-October/subject.html new file mode 100644 index 00000000..1eecfaed --- /dev/null +++ b/_build/static/archives/extend/2012-October/subject.html @@ -0,0 +1,82 @@ + + + + The Extend October 2012 Archive by subject + + + + + +

October 2012 Archives by subject

+ +

Starting: Wed Oct 17 12:16:51 CEST 2012
+ Ending: Wed Oct 31 00:43:06 CET 2012
+ Messages: 7

+

+

+ Last message date: + Wed Oct 31 00:43:06 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2012-October/thread.html b/_build/static/archives/extend/2012-October/thread.html new file mode 100644 index 00000000..e89fa1be --- /dev/null +++ b/_build/static/archives/extend/2012-October/thread.html @@ -0,0 +1,97 @@ + + + + The Extend October 2012 Archive by thread + + + + + +

October 2012 Archives by thread

+ +

Starting: Wed Oct 17 12:16:51 CEST 2012
+ Ending: Wed Oct 31 00:43:06 CET 2012
+ Messages: 7

+

+

+ Last message date: + Wed Oct 31 00:43:06 CET 2012
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-April.txt b/_build/static/archives/extend/2013-April.txt new file mode 100644 index 00000000..b988707c --- /dev/null +++ b/_build/static/archives/extend/2013-April.txt @@ -0,0 +1,3953 @@ +From essen at ninenines.eu Tue Apr 2 19:23:28 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 02 Apr 2013 19:23:28 +0200 +Subject: [99s-extend] [ANN] Ranch 0.8.0 +Message-ID: <515B1410.6080905@ninenines.eu> + +Just released! + +We have greatly improved the performance of Ranch both for accepting +connections and when they get disconnected. Stability has also been much +improved thanks to many community provided tests. + +Small API changes. Sorry! + + * ListenerPid argument to Protocol:start_link/4 became Ref + * as a result it's now ranch:accept_ack(Ref) + * ranch_listener:remove_connection(ListenerPid) became +ranch:remove_connection(Ref) + +Unless you used ranch_listener_remove_connection/1 your old code should +still work without any changes. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Wed Apr 3 17:21:16 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 03 Apr 2013 17:21:16 +0200 +Subject: [99s-extend] [ANN] Cowboy 0.8.3 +Message-ID: <515C48EC.7040403@ninenines.eu> + +Hello! + +Very small release just to update Ranch to 0.8.0 (faster!) and change +something about streaming the body. Newly introduced init_stream/5 +proved to be a bad idea and got removed in favor of a new stream_body/2 +which allows specifying the maximum chunk size you want on a per chunk +basis. + + https://github.com/extend/cowboy + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Wed Apr 3 21:33:20 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 3 Apr 2013 20:33:20 +0100 +Subject: [99s-extend] Response headers +Message-ID: + +Hi list, + +I'd like to set up my handler to use CORS. Can anyone tell me how I can modify the headers for my handler to support this? + +Thanks loads, +Lee + +From Christopher.Phillips at turner.com Wed Apr 3 22:35:36 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Wed, 3 Apr 2013 20:35:36 +0000 +Subject: [99s-extend] Response headers +In-Reply-To: +Message-ID: + + + Sure. Right now, Cowboy doesn't parse the headers, but you can manually +parse them in your handler. I've got them working in my implementation +pretty well, I'll try and break it down a bit here. + + A good, basic overview of what the requests the browser will send, and +what your responses should look like, is here: +https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS + + + +HANDLING PRE-FLIGHTS - + Pre-flights are the OPTION requests the browser automatically sends off +when you make a CORS request using a verb other than GET, or POST with one +of three acceptable content types. They're defined well in the above link. + + You can read off the requested headers the actual call wants to send in +the OPTIONS preflight with + + {Headers, NewRequest } = +cowboy_req:header(<<"access-control-request-headers">>, Request) + + Headers will either be the binary, or undefined. If the binary, you +either need to manually parse it and choose to allow/disallow the request +from continuing based on it, or, if you just want to allow all headers +trivially, just pipe that back into the request, a la - + + Request2 = +cowboy_req:set_resp_header(<<"access-control-allow-headers">>, +binary_to_list(Headers), NewRequest) + + (As a reminder, it can be undefined. You'll need to check for that +before passing it into the above. If it's undefined, you don't need to add +the access-control-allow-headers header). + + + + As part of the pre-flight request, you also need to handle what methods +are allowed. This looks something like - + + PreflightedRequest = +cowboy_req:set_resp_header(<<"access-control-allow-methods">>, <<"GET, +POST, DELETE, PUT">>, Request2) + + If I wanted to allow gets, posts, deletes, and puts. You can also choose +to read off the access-control-request-method header sent from the client, +but I don't see the point; your list of allowed methods doesn't need to +change based on that (the user is requesting a POST, why does that change +whether you allow a POST or not? But I digress). + + + + + +FOR ALL CALLS (both pre-flights and the actual call) + Respond with acceptable origin. If you want any domain to access this +resource (not advised, unless this is a public, readonly resource, but +good for testing), you can do - + + NewRequest = +cowboy_req:set_resp_header(<<"access-control-allow-origin">>, <<"*">>, +Request) + + + If you want to filter out the allowed domains, it looks like - + + Origin = cowboy_req:header(<<"origin">>, Request) %Get the origin that +the browser sent you + + %Do logic to check Origin, and any other data that would decide +whether this request is allowed; it will only apply on a CORS request from +another browser. + + %If it passes, pass Origin back as the value for the +access-control-allow-origin header. + NewRequest = +cowboy_req:set_resp_header(<<"access-control-allow-origin">>, Origin, +Request) + + + +FOR ONLY THE ACTUAL CALL + If you want to send custom headers back to your Javascript client (or +read any standard header beyond content-type), you need to explicitly +allow them. This looks like (if I wanted to expose the 'server' header so +my client Javascript can see that it's Cowboy on the backend) - + + ExposedHeaderRequest = +cowboy_req:set_resp_header(<<"access-control-expose-headers">>, +<<"server">>, Request) + + + + + That's basically it I believe. There is also a max age, and a allow +credentials header (which is really more of a require credentials); +they're pretty straightforwardly explained on that page I linked above, +but I haven't played with them personally. + + + Caveats I ran into were largely being aware that same domain requests do +NOT supply any of the CORS headers, not even the origin header (so you can +get undefined and have to handle those cases), as well as understanding +the ramifications of allowing cross domain requests. Also, if you want to +develop while disconnected (or if it's not easy to grab another domain), +use your hosts file to declare a fake domain pointed to 127.0.0.1, load +your page from that, explicitly define your AJAX calls to localhost. Note +too that there is a bug in Firefox at present when you try and get all the +request headers. It returns an empty list. You can get individual ones if +you know the name (I.e., getResponseHeader("server") will work, +getAllResponseHeaders() returns an empty string). This is further +compounded by jQuery building its own XHR that loads headers by calling +getAllResponseHeaders, so in Firefox, using jQuery, you can get back zero +headers. Don't know if that affects you, but it's an issue it took me a +good while to diagnose, and which we've had to bear in mind. + + + + +On 4/3/13 3:33 PM, "Lee Sylvester" wrote: + +>Hi list, +> +>I'd like to set up my handler to use CORS. Can anyone tell me how I can +>modify the headers for my handler to support this? +> +>Thanks loads, +>Lee +>_______________________________________________ +>Extend mailing list +>Extend at lists.ninenines.eu +>http://lists.ninenines.eu:81/listinfo/extend +> + + + + +From lee.sylvester at gmail.com Thu Apr 4 10:38:07 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 4 Apr 2013 09:38:07 +0100 +Subject: [99s-extend] Response headers +In-Reply-To: +References: +Message-ID: <3E75C3ED-9F52-495A-8E04-EF0A4667DB4E@gmail.com> + +Hi Christopher, + +Thank you for that. I will attempt to go through each piece today and solve the problem. This is good advice; maybe it belongs in a blog post? :-) + +Thanks again, +Lee + + + + +On 3 Apr 2013, at 21:35, "Phillips, Christopher" wrote: + +> +> Sure. Right now, Cowboy doesn't parse the headers, but you can manually +> parse them in your handler. I've got them working in my implementation +> pretty well, I'll try and break it down a bit here. +> +> A good, basic overview of what the requests the browser will send, and +> what your responses should look like, is here: +> https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS +> +> +> +> HANDLING PRE-FLIGHTS - +> Pre-flights are the OPTION requests the browser automatically sends off +> when you make a CORS request using a verb other than GET, or POST with one +> of three acceptable content types. They're defined well in the above link. +> +> You can read off the requested headers the actual call wants to send in +> the OPTIONS preflight with +> +> {Headers, NewRequest } = +> cowboy_req:header(<<"access-control-request-headers">>, Request) +> +> Headers will either be the binary, or undefined. If the binary, you +> either need to manually parse it and choose to allow/disallow the request +> from continuing based on it, or, if you just want to allow all headers +> trivially, just pipe that back into the request, a la - +> +> Request2 = +> cowboy_req:set_resp_header(<<"access-control-allow-headers">>, +> binary_to_list(Headers), NewRequest) +> +> (As a reminder, it can be undefined. You'll need to check for that +> before passing it into the above. If it's undefined, you don't need to add +> the access-control-allow-headers header). +> +> +> +> As part of the pre-flight request, you also need to handle what methods +> are allowed. This looks something like - +> +> PreflightedRequest = +> cowboy_req:set_resp_header(<<"access-control-allow-methods">>, <<"GET, +> POST, DELETE, PUT">>, Request2) +> +> If I wanted to allow gets, posts, deletes, and puts. You can also choose +> to read off the access-control-request-method header sent from the client, +> but I don't see the point; your list of allowed methods doesn't need to +> change based on that (the user is requesting a POST, why does that change +> whether you allow a POST or not? But I digress). +> +> +> +> +> +> FOR ALL CALLS (both pre-flights and the actual call) +> Respond with acceptable origin. If you want any domain to access this +> resource (not advised, unless this is a public, readonly resource, but +> good for testing), you can do - +> +> NewRequest = +> cowboy_req:set_resp_header(<<"access-control-allow-origin">>, <<"*">>, +> Request) +> +> +> If you want to filter out the allowed domains, it looks like - +> +> Origin = cowboy_req:header(<<"origin">>, Request) %Get the origin that +> the browser sent you +> +> %Do logic to check Origin, and any other data that would decide +> whether this request is allowed; it will only apply on a CORS request from +> another browser. +> +> %If it passes, pass Origin back as the value for the +> access-control-allow-origin header. +> NewRequest = +> cowboy_req:set_resp_header(<<"access-control-allow-origin">>, Origin, +> Request) +> +> +> +> FOR ONLY THE ACTUAL CALL +> If you want to send custom headers back to your Javascript client (or +> read any standard header beyond content-type), you need to explicitly +> allow them. This looks like (if I wanted to expose the 'server' header so +> my client Javascript can see that it's Cowboy on the backend) - +> +> ExposedHeaderRequest = +> cowboy_req:set_resp_header(<<"access-control-expose-headers">>, +> <<"server">>, Request) +> +> +> +> +> That's basically it I believe. There is also a max age, and a allow +> credentials header (which is really more of a require credentials); +> they're pretty straightforwardly explained on that page I linked above, +> but I haven't played with them personally. +> +> +> Caveats I ran into were largely being aware that same domain requests do +> NOT supply any of the CORS headers, not even the origin header (so you can +> get undefined and have to handle those cases), as well as understanding +> the ramifications of allowing cross domain requests. Also, if you want to +> develop while disconnected (or if it's not easy to grab another domain), +> use your hosts file to declare a fake domain pointed to 127.0.0.1, load +> your page from that, explicitly define your AJAX calls to localhost. Note +> too that there is a bug in Firefox at present when you try and get all the +> request headers. It returns an empty list. You can get individual ones if +> you know the name (I.e., getResponseHeader("server") will work, +> getAllResponseHeaders() returns an empty string). This is further +> compounded by jQuery building its own XHR that loads headers by calling +> getAllResponseHeaders, so in Firefox, using jQuery, you can get back zero +> headers. Don't know if that affects you, but it's an issue it took me a +> good while to diagnose, and which we've had to bear in mind. +> +> +> +> +> On 4/3/13 3:33 PM, "Lee Sylvester" wrote: +> +>> Hi list, +>> +>> I'd like to set up my handler to use CORS. Can anyone tell me how I can +>> modify the headers for my handler to support this? +>> +>> Thanks loads, +>> Lee +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From lee.sylvester at gmail.com Thu Apr 4 22:17:54 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 4 Apr 2013 21:17:54 +0100 +Subject: [99s-extend] Bullet connection +Message-ID: <33516651-FC93-49EA-A8CA-B5C3E42B03E5@gmail.com> + +Hi guys, + +So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT. The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations". + +Does anyone know how I fix this to get past this problem? + +Thanks, +Lee + +From essen at ninenines.eu Thu Apr 4 22:39:32 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 04 Apr 2013 22:39:32 +0200 +Subject: [99s-extend] Bullet connection +In-Reply-To: <33516651-FC93-49EA-A8CA-B5C3E42B03E5@gmail.com> +References: <33516651-FC93-49EA-A8CA-B5C3E42B03E5@gmail.com> +Message-ID: <515DE504.5060007@ninenines.eu> + +On 04/04/2013 10:17 PM, Lee Sylvester wrote: +> Hi guys, +> +> So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT. The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations". +> +> Does anyone know how I fix this to get past this problem? + +You should probably disable the proxy you have configured in your +browser for the domain localhost. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Thu Apr 4 22:54:54 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 4 Apr 2013 21:54:54 +0100 +Subject: [99s-extend] Bullet connection +In-Reply-To: <515DE504.5060007@ninenines.eu> +References: <33516651-FC93-49EA-A8CA-B5C3E42B03E5@gmail.com> + <515DE504.5060007@ninenines.eu> +Message-ID: <52A2CDB5-3C4D-4E20-ACDF-011A44E0FD8B@gmail.com> + +D'oh! I'm obviously tired :( Thanks for that. I saw the message and instantly assumed it was a Cowboy related error. Okay, so I got that fixed. Now I need to work out why my connections close the instant they're open :-D Oh, the life of a developer! + +Thanks again. + +Lee + + + + +On 4 Apr 2013, at 21:39, Lo?c Hoguin wrote: + +> On 04/04/2013 10:17 PM, Lee Sylvester wrote: +>> Hi guys, +>> +>> So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT. The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations". +>> +>> Does anyone know how I fix this to get past this problem? +> +> You should probably disable the proxy you have configured in your browser for the domain localhost. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From lee.sylvester at gmail.com Mon Apr 8 15:53:38 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Mon, 8 Apr 2013 14:53:38 +0100 +Subject: [99s-extend] Problems with Bullet +Message-ID: + +Hi all, + +I'm currently having problems getting a websocket to connect to a simple bare bones Bullet handler. Unfortunately, I'm still quite an Erlang noob, so the stack traces tend to lead me in circles. I'm hoping this is obvious stuff to you Erlang pros :-) + +Given the below handler: + +init(_Transport, Req, _Opts, _Active) -> + {ok, Req, undefined_state}. + +stream(Data, Req, State) -> + {ok, Req, State}. + +info(Info, Req, State) -> + {reply, Info, Req, State}. + +terminate(_Req, _State) -> + ok. + +Connecting with a websocket throws the following error: + +=ERROR REPORT==== 8-Apr-2013::14:46:11 === +** Cowboy handler bullet_handler terminating in init/3 + for the reason error:undef +** Options were [{handler,connection_handler}] +** Request was [{socket,#Port<0.926>}, + {transport,ranch_tcp}, + {connection,keepalive}, + {pid,<0.491.0>}, + {method,<<"GET">>}, + {version,{1,1}}, + {peer,{{127,0,0,1},56630}}, + {host,<<"localhost">>}, + {host_info,undefined}, + {port,8080}, + {path,<<"/">>}, + {path_info,undefined}, + {qs,<<"encoding=text">>}, + {qs_vals,undefined}, + {fragment,<<>>}, + {bindings,[]}, + {headers,[{<<"upgrade">>,<<"websocket">>}, + {<<"connection">>,<<"Upgrade">>}, + {<<"host">>,<<"localhost:8080">>}, + {<<"origin">>,<<"http://www.websocket.org">>}, + {<<"pragma">>,<<"no-cache">>}, + {<<"cache-control">>,<<"no-cache">>}, + {<<"sec-websocket-key">>, + <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, + {<<"sec-websocket-version">>,<<"13">>}, + {<<"sec-websocket-extensions">>, + <<"x-webkit-deflate-frame">>}]}, + {p_headers,[{<<"connection">>,[<<"upgrade">>]}]}, + {cookies,undefined}, + {meta,[]}, + {body_state,waiting}, + {multipart,undefined}, + {buffer,<<>>}, + {resp_compress,false}, + {resp_state,waiting}, + {resp_headers,[]}, + {resp_body,<<>>}, + {onresponse,undefined}] +** Stacktrace: [{bullet_handler,init, + [{tcp,http}, + {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>, + <<"GET">>, + {1,1}, + {{127,0,0,1},56630}, + <<"localhost">>,undefined,8080,<<"/">>, + undefined,<<"encoding=text">>,undefined,<<>>, + [], + [{<<"upgrade">>,<<"websocket">>}, + {<<"connection">>,<<"Upgrade">>}, + {<<"host">>,<<"localhost:8080">>}, + {<<"origin">>,<<"http://www.websocket.org">>}, + {<<"pragma">>,<<"no-cache">>}, + {<<"cache-control">>,<<"no-cache">>}, + {<<"sec-websocket-key">>, + <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, + {<<"sec-websocket-version">>,<<"13">>}, + {<<"sec-websocket-extensions">>, + <<"x-webkit-deflate-frame">>}], + [{<<"connection">>,[<<"upgrade">>]}], + undefined,[],waiting,undefined,<<>>,false,waiting,[], + <<>>,undefined}, + [{handler,connection_handler}]], + []}, + {cowboy_handler,handler_init,4, + [{file,"src/cowboy_handler.erl"},{line,69}]}, + {cowboy_protocol,execute,4, + [{file,"src/cowboy_protocol.erl"},{line,514}]}] + +Can anyone see what might be throwing this off? I'd like to get a minimal handler running before I attempt to add some logic. + +Thanks, +Lee + +From essen at ninenines.eu Mon Apr 8 16:08:31 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 08 Apr 2013 16:08:31 +0200 +Subject: [99s-extend] Problems with Bullet +In-Reply-To: +References: +Message-ID: <5162CF5F.2060200@ninenines.eu> + +Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin? + +On 04/08/2013 03:53 PM, Lee Sylvester wrote: +> Hi all, +> +> I'm currently having problems getting a websocket to connect to a simple bare bones Bullet handler. Unfortunately, I'm still quite an Erlang noob, so the stack traces tend to lead me in circles. I'm hoping this is obvious stuff to you Erlang pros :-) +> +> Given the below handler: +> +> init(_Transport, Req, _Opts, _Active) -> +> {ok, Req, undefined_state}. +> +> stream(Data, Req, State) -> +> {ok, Req, State}. +> +> info(Info, Req, State) -> +> {reply, Info, Req, State}. +> +> terminate(_Req, _State) -> +> ok. +> +> Connecting with a websocket throws the following error: +> +> =ERROR REPORT==== 8-Apr-2013::14:46:11 === +> ** Cowboy handler bullet_handler terminating in init/3 +> for the reason error:undef +> ** Options were [{handler,connection_handler}] +> ** Request was [{socket,#Port<0.926>}, +> {transport,ranch_tcp}, +> {connection,keepalive}, +> {pid,<0.491.0>}, +> {method,<<"GET">>}, +> {version,{1,1}}, +> {peer,{{127,0,0,1},56630}}, +> {host,<<"localhost">>}, +> {host_info,undefined}, +> {port,8080}, +> {path,<<"/">>}, +> {path_info,undefined}, +> {qs,<<"encoding=text">>}, +> {qs_vals,undefined}, +> {fragment,<<>>}, +> {bindings,[]}, +> {headers,[{<<"upgrade">>,<<"websocket">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"host">>,<<"localhost:8080">>}, +> {<<"origin">>,<<"http://www.websocket.org">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"sec-websocket-key">>, +> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"sec-websocket-extensions">>, +> <<"x-webkit-deflate-frame">>}]}, +> {p_headers,[{<<"connection">>,[<<"upgrade">>]}]}, +> {cookies,undefined}, +> {meta,[]}, +> {body_state,waiting}, +> {multipart,undefined}, +> {buffer,<<>>}, +> {resp_compress,false}, +> {resp_state,waiting}, +> {resp_headers,[]}, +> {resp_body,<<>>}, +> {onresponse,undefined}] +> ** Stacktrace: [{bullet_handler,init, +> [{tcp,http}, +> {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>, +> <<"GET">>, +> {1,1}, +> {{127,0,0,1},56630}, +> <<"localhost">>,undefined,8080,<<"/">>, +> undefined,<<"encoding=text">>,undefined,<<>>, +> [], +> [{<<"upgrade">>,<<"websocket">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"host">>,<<"localhost:8080">>}, +> {<<"origin">>,<<"http://www.websocket.org">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"sec-websocket-key">>, +> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"sec-websocket-extensions">>, +> <<"x-webkit-deflate-frame">>}], +> [{<<"connection">>,[<<"upgrade">>]}], +> undefined,[],waiting,undefined,<<>>,false,waiting,[], +> <<>>,undefined}, +> [{handler,connection_handler}]], +> []}, +> {cowboy_handler,handler_init,4, +> [{file,"src/cowboy_handler.erl"},{line,69}]}, +> {cowboy_protocol,execute,4, +> [{file,"src/cowboy_protocol.erl"},{line,514}]}] +> +> Can anyone see what might be throwing this off? I'd like to get a minimal handler running before I attempt to add some logic. +> +> Thanks, +> Lee +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Christopher.Phillips at turner.com Mon Apr 8 16:11:44 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Mon, 8 Apr 2013 14:11:44 +0000 +Subject: [99s-extend] Problems with Bullet +In-Reply-To: +Message-ID: + + Can you get the clock example working? I'm not sure why the initial +upgrade request would fail; are you exporting init/4 in your handler? Are +your dependencies consistent (I.e., blow them away and regrab them in case +it's an older version of cowboy with a new version of bullet, or vice +versa, maybe)? Either way, starting from the example would allow you to +start from a set of working code and either avoid the issue entirely, or +isolate it from your code. + +On 4/8/13 9:53 AM, "Lee Sylvester" wrote: + +>Hi all, +> +>I'm currently having problems getting a websocket to connect to a simple +>bare bones Bullet handler. Unfortunately, I'm still quite an Erlang +>noob, so the stack traces tend to lead me in circles. I'm hoping this is +>obvious stuff to you Erlang pros :-) +> +>Given the below handler: +> +>init(_Transport, Req, _Opts, _Active) -> +> {ok, Req, undefined_state}. +> +>stream(Data, Req, State) -> +> {ok, Req, State}. +> +>info(Info, Req, State) -> +> {reply, Info, Req, State}. +> +>terminate(_Req, _State) -> +> ok. +> +>Connecting with a websocket throws the following error: +> +>=ERROR REPORT==== 8-Apr-2013::14:46:11 === +>** Cowboy handler bullet_handler terminating in init/3 +> for the reason error:undef +>** Options were [{handler,connection_handler}] +>** Request was [{socket,#Port<0.926>}, +> {transport,ranch_tcp}, +> {connection,keepalive}, +> {pid,<0.491.0>}, +> {method,<<"GET">>}, +> {version,{1,1}}, +> {peer,{{127,0,0,1},56630}}, +> {host,<<"localhost">>}, +> {host_info,undefined}, +> {port,8080}, +> {path,<<"/">>}, +> {path_info,undefined}, +> {qs,<<"encoding=text">>}, +> {qs_vals,undefined}, +> {fragment,<<>>}, +> {bindings,[]}, +> {headers,[{<<"upgrade">>,<<"websocket">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"host">>,<<"localhost:8080">>}, +> {<<"origin">>,<<"http://www.websocket.org">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"sec-websocket-key">>, +> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"sec-websocket-extensions">>, +> <<"x-webkit-deflate-frame">>}]}, +> {p_headers,[{<<"connection">>,[<<"upgrade">>]}]}, +> {cookies,undefined}, +> {meta,[]}, +> {body_state,waiting}, +> {multipart,undefined}, +> {buffer,<<>>}, +> {resp_compress,false}, +> {resp_state,waiting}, +> {resp_headers,[]}, +> {resp_body,<<>>}, +> {onresponse,undefined}] +>** Stacktrace: [{bullet_handler,init, +> [{tcp,http}, +> {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>, +> <<"GET">>, +> {1,1}, +> {{127,0,0,1},56630}, +> <<"localhost">>,undefined,8080,<<"/">>, +> undefined,<<"encoding=text">>,undefined,<<>>, +> [], +> [{<<"upgrade">>,<<"websocket">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"host">>,<<"localhost:8080">>}, +> {<<"origin">>,<<"http://www.websocket.org">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"sec-websocket-key">>, +> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"sec-websocket-extensions">>, +> <<"x-webkit-deflate-frame">>}], +> [{<<"connection">>,[<<"upgrade">>]}], +> +>undefined,[],waiting,undefined,<<>>,false,waiting,[], +> <<>>,undefined}, +> [{handler,connection_handler}]], +> []}, +> {cowboy_handler,handler_init,4, +> [{file,"src/cowboy_handler.erl"},{line,69}]}, +> {cowboy_protocol,execute,4, +> [{file,"src/cowboy_protocol.erl"},{line,514}]}] +> +>Can anyone see what might be throwing this off? I'd like to get a +>minimal handler running before I attempt to add some logic. +> +>Thanks, +>Lee +>_______________________________________________ +>Extend mailing list +>Extend at lists.ninenines.eu +>http://lists.ninenines.eu:81/listinfo/extend +> + + + + +From Christopher.Phillips at turner.com Mon Apr 8 16:18:27 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Mon, 8 Apr 2013 14:18:27 +0000 +Subject: [99s-extend] Problems with Bullet +In-Reply-To: <5162CF5F.2060200@ninenines.eu> +Message-ID: + + *facepalm* Or that, yeah. Should have correlated the stack trace with +the error. Not used to seeing cowboy run as the app, not a dependency. + +On 4/8/13 10:08 AM, "Lo?c Hoguin" wrote: + +>Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin? +> +>On 04/08/2013 03:53 PM, Lee Sylvester wrote: +>> Hi all, +>> +>> I'm currently having problems getting a websocket to connect to a +>>simple bare bones Bullet handler. Unfortunately, I'm still quite an +>>Erlang noob, so the stack traces tend to lead me in circles. I'm hoping +>>this is obvious stuff to you Erlang pros :-) +>> +>> Given the below handler: +>> +>> init(_Transport, Req, _Opts, _Active) -> +>> {ok, Req, undefined_state}. +>> +>> stream(Data, Req, State) -> +>> {ok, Req, State}. +>> +>> info(Info, Req, State) -> +>> {reply, Info, Req, State}. +>> +>> terminate(_Req, _State) -> +>> ok. +>> +>> Connecting with a websocket throws the following error: +>> +>> =ERROR REPORT==== 8-Apr-2013::14:46:11 === +>> ** Cowboy handler bullet_handler terminating in init/3 +>> for the reason error:undef +>> ** Options were [{handler,connection_handler}] +>> ** Request was [{socket,#Port<0.926>}, +>> {transport,ranch_tcp}, +>> {connection,keepalive}, +>> {pid,<0.491.0>}, +>> {method,<<"GET">>}, +>> {version,{1,1}}, +>> {peer,{{127,0,0,1},56630}}, +>> {host,<<"localhost">>}, +>> {host_info,undefined}, +>> {port,8080}, +>> {path,<<"/">>}, +>> {path_info,undefined}, +>> {qs,<<"encoding=text">>}, +>> {qs_vals,undefined}, +>> {fragment,<<>>}, +>> {bindings,[]}, +>> {headers,[{<<"upgrade">>,<<"websocket">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"host">>,<<"localhost:8080">>}, +>> +>>{<<"origin">>,<<"http://www.websocket.org">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"sec-websocket-key">>, +>> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"x-webkit-deflate-frame">>}]}, +>> {p_headers,[{<<"connection">>,[<<"upgrade">>]}]}, +>> {cookies,undefined}, +>> {meta,[]}, +>> {body_state,waiting}, +>> {multipart,undefined}, +>> {buffer,<<>>}, +>> {resp_compress,false}, +>> {resp_state,waiting}, +>> {resp_headers,[]}, +>> {resp_body,<<>>}, +>> {onresponse,undefined}] +>> ** Stacktrace: [{bullet_handler,init, +>> [{tcp,http}, +>> +>>{http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>, +>> <<"GET">>, +>> {1,1}, +>> {{127,0,0,1},56630}, +>> <<"localhost">>,undefined,8080,<<"/">>, +>> undefined,<<"encoding=text">>,undefined,<<>>, +>> [], +>> [{<<"upgrade">>,<<"websocket">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"host">>,<<"localhost:8080">>}, +>> +>>{<<"origin">>,<<"http://www.websocket.org">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"sec-websocket-key">>, +>> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"x-webkit-deflate-frame">>}], +>> [{<<"connection">>,[<<"upgrade">>]}], +>> +>>undefined,[],waiting,undefined,<<>>,false,waiting,[], +>> <<>>,undefined}, +>> [{handler,connection_handler}]], +>> []}, +>> {cowboy_handler,handler_init,4, +>> [{file,"src/cowboy_handler.erl"},{line,69}]}, +>> {cowboy_protocol,execute,4, +>> [{file,"src/cowboy_protocol.erl"},{line,514}]}] +>> +>> Can anyone see what might be throwing this off? I'd like to get a +>>minimal handler running before I attempt to add some logic. +>> +>> Thanks, +>> Lee +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +>-- +>Lo?c Hoguin +>Erlang Cowboy +>Nine Nines +>http://ninenines.eu +>_______________________________________________ +>Extend mailing list +>Extend at lists.ninenines.eu +>http://lists.ninenines.eu:81/listinfo/extend +> + + + + +From lee.sylvester at gmail.com Mon Apr 8 16:21:53 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Mon, 8 Apr 2013 15:21:53 +0100 +Subject: [99s-extend] Problems with Bullet +In-Reply-To: +References: +Message-ID: + +Thanks guys, that was exactly the problem. I feel a little stupid :-) I use Rebar to compile my apps, but none of the three books I have on Erlang describe the config files in much detail. I probably have my entire setup wrong. + +Anyhow, it looks to be working, now :-) + +Thanks again, +Lee + + + +On 8 Apr 2013, at 15:18, "Phillips, Christopher" wrote: + +> *facepalm* Or that, yeah. Should have correlated the stack trace with +> the error. Not used to seeing cowboy run as the app, not a dependency. +> +> On 4/8/13 10:08 AM, "Lo?c Hoguin" wrote: +> +>> Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin? +>> +>> On 04/08/2013 03:53 PM, Lee Sylvester wrote: +>>> Hi all, +>>> +>>> I'm currently having problems getting a websocket to connect to a +>>> simple bare bones Bullet handler. Unfortunately, I'm still quite an +>>> Erlang noob, so the stack traces tend to lead me in circles. I'm hoping +>>> this is obvious stuff to you Erlang pros :-) +>>> +>>> Given the below handler: +>>> +>>> init(_Transport, Req, _Opts, _Active) -> +>>> {ok, Req, undefined_state}. +>>> +>>> stream(Data, Req, State) -> +>>> {ok, Req, State}. +>>> +>>> info(Info, Req, State) -> +>>> {reply, Info, Req, State}. +>>> +>>> terminate(_Req, _State) -> +>>> ok. +>>> +>>> Connecting with a websocket throws the following error: +>>> +>>> =ERROR REPORT==== 8-Apr-2013::14:46:11 === +>>> ** Cowboy handler bullet_handler terminating in init/3 +>>> for the reason error:undef +>>> ** Options were [{handler,connection_handler}] +>>> ** Request was [{socket,#Port<0.926>}, +>>> {transport,ranch_tcp}, +>>> {connection,keepalive}, +>>> {pid,<0.491.0>}, +>>> {method,<<"GET">>}, +>>> {version,{1,1}}, +>>> {peer,{{127,0,0,1},56630}}, +>>> {host,<<"localhost">>}, +>>> {host_info,undefined}, +>>> {port,8080}, +>>> {path,<<"/">>}, +>>> {path_info,undefined}, +>>> {qs,<<"encoding=text">>}, +>>> {qs_vals,undefined}, +>>> {fragment,<<>>}, +>>> {bindings,[]}, +>>> {headers,[{<<"upgrade">>,<<"websocket">>}, +>>> {<<"connection">>,<<"Upgrade">>}, +>>> {<<"host">>,<<"localhost:8080">>}, +>>> +>>> {<<"origin">>,<<"http://www.websocket.org">>}, +>>> {<<"pragma">>,<<"no-cache">>}, +>>> {<<"cache-control">>,<<"no-cache">>}, +>>> {<<"sec-websocket-key">>, +>>> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +>>> {<<"sec-websocket-version">>,<<"13">>}, +>>> {<<"sec-websocket-extensions">>, +>>> <<"x-webkit-deflate-frame">>}]}, +>>> {p_headers,[{<<"connection">>,[<<"upgrade">>]}]}, +>>> {cookies,undefined}, +>>> {meta,[]}, +>>> {body_state,waiting}, +>>> {multipart,undefined}, +>>> {buffer,<<>>}, +>>> {resp_compress,false}, +>>> {resp_state,waiting}, +>>> {resp_headers,[]}, +>>> {resp_body,<<>>}, +>>> {onresponse,undefined}] +>>> ** Stacktrace: [{bullet_handler,init, +>>> [{tcp,http}, +>>> +>>> {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>, +>>> <<"GET">>, +>>> {1,1}, +>>> {{127,0,0,1},56630}, +>>> <<"localhost">>,undefined,8080,<<"/">>, +>>> undefined,<<"encoding=text">>,undefined,<<>>, +>>> [], +>>> [{<<"upgrade">>,<<"websocket">>}, +>>> {<<"connection">>,<<"Upgrade">>}, +>>> {<<"host">>,<<"localhost:8080">>}, +>>> +>>> {<<"origin">>,<<"http://www.websocket.org">>}, +>>> {<<"pragma">>,<<"no-cache">>}, +>>> {<<"cache-control">>,<<"no-cache">>}, +>>> {<<"sec-websocket-key">>, +>>> <<"fEj/SOOcQgSKATOjhbNJBQ==">>}, +>>> {<<"sec-websocket-version">>,<<"13">>}, +>>> {<<"sec-websocket-extensions">>, +>>> <<"x-webkit-deflate-frame">>}], +>>> [{<<"connection">>,[<<"upgrade">>]}], +>>> +>>> undefined,[],waiting,undefined,<<>>,false,waiting,[], +>>> <<>>,undefined}, +>>> [{handler,connection_handler}]], +>>> []}, +>>> {cowboy_handler,handler_init,4, +>>> [{file,"src/cowboy_handler.erl"},{line,69}]}, +>>> {cowboy_protocol,execute,4, +>>> [{file,"src/cowboy_protocol.erl"},{line,514}]}] +>>> +>>> Can anyone see what might be throwing this off? I'd like to get a +>>> minimal handler running before I attempt to add some logic. +>>> +>>> Thanks, +>>> Lee +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From lee.sylvester at gmail.com Wed Apr 10 13:47:45 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 10 Apr 2013 12:47:45 +0100 +Subject: [99s-extend] Heartbeat? +Message-ID: + +Hey guys, + +So, my bullet websockets are going great. However, I have a question. At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds. Therefore, should I send a heartbeat to the client from Erlang to keep this open? The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur. + +Thanks, +Lee + +From sasa.juric at gmail.com Wed Apr 10 14:00:47 2013 +From: sasa.juric at gmail.com (Sasa Juric) +Date: Wed, 10 Apr 2013 14:00:47 +0200 +Subject: [99s-extend] cowboy and chromium +Message-ID: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + +Hi, + +I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. + +After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. + +If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. + +After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. + +However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. + +This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? + +Thank you very much in advance and best regards, +Sasa + +From essen at ninenines.eu Wed Apr 10 16:38:26 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 10 Apr 2013 16:38:26 +0200 +Subject: [99s-extend] Heartbeat? +In-Reply-To: +References: +Message-ID: <51657962.8020009@ninenines.eu> + +On 04/10/2013 01:47 PM, Lee Sylvester wrote: +> Hey guys, +> +> So, my bullet websockets are going great. However, I have a question. At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds. Therefore, should I send a heartbeat to the client from Erlang to keep this open? The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur. + +Send one from the client if you want it to scale. Bullet provides you +with one callback that you can use to send anything. If you're using +JSON then sending {} is generally enough. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Wed Apr 10 16:41:21 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 10 Apr 2013 16:41:21 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> +Message-ID: <51657A11.7070902@ninenines.eu> + +On 04/10/2013 02:00 PM, Sasa Juric wrote: +> Hi, +> +> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +> +> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +> +> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +> +> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +> +> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +> +> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? + +Haven't seen this happen on plain Cowboy. The proxy might be the +culprit. See if you can reproduce without the proxy. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From sasa.juric at gmail.com Wed Apr 10 16:50:31 2013 +From: sasa.juric at gmail.com (Sasa Juric) +Date: Wed, 10 Apr 2013 16:50:31 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <51657A11.7070902@ninenines.eu> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> +Message-ID: <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + +I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. + +Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. + +Question: can I configure keep-alive timeout in Cowboy? + + +On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: + +> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>> Hi, +>> +>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>> +>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>> +>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>> +>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>> +>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>> +>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +> +> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Wed Apr 10 16:51:50 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 10 Apr 2013 16:51:50 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> +Message-ID: <51657C86.2060800@ninenines.eu> + +'timeout' protocol option, in milliseconds. + +On 04/10/2013 04:50 PM, Sasa Juric wrote: +> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +> +> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +> +> Question: can I configure keep-alive timeout in Cowboy? +> +> +> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +> +>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>> Hi, +>>> +>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>> +>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>> +>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>> +>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>> +>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>> +>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>> +>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Wed Apr 10 16:53:24 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 10 Apr 2013 15:53:24 +0100 +Subject: [99s-extend] Heartbeat? +In-Reply-To: <51657962.8020009@ninenines.eu> +References: + <51657962.8020009@ninenines.eu> +Message-ID: <2499D410-A700-41A3-A926-F721CC092600@gmail.com> + +Ahh, thank you. + +Regards, +Lee + + + +On 10 Apr 2013, at 15:38, Lo?c Hoguin wrote: + +> On 04/10/2013 01:47 PM, Lee Sylvester wrote: +>> Hey guys, +>> +>> So, my bullet websockets are going great. However, I have a question. At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds. Therefore, should I send a heartbeat to the client from Erlang to keep this open? The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur. +> +> Send one from the client if you want it to scale. Bullet provides you with one callback that you can use to send anything. If you're using JSON then sending {} is generally enough. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From sasa.juric at gmail.com Wed Apr 10 16:56:08 2013 +From: sasa.juric at gmail.com (Sasa Juric) +Date: Wed, 10 Apr 2013 16:56:08 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <51657C86.2060800@ninenines.eu> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + <51657C86.2060800@ninenines.eu> +Message-ID: + +Thanks! + +I was looking at the option, but was confused by description which states: +Time in milliseconds a client has to send the full request line and headers. + +I'll give it a try and see how it works. + +Best regards, +Sasa + +On Apr 10, 2013, at 4:51 PM, Lo?c Hoguin wrote: + +> 'timeout' protocol option, in milliseconds. +> +> On 04/10/2013 04:50 PM, Sasa Juric wrote: +>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +>> +>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +>> +>> Question: can I configure keep-alive timeout in Cowboy? +>> +>> +>> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +>> +>>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>>> Hi, +>>>> +>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>>> +>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>>> +>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>>> +>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>>> +>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>>> +>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>>> +>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Wed Apr 10 17:01:14 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 10 Apr 2013 17:01:14 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + <51657C86.2060800@ninenines.eu> + +Message-ID: <51657EBA.7050506@ninenines.eu> + +Means it's not a read timeout, but a timeout for the whole request up to +and excluding the body (so an intentionally slow client will get +disconnected at 5s). + +On 04/10/2013 04:56 PM, Sasa Juric wrote: +> Thanks! +> +> I was looking at the option, but was confused by description which states: +> Time in milliseconds a client has to send the full request line and headers. +> +> I'll give it a try and see how it works. +> +> Best regards, +> Sasa +> +> On Apr 10, 2013, at 4:51 PM, Lo?c Hoguin wrote: +> +>> 'timeout' protocol option, in milliseconds. +>> +>> On 04/10/2013 04:50 PM, Sasa Juric wrote: +>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +>>> +>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +>>> +>>> Question: can I configure keep-alive timeout in Cowboy? +>>> +>>> +>>> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +>>> +>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>>>> Hi, +>>>>> +>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>>>> +>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>>>> +>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>>>> +>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>>>> +>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>>>> +>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>>>> +>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From sasa.juric at gmail.com Wed Apr 10 17:05:51 2013 +From: sasa.juric at gmail.com (Sasa Juric) +Date: Wed, 10 Apr 2013 17:05:51 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <51657EBA.7050506@ninenines.eu> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + <51657C86.2060800@ninenines.eu> + + <51657EBA.7050506@ninenines.eu> +Message-ID: + +Ok, just to make sure I understand: +When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply? + + +On Apr 10, 2013, at 5:01 PM, Lo?c Hoguin wrote: + +> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s). +> +> On 04/10/2013 04:56 PM, Sasa Juric wrote: +>> Thanks! +>> +>> I was looking at the option, but was confused by description which states: +>> Time in milliseconds a client has to send the full request line and headers. +>> +>> I'll give it a try and see how it works. +>> +>> Best regards, +>> Sasa +>> +>> On Apr 10, 2013, at 4:51 PM, Lo?c Hoguin wrote: +>> +>>> 'timeout' protocol option, in milliseconds. +>>> +>>> On 04/10/2013 04:50 PM, Sasa Juric wrote: +>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +>>>> +>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +>>>> +>>>> Question: can I configure keep-alive timeout in Cowboy? +>>>> +>>>> +>>>> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +>>>> +>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>>>>> Hi, +>>>>>> +>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>>>>> +>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>>>>> +>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>>>>> +>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>>>>> +>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>>>>> +>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>>>>> +>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> Erlang Cowboy +>>>>> Nine Nines +>>>>> http://ninenines.eu +>>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Wed Apr 10 17:07:18 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 10 Apr 2013 17:07:18 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + <51657C86.2060800@ninenines.eu> + + <51657EBA.7050506@ninenines.eu> + +Message-ID: <51658026.2090805@ninenines.eu> + +It's running from the moment Cowboy starts expecting a new request up to +the moment it got the request in full (excluding the body), then it's +reset for the next request. + +On 04/10/2013 05:05 PM, Sasa Juric wrote: +> Ok, just to make sure I understand: +> When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply? +> +> +> On Apr 10, 2013, at 5:01 PM, Lo?c Hoguin wrote: +> +>> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s). +>> +>> On 04/10/2013 04:56 PM, Sasa Juric wrote: +>>> Thanks! +>>> +>>> I was looking at the option, but was confused by description which states: +>>> Time in milliseconds a client has to send the full request line and headers. +>>> +>>> I'll give it a try and see how it works. +>>> +>>> Best regards, +>>> Sasa +>>> +>>> On Apr 10, 2013, at 4:51 PM, Lo?c Hoguin wrote: +>>> +>>>> 'timeout' protocol option, in milliseconds. +>>>> +>>>> On 04/10/2013 04:50 PM, Sasa Juric wrote: +>>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +>>>>> +>>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +>>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +>>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +>>>>> +>>>>> Question: can I configure keep-alive timeout in Cowboy? +>>>>> +>>>>> +>>>>> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +>>>>> +>>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>>>>>> Hi, +>>>>>>> +>>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>>>>>> +>>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>>>>>> +>>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>>>>>> +>>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>>>>>> +>>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>>>>>> +>>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>>>>>> +>>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>>>>>> +>>>>>> -- +>>>>>> Lo?c Hoguin +>>>>>> Erlang Cowboy +>>>>>> Nine Nines +>>>>>> http://ninenines.eu +>>>>> +>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From sasa.juric at gmail.com Wed Apr 10 17:11:57 2013 +From: sasa.juric at gmail.com (Sasa Juric) +Date: Wed, 10 Apr 2013 17:11:57 +0200 +Subject: [99s-extend] cowboy and chromium +In-Reply-To: <51658026.2090805@ninenines.eu> +References: <90FA9B10-201C-469E-AF79-749CF56160F1@gmail.com> + <51657A11.7070902@ninenines.eu> + <3CACD966-2058-4ABF-A819-AE127BE964D7@gmail.com> + <51657C86.2060800@ninenines.eu> + + <51657EBA.7050506@ninenines.eu> + + <51658026.2090805@ninenines.eu> +Message-ID: + +Thanks! + +On Apr 10, 2013, at 5:07 PM, Lo?c Hoguin wrote: + +> It's running from the moment Cowboy starts expecting a new request up to the moment it got the request in full (excluding the body), then it's reset for the next request. +> +> On 04/10/2013 05:05 PM, Sasa Juric wrote: +>> Ok, just to make sure I understand: +>> When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply? +>> +>> +>> On Apr 10, 2013, at 5:01 PM, Lo?c Hoguin wrote: +>> +>>> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s). +>>> +>>> On 04/10/2013 04:56 PM, Sasa Juric wrote: +>>>> Thanks! +>>>> +>>>> I was looking at the option, but was confused by description which states: +>>>> Time in milliseconds a client has to send the full request line and headers. +>>>> +>>>> I'll give it a try and see how it works. +>>>> +>>>> Best regards, +>>>> Sasa +>>>> +>>>> On Apr 10, 2013, at 4:51 PM, Lo?c Hoguin wrote: +>>>> +>>>>> 'timeout' protocol option, in milliseconds. +>>>>> +>>>>> On 04/10/2013 04:50 PM, Sasa Juric wrote: +>>>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion. +>>>>>> +>>>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes. +>>>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout. +>>>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds. +>>>>>> +>>>>>> Question: can I configure keep-alive timeout in Cowboy? +>>>>>> +>>>>>> +>>>>>> On Apr 10, 2013, at 4:41 PM, Lo?c Hoguin wrote: +>>>>>> +>>>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote: +>>>>>>>> Hi, +>>>>>>>> +>>>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers. +>>>>>>>> +>>>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine. +>>>>>>>> +>>>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions. +>>>>>>>> +>>>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily. +>>>>>>>> +>>>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. +>>>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. +>>>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it. +>>>>>>>> +>>>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer? +>>>>>>> +>>>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy. +>>>>>>> +>>>>>>> -- +>>>>>>> Lo?c Hoguin +>>>>>>> Erlang Cowboy +>>>>>>> Nine Nines +>>>>>>> http://ninenines.eu +>>>>>> +>>>>> +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> Erlang Cowboy +>>>>> Nine Nines +>>>>> http://ninenines.eu +>>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From lee.sylvester at gmail.com Thu Apr 11 07:51:12 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 11 Apr 2013 06:51:12 +0100 +Subject: [99s-extend] Distributed model? +Message-ID: + +Hi guys, + +So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. + +I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? + +Thanks, +Lee + +From jeremy at quarkgames.com Thu Apr 11 08:29:16 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Wed, 10 Apr 2013 23:29:16 -0700 +Subject: [99s-extend] Distributed model? +In-Reply-To: +References: +Message-ID: + +Make all the machines identically and add an haproxy (or equivalent) +machine to load balance between all of them. Haproxy can handle many +many requests. Keep in mind that with tcp, the load balancer is just +accepting the socket but then the client communicates with the actual +application server directly afterwards. + +On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester wrote: +> Hi guys, +> +> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. +> +> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? +> +> Thanks, +> Lee +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From lee.sylvester at gmail.com Thu Apr 11 08:49:18 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 11 Apr 2013 07:49:18 +0100 +Subject: [99s-extend] Distributed model? +In-Reply-To: +References: + +Message-ID: <8456939C-6A11-4A18-BD8A-DF378644DACB@gmail.com> + +Thanks Jeremy, but what about inter-node communication? If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that? Especially if this user is sending several messages and expecting replies. Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this? + +Thanks, +Lee + + +On 11 Apr 2013, at 07:29, Jeremy Ong wrote: + +> Make all the machines identically and add an haproxy (or equivalent) +> machine to load balance between all of them. Haproxy can handle many +> many requests. Keep in mind that with tcp, the load balancer is just +> accepting the socket but then the client communicates with the actual +> application server directly afterwards. +> +> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester wrote: +>> Hi guys, +>> +>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. +>> +>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? +>> +>> Thanks, +>> Lee +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend + + + +From jeremy at quarkgames.com Thu Apr 11 09:04:04 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Thu, 11 Apr 2013 00:04:04 -0700 +Subject: [99s-extend] Distributed model? +In-Reply-To: <8456939C-6A11-4A18-BD8A-DF378644DACB@gmail.com> +References: + + <8456939C-6A11-4A18-BD8A-DF378644DACB@gmail.com> +Message-ID: + +I see. I assume this is for a chat server of some sort? + +You don't want the user process sending all these messages because the +user process wouldn't be able to do anything useful (like receive +messages) in the meantime. + +Better is to implement a pubsub process for each channel of +communication (i.e. one process per room) or rely on Redis pubsub or +something if speed is extremely important. + +There is no way to get around the O(N) complexity of broadcasting. + +On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester wrote: +> Thanks Jeremy, but what about inter-node communication? If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that? Especially if this user is sending several messages and expecting replies. Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this? +> +> Thanks, +> Lee +> +> +> On 11 Apr 2013, at 07:29, Jeremy Ong wrote: +> +>> Make all the machines identically and add an haproxy (or equivalent) +>> machine to load balance between all of them. Haproxy can handle many +>> many requests. Keep in mind that with tcp, the load balancer is just +>> accepting the socket but then the client communicates with the actual +>> application server directly afterwards. +>> +>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester wrote: +>>> Hi guys, +>>> +>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. +>>> +>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? +>>> +>>> Thanks, +>>> Lee +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +> + + +From lee.sylvester at gmail.com Thu Apr 11 14:55:29 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 11 Apr 2013 13:55:29 +0100 +Subject: [99s-extend] Distributed model? +In-Reply-To: +References: + + <8456939C-6A11-4A18-BD8A-DF378644DACB@gmail.com> + +Message-ID: + +Thank you, Jeremy, that's good advice. It's not so much a chat platform, but I guess it would resemble one in architecture. The part I'm concerned about, though, is should I be avoiding the internal Erlang messaging between connections (over many nodes) for heavy messaging? + +Thanks, +Lee + + + +On 11 Apr 2013, at 08:04, Jeremy Ong wrote: + +> I see. I assume this is for a chat server of some sort? +> +> You don't want the user process sending all these messages because the +> user process wouldn't be able to do anything useful (like receive +> messages) in the meantime. +> +> Better is to implement a pubsub process for each channel of +> communication (i.e. one process per room) or rely on Redis pubsub or +> something if speed is extremely important. +> +> There is no way to get around the O(N) complexity of broadcasting. +> +> On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester wrote: +>> Thanks Jeremy, but what about inter-node communication? If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that? Especially if this user is sending several messages and expecting replies. Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this? +>> +>> Thanks, +>> Lee +>> +>> +>> On 11 Apr 2013, at 07:29, Jeremy Ong wrote: +>> +>>> Make all the machines identically and add an haproxy (or equivalent) +>>> machine to load balance between all of them. Haproxy can handle many +>>> many requests. Keep in mind that with tcp, the load balancer is just +>>> accepting the socket but then the client communicates with the actual +>>> application server directly afterwards. +>>> +>>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester wrote: +>>>> Hi guys, +>>>> +>>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. +>>>> +>>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? +>>>> +>>>> Thanks, +>>>> Lee +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> http://lists.ninenines.eu:81/listinfo/extend +>> + + + +From lee.sylvester at gmail.com Thu Apr 11 17:46:35 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 11 Apr 2013 16:46:35 +0100 +Subject: [99s-extend] Distributed model? +In-Reply-To: +References: + + <8456939C-6A11-4A18-BD8A-DF378644DACB@gmail.com> + + +Message-ID: <4011ABA6-BD55-4DEB-BE8F-2E20F2376A25@gmail.com> + +Okay, so I've figured it out. I will need to have a separate messaging layer. Does anyone know of a messaging layer that can be used when all you know is the PID to send to? + +Thanks, +Lee + + + +On 11 Apr 2013, at 13:55, Lee Sylvester wrote: + +> Thank you, Jeremy, that's good advice. It's not so much a chat platform, but I guess it would resemble one in architecture. The part I'm concerned about, though, is should I be avoiding the internal Erlang messaging between connections (over many nodes) for heavy messaging? +> +> Thanks, +> Lee +> +> +> +> On 11 Apr 2013, at 08:04, Jeremy Ong wrote: +> +>> I see. I assume this is for a chat server of some sort? +>> +>> You don't want the user process sending all these messages because the +>> user process wouldn't be able to do anything useful (like receive +>> messages) in the meantime. +>> +>> Better is to implement a pubsub process for each channel of +>> communication (i.e. one process per room) or rely on Redis pubsub or +>> something if speed is extremely important. +>> +>> There is no way to get around the O(N) complexity of broadcasting. +>> +>> On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester wrote: +>>> Thanks Jeremy, but what about inter-node communication? If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that? Especially if this user is sending several messages and expecting replies. Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this? +>>> +>>> Thanks, +>>> Lee +>>> +>>> +>>> On 11 Apr 2013, at 07:29, Jeremy Ong wrote: +>>> +>>>> Make all the machines identically and add an haproxy (or equivalent) +>>>> machine to load balance between all of them. Haproxy can handle many +>>>> many requests. Keep in mind that with tcp, the load balancer is just +>>>> accepting the socket but then the client communicates with the actual +>>>> application server directly afterwards. +>>>> +>>>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester wrote: +>>>>> Hi guys, +>>>>> +>>>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list. I'm now looking at the best means of clustering this app. I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away. +>>>>> +>>>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection. I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes. With this in mind, should I look at adding a ZMQ layer or some such to facilitate this? What is the general solution to high traffic between nodes? +>>>>> +>>>>> Thanks, +>>>>> Lee +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +> + + + +From Kevin.Brown at turner.com Fri Apr 12 01:37:18 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Thu, 11 Apr 2013 23:37:18 +0000 +Subject: [99s-extend] populating #http_req for unit testing +In-Reply-To: +Message-ID: + + +Cowfolk, + +I am doing something like this to create an #http_req suitable for unit +testing my resource callbacks: + +-define (HTTP_REQ_ENCODERS_PORT_8000, #http_req{host= <<"www.foo.com">> , +port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>, fragment= +<<>> }). + +Notice that I needed to set the transport to a Cowboy specific atom +because I wanted to get cowboy_req:host_url and cowboy_req:path to work +properly. + +I'm sure there is a method that Cowboy uses internally to populate an +#http_req from a URL that I could use for testing. What might that be? +How else should I be populating this record. + +Cheers, + +-kb + + + + + + +On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu" + wrote: + +>Welcome to the Extend at lists.ninenines.eu mailing list! +> +>To post to this list, send your message to: +> +> extend at lists.ninenines.eu +> +>General information about the mailing list is at: +> +> http://lists.ninenines.eu:81/listinfo/extend +> +>If you ever want to unsubscribe or change your options (eg, switch to +>or from digest mode, change your password, etc.), visit your +>subscription page at: +> +> http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com +> +>You can also make such adjustments via email by sending a message to: +> +> Extend-request at lists.ninenines.eu +> +>with the word `help' in the subject or body (don't include the +>quotes), and you will get back a message with instructions. +> +>You must know your password to change your options (including changing +>the password, itself) or to unsubscribe without confirmation. It is: +> +> doofus1 +> +>Normally, Mailman will remind you of your lists.ninenines.eu mailing +>list passwords once every month, although you can disable this if you +>prefer. This reminder will also include instructions on how to +>unsubscribe or change your account options. There is also a button on +>your options page that will email your current password to you. +> + + + + +From essen at ninenines.eu Fri Apr 12 02:07:26 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 12 Apr 2013 02:07:26 +0200 +Subject: [99s-extend] populating #http_req for unit testing +In-Reply-To: +References: +Message-ID: <5167503E.5070204@ninenines.eu> + +There's a few undocumented functions in cowboy_req, like new, set and +get, used by Cowboy internally. + +On 04/12/2013 01:37 AM, Brown, Kevin wrote: +> +> Cowfolk, +> +> I am doing something like this to create an #http_req suitable for unit +> testing my resource callbacks: +> +> -define (HTTP_REQ_ENCODERS_PORT_8000, #http_req{host= <<"www.foo.com">> , +> port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>, fragment= +> <<>> }). +> +> Notice that I needed to set the transport to a Cowboy specific atom +> because I wanted to get cowboy_req:host_url and cowboy_req:path to work +> properly. +> +> I'm sure there is a method that Cowboy uses internally to populate an +> #http_req from a URL that I could use for testing. What might that be? +> How else should I be populating this record. +> +> Cheers, +> +> -kb +> +> +> +> +> +> +> On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu" +> wrote: +> +>> Welcome to the Extend at lists.ninenines.eu mailing list! +>> +>> To post to this list, send your message to: +>> +>> extend at lists.ninenines.eu +>> +>> General information about the mailing list is at: +>> +>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> If you ever want to unsubscribe or change your options (eg, switch to +>> or from digest mode, change your password, etc.), visit your +>> subscription page at: +>> +>> http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com +>> +>> You can also make such adjustments via email by sending a message to: +>> +>> Extend-request at lists.ninenines.eu +>> +>> with the word `help' in the subject or body (don't include the +>> quotes), and you will get back a message with instructions. +>> +>> You must know your password to change your options (including changing +>> the password, itself) or to unsubscribe without confirmation. It is: +>> +>> doofus1 +>> +>> Normally, Mailman will remind you of your lists.ninenines.eu mailing +>> list passwords once every month, although you can disable this if you +>> prefer. This reminder will also include instructions on how to +>> unsubscribe or change your account options. There is also a button on +>> your options page that will email your current password to you. +>> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Kevin.Brown at turner.com Fri Apr 12 02:30:15 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Fri, 12 Apr 2013 00:30:15 +0000 +Subject: [99s-extend] populating #http_req for unit testing +In-Reply-To: <5167503E.5070204@ninenines.eu> +Message-ID: + +Thanks. + +On 4/11/13 8:07 PM, "Lo?c Hoguin" wrote: + +>There's a few undocumented functions in cowboy_req, like new, set and +>get, used by Cowboy internally. +> +>On 04/12/2013 01:37 AM, Brown, Kevin wrote: +>> +>> Cowfolk, +>> +>> I am doing something like this to create an #http_req suitable for unit +>> testing my resource callbacks: +>> +>> -define (HTTP_REQ_ENCODERS_PORT_8000, #http_req{host= +>><<"www.foo.com">> , +>> port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>, +>>fragment= +>> <<>> }). +>> +>> Notice that I needed to set the transport to a Cowboy specific atom +>> because I wanted to get cowboy_req:host_url and cowboy_req:path to work +>> properly. +>> +>> I'm sure there is a method that Cowboy uses internally to populate an +>> #http_req from a URL that I could use for testing. What might that be? +>> How else should I be populating this record. +>> +>> Cheers, +>> +>> -kb +>> +>> +>> +>> +>> +>> +>> On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu" +>> wrote: +>> +>>> Welcome to the Extend at lists.ninenines.eu mailing list! +>>> +>>> To post to this list, send your message to: +>>> +>>> extend at lists.ninenines.eu +>>> +>>> General information about the mailing list is at: +>>> +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>>> If you ever want to unsubscribe or change your options (eg, switch to +>>> or from digest mode, change your password, etc.), visit your +>>> subscription page at: +>>> +>>> http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com +>>> +>>> You can also make such adjustments via email by sending a message to: +>>> +>>> Extend-request at lists.ninenines.eu +>>> +>>> with the word `help' in the subject or body (don't include the +>>> quotes), and you will get back a message with instructions. +>>> +>>> You must know your password to change your options (including changing +>>> the password, itself) or to unsubscribe without confirmation. It is: +>>> +>>> doofus1 +>>> +>>> Normally, Mailman will remind you of your lists.ninenines.eu mailing +>>> list passwords once every month, although you can disable this if you +>>> prefer. This reminder will also include instructions on how to +>>> unsubscribe or change your account options. There is also a button on +>>> your options page that will email your current password to you. +>>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +>-- +>Lo?c Hoguin +>Erlang Cowboy +>Nine Nines +>http://ninenines.eu +> + + + + +From edgurgel at gmail.com Sat Apr 13 13:12:39 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Sat, 13 Apr 2013 08:12:39 -0300 +Subject: [99s-extend] populating #http_req for unit testing +In-Reply-To: +References: + +Message-ID: + +On Thu, Apr 11, 2013 at 8:37 PM, Brown, Kevin wrote: + +> +> Cowfolk, +> +> I am doing something like this to create an #http_req suitable for unit +> testing my resource callbacks: +> + + +I use the library meck(https://github.com/eproxus/meck) to test stuff doing +something like this: + +some_test() -> + meck:expect(cowboy_req, binding, 2, {<<"app_key">>, req} ) + ?assertEqual({ok, req, empty}, + websocket_handler:websocket_init(transport, req, opts)), + ?assert(meck:validate(cowboy_req)). + +I use simple atoms as input and mock the cowboy_req functions to return +atoms that would represent the correct or the wrong answer. + +The real implementation or how cowboy represent stuff is not important +here, just the output pattern like {Binding, Req}. + +That's it + +-- + +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From erlang at rambocoder.com Mon Apr 15 22:45:42 2013 +From: erlang at rambocoder.com (rambocoder) +Date: Mon, 15 Apr 2013 16:45:42 -0400 +Subject: [99s-extend] Reading body_qs multiple times +Message-ID: + +Hello group, + +I am trying to put together a CSRF middleware +https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693 +and +if the body of the request contains "_csrf" token, I check to make sure it +matches the csrf token in the session. + +Currently I am doing it in middleware using cowboy_req:body_qs/1 however +when in the handler I need to read another body parameter, such as in the +rest_pastebin example: + +{ok, BodyQs, Req3} = cowboy_req:body_qs(Req), +Paste = proplists:get_value(<<"paste">>, BodyQs), + +cowboy_req:body_qs/1 returns [] due to the body of the request being +already read {body_state,done} + +Is it pointless to have the type of CSRF middleware that I am writing and +just do the CSRF in the handler's callback, where I can deal with all the +body_qs at once? + +Thank you, + +rambocoder +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Apr 15 22:47:47 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 15 Apr 2013 22:47:47 +0200 +Subject: [99s-extend] Reading body_qs multiple times +In-Reply-To: +References: +Message-ID: <516C6773.1000004@ninenines.eu> + +Why not just put the token in the URL instead? if it's CSRF then it's +probably used only once and only for POST and the like, so not cached or +anything. + +On 04/15/2013 10:45 PM, rambocoder wrote: +> Hello group, +> +> I am trying to put together a CSRF middleware +> https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693 and +> if the body of the request contains "_csrf" token, I check to make sure +> it matches the csrf token in the session. +> +> Currently I am doing it in middleware using cowboy_req:body_qs/1 however +> when in the handler I need to read another body parameter, such as in +> the rest_pastebin example: +> +> {ok, BodyQs, Req3} = cowboy_req:body_qs(Req), +> Paste = proplists:get_value(<<"paste">>, BodyQs), +> +> cowboy_req:body_qs/1 returns [] due to the body of the request being +> already read {body_state,done} +> +> Is it pointless to have the type of CSRF middleware that I am writing +> and just do the CSRF in the handler's callback, where I can deal with +> all the body_qs at once? +> +> Thank you, +> +> rambocoder +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From erlang at rambocoder.com Tue Apr 16 02:13:44 2013 +From: erlang at rambocoder.com (rambocoder) +Date: Mon, 15 Apr 2013 20:13:44 -0400 +Subject: [99s-extend] Reading body_qs multiple times +In-Reply-To: <516C6773.1000004@ninenines.eu> +References: + <516C6773.1000004@ninenines.eu> +Message-ID: + +Loic, + +After giving the CSRF middleware some thought and reading +https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL +I +came to conclusion that it is best to just not create the middleware and +instead deal with CSRF on as needed basis. + +I know that node's Connect middleware +http://www.senchalabs.org/connect/csrf.html#defaultValue for example allows +for the csrf token to be passed as a query string parameter, however, the +OWASP article made me think that it is not the most secure approach. + +For example, AngularJS http://docs.angularjs.org/api/ng.$http has a section +on how their AJAX component behaves to do CSRF out of the box, and they are +talking about the server sending a cookie XSRF-TOKEN that is not HttpOnly. +That makes me realize that csrf is a process more than just slapping some +middleware into the pipeline. + +Btw, I noticed that when the result of the middleware execute function is: +{error, StatusCode, Req} +if I set the reply on the request via cowboy_req:reply before returning the +{error.. , the status code of that reply will be used. + +Such as: +{ok, Req3} = cowboy_req:reply(403, [], "Invalid CSRF Token.", Req2), +{error, 500, Req3}; % 500 is ignored, 403 is returned + +Is that by design? + +Sincerely, + +rambocoder + + + +On Mon, Apr 15, 2013 at 4:47 PM, Lo?c Hoguin wrote: + +> Why not just put the token in the URL instead? if it's CSRF then it's +> probably used only once and only for POST and the like, so not cached or +> anything. +> +> +> On 04/15/2013 10:45 PM, rambocoder wrote: +> +>> Hello group, +>> +>> I am trying to put together a CSRF middleware +>> https://github.com/rambocoder/**stable/commit/** +>> b26980d292ac42aadfe9921a961436**e28cdbb693and +>> if the body of the request contains "_csrf" token, I check to make sure +>> it matches the csrf token in the session. +>> +>> Currently I am doing it in middleware using cowboy_req:body_qs/1 however +>> when in the handler I need to read another body parameter, such as in +>> the rest_pastebin example: +>> +>> {ok, BodyQs, Req3} = cowboy_req:body_qs(Req), +>> Paste = proplists:get_value(<<"paste">**>, BodyQs), +>> +>> cowboy_req:body_qs/1 returns [] due to the body of the request being +>> already read {body_state,done} +>> +>> Is it pointless to have the type of CSRF middleware that I am writing +>> and just do the CSRF in the handler's callback, where I can deal with +>> all the body_qs at once? +>> +>> Thank you, +>> +>> rambocoder +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Apr 16 13:34:14 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 16 Apr 2013 13:34:14 +0200 +Subject: [99s-extend] Reading body_qs multiple times +In-Reply-To: +References: + <516C6773.1000004@ninenines.eu> + +Message-ID: <516D3736.4000106@ninenines.eu> + +On 04/16/2013 02:13 AM, rambocoder wrote: +> Loic, +> +> After giving the CSRF middleware some thought and reading +> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL I +> came to conclusion that it is best to just not create the middleware and +> instead deal with CSRF on as needed basis. + +Your link says what I said too, except I probably wasn't explicit enough. + +If you have a form that does POST (or PUT or PATCH or DELETE), put the +token in "
". The token must +be only valid once, it must not be reused, not even between different +forms (each form gets its own token). Since it is not a GET request, +then you don't have cache or referer issues. + +You can still have issues if you allow another site to run JS on yours +(but you probably shouldn't) or if there is a malevolent proxy (use SSL +where needed), but these are different issues entirely. + +> Btw, I noticed that when the result of the middleware execute function is: +> {error, StatusCode, Req} +> if I set the reply on the request via cowboy_req:reply before returning +> the {error.. , the status code of that reply will be used. +> +> Such as: +> {ok, Req3} = cowboy_req:reply(403, [], "Invalid CSRF Token.", Req2), +> {error, 500, Req3}; % 500 is ignored, 403 is returned + +Yes, the response was already sent, therefore the second one is ignored. + +> Is that by design? +> +> Sincerely, +> +> rambocoder +> +> +> +> On Mon, Apr 15, 2013 at 4:47 PM, Lo?c Hoguin > wrote: +> +> Why not just put the token in the URL instead? if it's CSRF then +> it's probably used only once and only for POST and the like, so not +> cached or anything. +> +> +> On 04/15/2013 10:45 PM, rambocoder wrote: +> +> Hello group, +> +> I am trying to put together a CSRF middleware +> https://github.com/rambocoder/__stable/commit/__b26980d292ac42aadfe9921a961436__e28cdbb693 +> +> and +> if the body of the request contains "_csrf" token, I check to +> make sure +> it matches the csrf token in the session. +> +> Currently I am doing it in middleware using cowboy_req:body_qs/1 +> however +> when in the handler I need to read another body parameter, such +> as in +> the rest_pastebin example: +> +> {ok, BodyQs, Req3} = cowboy_req:body_qs(Req), +> Paste = proplists:get_value(<<"paste">__>, BodyQs), +> +> cowboy_req:body_qs/1 returns [] due to the body of the request being +> already read {body_state,done} +> +> Is it pointless to have the type of CSRF middleware that I am +> writing +> and just do the CSRF in the handler's callback, where I can deal +> with +> all the body_qs at once? +> +> Thank you, +> +> rambocoder +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/__listinfo/extend +> +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Fri Apr 19 16:47:09 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Fri, 19 Apr 2013 15:47:09 +0100 +Subject: [99s-extend] Cowboy CORS +Message-ID: <0103B45C-A73C-498E-908D-AA1639D3DEE1@gmail.com> + +Hi guys, + +So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (test.localhost.com and cowboy.localhost.com). However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy. Here's the OPTIONS response from Chrome's console: + + +Request URL:http://www.example.com/ +Request Method:OPTIONS +Status Code:200 OK +Request Headersview source +Accept:*/* +Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +Accept-Encoding:gzip,deflate,sdch +Accept-Language:en-US,en;q=0.8 +Access-Control-Request-Headers:origin, method, content-type +Access-Control-Request-Method:POST +Connection:keep-alive +Host:www.example.com +Origin:http://test.localhost.com:8889 +Referer:http://test.localhost.com:8889/ +User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +Response Headersview source +Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method +Access-Control-Allow-Methods:GET, POST, OPTIONS +Access-Control-Allow-Origin:* +connection:keep-alive +content-length:0 +date:Fri, 19 Apr 2013 14:40:00 GMT +server:Cowboy + +And then this is the POST response: + +Request URL:http://www.example.com/ +Request Headersview parsed +POST http://www.example.com/ HTTP/1.1 +Origin: http://test.localhost.com:8889 +Referer: http://test.localhost.com:8889/ +method: POST http://www.example.com/ HTTP/1.1 +User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +content-type: application/x-www-form-urlencoded +Form Dataview parsed +data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"www.example.com","Application":"test_app","Ident":"lee"} + +I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working. Can anyone spot what I might be doing wrong? + +The cowboy_req:set_resp_header is happening in the handle? So + +handle(Req, State) -> + Reply = case cowboy_req:method(Req) of + {<<"POST">>, Req2} -> + Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2), +[snip] + + +Thanks, +Lee + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From Christopher.Phillips at turner.com Fri Apr 19 17:08:03 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 19 Apr 2013 15:08:03 +0000 +Subject: [99s-extend] Cowboy CORS +In-Reply-To: <0103B45C-A73C-498E-908D-AA1639D3DEE1@gmail.com> +Message-ID: + + When querying to the VM from a browser, is Chrome complaining that it's a cross domain request in the console? Or something else? + + Is the OPTIONS request firing and failing, or is it the POST that is failing (in the network tab)? + + If it's working in a cross origin context for you locally across different domains (I.e., the browser is sending the CORS headers on the request, and you're seeing the right headers on the response, and the browser is handling them properly, such that you can retrieve the response from your Javascript), then it seems unlikely to be a CORS issue, but maybe a config or proxy or code issue in your handler. + + +From: Lee Sylvester > +Date: Friday, April 19, 2013 10:47 AM +To: "extend at lists.ninenines.eu" > +Subject: [99s-extend] Cowboy CORS + +Hi guys, + +So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (test.localhost.com and cowboy.localhost.com). However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy. Here's the OPTIONS response from Chrome's console: + + + + 1. +Request URL: +http://www.example.com/ + 2. +Request Method: +OPTIONS + 3. +Status Code: +200 OK + 4. Request Headersview source + * +Accept: +*/* + * +Accept-Charset: +ISO-8859-1,utf-8;q=0.7,*;q=0.3 + * +Accept-Encoding: +gzip,deflate,sdch + * +Accept-Language: +en-US,en;q=0.8 + * +Access-Control-Request-Headers: +origin, method, content-type + * +Access-Control-Request-Method: +POST + * +Connection: +keep-alive + * +Host: +www.example.com + * +Origin: +http://test.localhost.com:8889 + * +Referer: +http://test.localhost.com:8889/ + * +User-Agent: +Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 + 5. Response Headersview source + * +Access-Control-Allow-Headers: +Content-Type, X-Requested-With, Origin, Method + * +Access-Control-Allow-Methods: +GET, POST, OPTIONS + * +Access-Control-Allow-Origin: +* + * +connection: +keep-alive + * +content-length: +0 + * +date: +Fri, 19 Apr 2013 14:40:00 GMT + * +server: +Cowboy + +And then this is the POST response: + + + 1. +Request URL: +http://www.example.com/ + 2. Request Headersview parsed + * POST http://www.example.com/ HTTP/1.1 Origin: http://test.localhost.com:8889 Referer: http://test.localhost.com:8889/ method: POST http://www.example.com/ HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 content-type: application/x-www-form-urlencoded + 3. Form Dataview parsed + * data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"www.example.com","Application":"test_app","Ident":"lee"} + +I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working. Can anyone spot what I might be doing wrong? + +The cowboy_req:set_resp_header is happening in the handle? So + +handle(Req, State) -> +Reply = case cowboy_req:method(Req) of +{<<"POST">>, Req2} -> +Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2), +[snip] + + +Thanks, +Lee + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lee.sylvester at gmail.com Mon Apr 22 14:59:54 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Mon, 22 Apr 2013 13:59:54 +0100 +Subject: [99s-extend] 505 error +Message-ID: <7E836341-BC4B-4575-AAFC-9F610A5610AE@gmail.com> + +Hi guys, + +So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed. I am now able to use these from many machines from many locations. However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance: + +Request URL:http://www.example.com +Request Method:OPTIONS +Status Code:505 HTTP Version Not Supported +Request Headersview source +Accept:*/* +Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +Accept-Encoding:gzip,deflate,sdch +Accept-Language:en-US,en;q=0.8 +Access-Control-Request-Headers:origin, method, content-type +Access-Control-Request-Method:POST +Connection:keep-alive +Host:www.example.com +Origin:http://www.test.com +Referer:http://www.test.com/ +User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +Response Headersview source +connection:close +content-length:0 +date:Mon, 22 Apr 2013 12:22:50 GMT +server:Cowboy + +To get around the CORS issue, I set up an onrequest hook, which points to the function: + +set_request_cors(Req) -> + Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req), + Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), + cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3). + +I'm afraid I don't have any more info, but this issue is completely eluding me. + +Thanks, +Lee + + + +From Kevin.Brown at turner.com Mon Apr 22 16:28:11 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Mon, 22 Apr 2013 14:28:11 +0000 +Subject: [99s-extend] 505 error +In-Reply-To: <7E836341-BC4B-4575-AAFC-9F610A5610AE@gmail.com> +References: <7E836341-BC4B-4575-AAFC-9F610A5610AE@gmail.com> +Message-ID: <74D3D8EB-2285-47F5-9BD9-BED2021BE79A@turner.com> + +What is the exact http request sent on the failing and successful machines? How do the differ? + +Stack trace? + +On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" wrote: + +> Hi guys, +> +> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed. I am now able to use these from many machines from many locations. However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance: +> +> Request URL:http://www.example.com +> Request Method:OPTIONS +> Status Code:505 HTTP Version Not Supported +> Request Headersview source +> Accept:*/* +> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +> Accept-Encoding:gzip,deflate,sdch +> Accept-Language:en-US,en;q=0.8 +> Access-Control-Request-Headers:origin, method, content-type +> Access-Control-Request-Method:POST +> Connection:keep-alive +> Host:www.example.com +> Origin:http://www.test.com +> Referer:http://www.test.com/ +> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +> Response Headersview source +> connection:close +> content-length:0 +> date:Mon, 22 Apr 2013 12:22:50 GMT +> server:Cowboy +> +> To get around the CORS issue, I set up an onrequest hook, which points to the function: +> +> set_request_cors(Req) -> +> Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req), +> Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3). +> +> I'm afraid I don't have any more info, but this issue is completely eluding me. +> +> Thanks, +> Lee +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + + +From lee.sylvester at gmail.com Mon Apr 22 16:40:19 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Mon, 22 Apr 2013 15:40:19 +0100 +Subject: [99s-extend] 505 error +In-Reply-To: <74D3D8EB-2285-47F5-9BD9-BED2021BE79A@turner.com> +References: <7E836341-BC4B-4575-AAFC-9F610A5610AE@gmail.com> + <74D3D8EB-2285-47F5-9BD9-BED2021BE79A@turner.com> +Message-ID: <8D420762-BBE6-48AC-81C9-56FED6EDA3F2@gmail.com> + +Well, the below is the sent and return headers on the failing machine. On a succeeding machine, the headers are + +Request URL:http://www.example.com +Request Method:OPTIONS +Status Code:200 OK + +Request Headersview source +Accept:*/* +Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +Accept-Encoding:gzip,deflate,sdch +Accept-Language:en-US,en;q=0.8 +Access-Control-Request-Headers:origin, method, content-type +Access-Control-Request-Method:POST +Connection:keep-alive +Host:www.example.com +Origin:http://www.test.com +Referer:http://www.test.com/ +User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 + +Response Headersview source +Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method +Access-Control-Allow-Methods:GET, POST, OPTIONS +Access-Control-Allow-Origin:* +connection:keep-alive +content-length:68 +date:Mon, 22 Apr 2013 14:33:30 GMT +server:Cowboy + +As you can see, the header control and content isn't being sent back and the connection is closed. + +Thanks, +Lee + + + + +On 22 Apr 2013, at 15:28, "Brown, Kevin" wrote: + +> What is the exact http request sent on the failing and successful machines? How do the differ? +> +> Stack trace? +> +> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" wrote: +> +>> Hi guys, +>> +>> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed. I am now able to use these from many machines from many locations. However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance: +>> +>> Request URL:http://www.example.com +>> Request Method:OPTIONS +>> Status Code:505 HTTP Version Not Supported +>> +>> Request Headersview source +>> Accept:*/* +>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>> Accept-Encoding:gzip,deflate,sdch +>> Accept-Language:en-US,en;q=0.8 +>> Access-Control-Request-Headers:origin, method, content-type +>> Access-Control-Request-Method:POST +>> Connection:keep-alive +>> Host:www.example.com +>> Origin:http://www.test.com +>> Referer:http://www.test.com/ +>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +>> +>> Response Headersview source +>> connection:close +>> content-length:0 +>> date:Mon, 22 Apr 2013 12:22:50 GMT +>> server:Cowboy +>> +>> To get around the CORS issue, I set up an onrequest hook, which points to the function: +>> +>> set_request_cors(Req) -> +>> Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req), +>> Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3). +>> +>> I'm afraid I don't have any more info, but this issue is completely eluding me. +>> +>> Thanks, +>> Lee +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> + + + +From essen at ninenines.eu Mon Apr 22 17:53:44 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 22 Apr 2013 17:53:44 +0200 +Subject: [99s-extend] 505 error +In-Reply-To: <8D420762-BBE6-48AC-81C9-56FED6EDA3F2@gmail.com> +References: <7E836341-BC4B-4575-AAFC-9F610A5610AE@gmail.com> + <74D3D8EB-2285-47F5-9BD9-BED2021BE79A@turner.com> + <8D420762-BBE6-48AC-81C9-56FED6EDA3F2@gmail.com> +Message-ID: <51755D08.2070006@ninenines.eu> + +Headers are one thing but it'd be useful to know the request line itself. + +On 04/22/2013 04:40 PM, Lee Sylvester wrote: +> Well, the below is the sent and return headers on the failing machine. On a succeeding machine, the headers are +> +> Request URL:http://www.example.com +> Request Method:OPTIONS +> Status Code:200 OK +> +> Request Headersview source +> Accept:*/* +> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +> Accept-Encoding:gzip,deflate,sdch +> Accept-Language:en-US,en;q=0.8 +> Access-Control-Request-Headers:origin, method, content-type +> Access-Control-Request-Method:POST +> Connection:keep-alive +> Host:www.example.com +> Origin:http://www.test.com +> Referer:http://www.test.com/ +> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +> +> Response Headersview source +> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method +> Access-Control-Allow-Methods:GET, POST, OPTIONS +> Access-Control-Allow-Origin:* +> connection:keep-alive +> content-length:68 +> date:Mon, 22 Apr 2013 14:33:30 GMT +> server:Cowboy +> +> As you can see, the header control and content isn't being sent back and the connection is closed. +> +> Thanks, +> Lee +> +> +> +> +> On 22 Apr 2013, at 15:28, "Brown, Kevin" wrote: +> +>> What is the exact http request sent on the failing and successful machines? How do the differ? +>> +>> Stack trace? +>> +>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" wrote: +>> +>>> Hi guys, +>>> +>>> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed. I am now able to use these from many machines from many locations. However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance: +>>> +>>> Request URL:http://www.example.com +>>> Request Method:OPTIONS +>>> Status Code:505 HTTP Version Not Supported +>>> +>>> Request Headersview source +>>> Accept:*/* +>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>>> Accept-Encoding:gzip,deflate,sdch +>>> Accept-Language:en-US,en;q=0.8 +>>> Access-Control-Request-Headers:origin, method, content-type +>>> Access-Control-Request-Method:POST +>>> Connection:keep-alive +>>> Host:www.example.com +>>> Origin:http://www.test.com +>>> Referer:http://www.test.com/ +>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +>>> +>>> Response Headersview source +>>> connection:close +>>> content-length:0 +>>> date:Mon, 22 Apr 2013 12:22:50 GMT +>>> server:Cowboy +>>> +>>> To get around the CORS issue, I set up an onrequest hook, which points to the function: +>>> +>>> set_request_cors(Req) -> +>>> Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req), +>>> Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3). +>>> +>>> I'm afraid I don't have any more info, but this issue is completely eluding me. +>>> +>>> Thanks, +>>> Lee +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Kevin.Brown at turner.com Mon Apr 22 17:55:11 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Mon, 22 Apr 2013 15:55:11 +0000 +Subject: [99s-extend] 505 error +In-Reply-To: <8D420762-BBE6-48AC-81C9-56FED6EDA3F2@gmail.com> +Message-ID: + +You might see if "view source" (rather than the parsed view you sent) +yields any clues. You'd like to see HTTP version being sent. + + +On 4/22/13 10:40 AM, "Lee Sylvester" wrote: + +>Well, the below is the sent and return headers on the failing machine. +>On a succeeding machine, the headers are +> +>Request URL:http://www.example.com +>Request Method:OPTIONS +>Status Code:200 OK +> +>Request Headersview source +>Accept:*/* +>Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>Accept-Encoding:gzip,deflate,sdch +>Accept-Language:en-US,en;q=0.8 +>Access-Control-Request-Headers:origin, method, content-type +>Access-Control-Request-Method:POST +>Connection:keep-alive +>Host:www.example.com +>Origin:http://www.test.com +>Referer:http://www.test.com/ +>User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) +>AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +> +>Response Headersview source +>Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, +>Method +>Access-Control-Allow-Methods:GET, POST, OPTIONS +>Access-Control-Allow-Origin:* +>connection:keep-alive +>content-length:68 +>date:Mon, 22 Apr 2013 14:33:30 GMT +>server:Cowboy +> +>As you can see, the header control and content isn't being sent back and +>the connection is closed. +> +>Thanks, +>Lee +> +> +> +> +>On 22 Apr 2013, at 15:28, "Brown, Kevin" wrote: +> +>> What is the exact http request sent on the failing and successful +>>machines? How do the differ? +>> +>> Stack trace? +>> +>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" +>>wrote: +>> +>>> Hi guys, +>>> +>>> So, I was getting a CORS issue when connecting to my Bullet impl, +>>>which I have since fixed. I am now able to use these from many +>>>machines from many locations. However, I have found some machines to +>>>be getting a 505 error when making a POST request to the Cowboy +>>>instance: +>>> +>>> Request URL:http://www.example.com +>>> Request Method:OPTIONS +>>> Status Code:505 HTTP Version Not Supported +>>> +>>> Request Headersview source +>>> Accept:*/* +>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>>> Accept-Encoding:gzip,deflate,sdch +>>> Accept-Language:en-US,en;q=0.8 +>>> Access-Control-Request-Headers:origin, method, content-type +>>> Access-Control-Request-Method:POST +>>> Connection:keep-alive +>>> Host:www.example.com +>>> Origin:http://www.test.com +>>> Referer:http://www.test.com/ +>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 +>>>(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +>>> +>>> Response Headersview source +>>> connection:close +>>> content-length:0 +>>> date:Mon, 22 Apr 2013 12:22:50 GMT +>>> server:Cowboy +>>> +>>> To get around the CORS issue, I set up an onrequest hook, which points +>>>to the function: +>>> +>>> set_request_cors(Req) -> +>>> Req2 = +>>>cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, +>>>POST, OPTIONS">>, Req), +>>> Req3 = +>>>cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, +>>><<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, +>>><<"*">>, Req3). +>>> +>>> I'm afraid I don't have any more info, but this issue is completely +>>>eluding me. +>>> +>>> Thanks, +>>> Lee +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +> +> + + + + +From lee.sylvester at gmail.com Mon Apr 22 20:30:08 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Mon, 22 Apr 2013 19:30:08 +0100 +Subject: [99s-extend] 505 error +In-Reply-To: +References: +Message-ID: <5826B1C1-C80E-4073-953C-3BF74829CE1A@gmail.com> + +Does this help? + +Request URL:http://www.example.com +Request Method:OPTIONS +Status Code:505 HTTP Version Not Supported + +Request Headersview parsed +OPTIONS http://www.example.com HTTP/1.1 +Host: www.example.com +Proxy-Connection: keep-alive +Access-Control-Request-Method: POST +Origin: http://localhost +User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +Access-Control-Request-Headers: origin, method, content-type +Accept: */* +Referer: http://localhost/p/ +Accept-Encoding: gzip,deflate,sdch +Accept-Language: en-US,en;q=0.8 +Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 + +Response Headersview parsed +HTTP/1.1 505 HTTP Version Not Supported +connection: close +server: Cowboy +date: Mon, 22 Apr 2013 17:42:39 GMT +content-length: 0 + +Thanks, +Lee + + +On 22 Apr 2013, at 16:55, "Brown, Kevin" wrote: + +> You might see if "view source" (rather than the parsed view you sent) +> yields any clues. You'd like to see HTTP version being sent. +> +> +> On 4/22/13 10:40 AM, "Lee Sylvester" wrote: +> +>> Well, the below is the sent and return headers on the failing machine. +>> On a succeeding machine, the headers are +>> +>> Request URL:http://www.example.com +>> Request Method:OPTIONS +>> Status Code:200 OK +>> +>> Request Headersview source +>> Accept:*/* +>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>> Accept-Encoding:gzip,deflate,sdch +>> Accept-Language:en-US,en;q=0.8 +>> Access-Control-Request-Headers:origin, method, content-type +>> Access-Control-Request-Method:POST +>> Connection:keep-alive +>> Host:www.example.com +>> Origin:http://www.test.com +>> Referer:http://www.test.com/ +>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) +>> AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +>> +>> Response Headersview source +>> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, +>> Method +>> Access-Control-Allow-Methods:GET, POST, OPTIONS +>> Access-Control-Allow-Origin:* +>> connection:keep-alive +>> content-length:68 +>> date:Mon, 22 Apr 2013 14:33:30 GMT +>> server:Cowboy +>> +>> As you can see, the header control and content isn't being sent back and +>> the connection is closed. +>> +>> Thanks, +>> Lee +>> +>> +>> +>> +>> On 22 Apr 2013, at 15:28, "Brown, Kevin" wrote: +>> +>>> What is the exact http request sent on the failing and successful +>>> machines? How do the differ? +>>> +>>> Stack trace? +>>> +>>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" +>>> wrote: +>>> +>>>> Hi guys, +>>>> +>>>> So, I was getting a CORS issue when connecting to my Bullet impl, +>>>> which I have since fixed. I am now able to use these from many +>>>> machines from many locations. However, I have found some machines to +>>>> be getting a 505 error when making a POST request to the Cowboy +>>>> instance: +>>>> +>>>> Request URL:http://www.example.com +>>>> Request Method:OPTIONS +>>>> Status Code:505 HTTP Version Not Supported +>>>> +>>>> Request Headersview source +>>>> Accept:*/* +>>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>>>> Accept-Encoding:gzip,deflate,sdch +>>>> Accept-Language:en-US,en;q=0.8 +>>>> Access-Control-Request-Headers:origin, method, content-type +>>>> Access-Control-Request-Method:POST +>>>> Connection:keep-alive +>>>> Host:www.example.com +>>>> Origin:http://www.test.com +>>>> Referer:http://www.test.com/ +>>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 +>>>> (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +>>>> +>>>> Response Headersview source +>>>> connection:close +>>>> content-length:0 +>>>> date:Mon, 22 Apr 2013 12:22:50 GMT +>>>> server:Cowboy +>>>> +>>>> To get around the CORS issue, I set up an onrequest hook, which points +>>>> to the function: +>>>> +>>>> set_request_cors(Req) -> +>>>> Req2 = +>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, +>>>> POST, OPTIONS">>, Req), +>>>> Req3 = +>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, +>>>> <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, +>>>> <<"*">>, Req3). +>>>> +>>>> I'm afraid I don't have any more info, but this issue is completely +>>>> eluding me. +>>>> +>>>> Thanks, +>>>> Lee +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>> +>>> +>> +>> +> +> + + + +From essen at ninenines.eu Mon Apr 22 21:19:39 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 22 Apr 2013 21:19:39 +0200 +Subject: [99s-extend] 505 error +In-Reply-To: <5826B1C1-C80E-4073-953C-3BF74829CE1A@gmail.com> +References: + <5826B1C1-C80E-4073-953C-3BF74829CE1A@gmail.com> +Message-ID: <51758D4B.1020501@ninenines.eu> + +I'm going to need the exact request line to make sense of it. +Something's missing in the parser I think, not sure what in your case +though. Feel free to private email it. + +On 04/22/2013 08:30 PM, Lee Sylvester wrote: +> Does this help? +> +> Request URL:http://www.example.com +> Request Method:OPTIONS +> Status Code:505 HTTP Version Not Supported +> +> Request Headersview parsed +> OPTIONS http://www.example.com HTTP/1.1 +> Host: www.example.com +> Proxy-Connection: keep-alive +> Access-Control-Request-Method: POST +> Origin: http://localhost +> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +> Access-Control-Request-Headers: origin, method, content-type +> Accept: */* +> Referer: http://localhost/p/ +> Accept-Encoding: gzip,deflate,sdch +> Accept-Language: en-US,en;q=0.8 +> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 +> +> Response Headersview parsed +> HTTP/1.1 505 HTTP Version Not Supported +> connection: close +> server: Cowboy +> date: Mon, 22 Apr 2013 17:42:39 GMT +> content-length: 0 +> +> Thanks, +> Lee +> +> +> On 22 Apr 2013, at 16:55, "Brown, Kevin" wrote: +> +>> You might see if "view source" (rather than the parsed view you sent) +>> yields any clues. You'd like to see HTTP version being sent. +>> +>> +>> On 4/22/13 10:40 AM, "Lee Sylvester" wrote: +>> +>>> Well, the below is the sent and return headers on the failing machine. +>>> On a succeeding machine, the headers are +>>> +>>> Request URL:http://www.example.com +>>> Request Method:OPTIONS +>>> Status Code:200 OK +>>> +>>> Request Headersview source +>>> Accept:*/* +>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>>> Accept-Encoding:gzip,deflate,sdch +>>> Accept-Language:en-US,en;q=0.8 +>>> Access-Control-Request-Headers:origin, method, content-type +>>> Access-Control-Request-Method:POST +>>> Connection:keep-alive +>>> Host:www.example.com +>>> Origin:http://www.test.com +>>> Referer:http://www.test.com/ +>>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) +>>> AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 +>>> +>>> Response Headersview source +>>> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, +>>> Method +>>> Access-Control-Allow-Methods:GET, POST, OPTIONS +>>> Access-Control-Allow-Origin:* +>>> connection:keep-alive +>>> content-length:68 +>>> date:Mon, 22 Apr 2013 14:33:30 GMT +>>> server:Cowboy +>>> +>>> As you can see, the header control and content isn't being sent back and +>>> the connection is closed. +>>> +>>> Thanks, +>>> Lee +>>> +>>> +>>> +>>> +>>> On 22 Apr 2013, at 15:28, "Brown, Kevin" wrote: +>>> +>>>> What is the exact http request sent on the failing and successful +>>>> machines? How do the differ? +>>>> +>>>> Stack trace? +>>>> +>>>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" +>>>> wrote: +>>>> +>>>>> Hi guys, +>>>>> +>>>>> So, I was getting a CORS issue when connecting to my Bullet impl, +>>>>> which I have since fixed. I am now able to use these from many +>>>>> machines from many locations. However, I have found some machines to +>>>>> be getting a 505 error when making a POST request to the Cowboy +>>>>> instance: +>>>>> +>>>>> Request URL:http://www.example.com +>>>>> Request Method:OPTIONS +>>>>> Status Code:505 HTTP Version Not Supported +>>>>> +>>>>> Request Headersview source +>>>>> Accept:*/* +>>>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 +>>>>> Accept-Encoding:gzip,deflate,sdch +>>>>> Accept-Language:en-US,en;q=0.8 +>>>>> Access-Control-Request-Headers:origin, method, content-type +>>>>> Access-Control-Request-Method:POST +>>>>> Connection:keep-alive +>>>>> Host:www.example.com +>>>>> Origin:http://www.test.com +>>>>> Referer:http://www.test.com/ +>>>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 +>>>>> (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31 +>>>>> +>>>>> Response Headersview source +>>>>> connection:close +>>>>> content-length:0 +>>>>> date:Mon, 22 Apr 2013 12:22:50 GMT +>>>>> server:Cowboy +>>>>> +>>>>> To get around the CORS issue, I set up an onrequest hook, which points +>>>>> to the function: +>>>>> +>>>>> set_request_cors(Req) -> +>>>>> Req2 = +>>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, +>>>>> POST, OPTIONS">>, Req), +>>>>> Req3 = +>>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, +>>>>> <<"Content-Type, X-Requested-With, Origin, Method">>, Req2), +>>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, +>>>>> <<"*">>, Req3). +>>>>> +>>>>> I'm afraid I don't have any more info, but this issue is completely +>>>>> eluding me. +>>>>> +>>>>> Thanks, +>>>>> Lee +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>>> +>>>> +>>> +>>> +>> +>> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From yongboy at gmail.com Thu Apr 25 05:46:24 2013 +From: yongboy at gmail.com (yongboy) +Date: Thu, 25 Apr 2013 11:46:24 +0800 +Subject: [99s-extend] does cowboy support hot code reload/replace ? +Message-ID: + +You know, the OTP's code_change so heavy, sometimes, you just want to +debug, or change a little, does not want to rewrite the rel appup file. +Any help is appreciated, thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Apr 25 13:42:15 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 25 Apr 2013 13:42:15 +0200 +Subject: [99s-extend] does cowboy support hot code reload/replace ? +In-Reply-To: +References: +Message-ID: <51791697.7030500@ninenines.eu> + +On 04/25/2013 05:46 AM, yongboy wrote: +> You know, the OTP's code_change so heavy, sometimes, you just want to +> debug, or change a little, does not want to rewrite the rel appup file. +> Any help is appreciated, thanks. + +At this time there is no code_change mechanism in Cowboy. Reloading a +module works, modifying the protocol options with +ranch:set_protocol_options can be used, but it doesn't change the +running processes. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From yongboy at gmail.com Fri Apr 26 07:57:00 2013 +From: yongboy at gmail.com (yongboy) +Date: Fri, 26 Apr 2013 13:57:00 +0800 +Subject: [99s-extend] does cowboy support hot code reload/replace ? +In-Reply-To: <51791697.7030500@ninenines.eu> +References: + <51791697.7030500@ninenines.eu> +Message-ID: + +Thanks very much ! +Maybe we can use the code:load_file() function I had just found it . + + +2013/4/25 Lo?c Hoguin + +> On 04/25/2013 05:46 AM, yongboy wrote: +> +>> You know, the OTP's code_change so heavy, sometimes, you just want to +>> debug, or change a little, does not want to rewrite the rel appup file. +>> Any help is appreciated, thanks. +>> +> +> At this time there is no code_change mechanism in Cowboy. Reloading a +> module works, modifying the protocol options with +> ranch:set_protocol_options can be used, but it doesn't change the running +> processes. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From yongboy at gmail.com Fri Apr 26 08:11:56 2013 +From: yongboy at gmail.com (yongboy) +Date: Fri, 26 Apr 2013 14:11:56 +0800 +Subject: [99s-extend] cowboy how to ruduce the memory usage per long-hold + connection +Message-ID: + +I have tested one long-hold webapp, when 512000 user connected, the app +used +6801M memory, 6801M*1024K / 512000 = 13.6K/Connection. + +Does anyone give me some advice on how to reduce the memory usage per one +connection, thanks very much ! + +Here is the code snippet: + +start(_Type, _Args) -> + Dispatch = cowboy_router:compile([ + {'_', [{'_', htmlfile_handler, []}]} + ]), + cowboy:start_http(my_http_listener, 100, + [{port, 8000}, {max_connections, infinity}], + [{env, [{dispatch, Dispatch}]}] + ), + count_server:start(), + htmlfilesimple_sup:start_link(). + +...... + +-module(htmlfile_handler). +-behaviour(cowboy_loop_handler). +-export([init/3, info/3, terminate/3]). +-define(HEARBEAT_TIMEOUT, 20*1000). +-record(status, {count=0}). + +init(_Any, Req, State) -> + NowCount = count_server:welcome(), + io:format("online user ~p :))~n", [NowCount]), + + output_first(Req), + Req2 = cowboy_req:compact(Req), + {loop, Req2, State, hibernate}. + +%% POST/Short Request +info(_Any, Req, State) -> + {loop, Req, State, hibernate}. + +output_first(Req) -> + {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>, +<<"text/html; charset=utf-8">>}, + +{<<"Connection">>, <<"keep-alive">>}], Req), + cowboy_req:chunk(<<" +">>, + Reply), + cowboy_req:chunk(gen_output("1::"), Reply). + +gen_output(String) -> + DescList = io_lib:format("", [String]), + list_to_binary(DescList). + +terminate(Reason, _Req, _State) -> + NowCount = count_server:bye(), + io:format("offline user ~p :(( ~n", [NowCount]). +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From erlang at rambocoder.com Fri Apr 26 15:11:53 2013 +From: erlang at rambocoder.com (rambocoder) +Date: Fri, 26 Apr 2013 09:11:53 -0400 +Subject: [99s-extend] cowboy how to ruduce the memory usage per + long-hold connection +In-Reply-To: +References: +Message-ID: + +Is 13.6K/connection considered a lot? Once you start doing SSL, each +connection will be about 80K, IMHO the most important factor for huge +ammount of COMET users is latency, which Cowboy and Erlang do great. + +-rambocoder + +On Fri, Apr 26, 2013 at 2:11 AM, yongboy wrote: + +> I have tested one long-hold webapp, when 512000 user connected, the app +> used +> 6801M memory, 6801M*1024K / 512000 = 13.6K/Connection. +> +> Does anyone give me some advice on how to reduce the memory usage per one +> connection, thanks very much ! +> +> Here is the code snippet: +> +> start(_Type, _Args) -> +> Dispatch = cowboy_router:compile([ +> {'_', [{'_', htmlfile_handler, []}]} +> ]), +> cowboy:start_http(my_http_listener, 100, +> [{port, 8000}, {max_connections, infinity}], +> [{env, [{dispatch, Dispatch}]}] +> ), +> count_server:start(), +> htmlfilesimple_sup:start_link(). +> +> ...... +> +> -module(htmlfile_handler). +> -behaviour(cowboy_loop_handler). +> -export([init/3, info/3, terminate/3]). +> -define(HEARBEAT_TIMEOUT, 20*1000). +> -record(status, {count=0}). +> +> init(_Any, Req, State) -> +> NowCount = count_server:welcome(), +> io:format("online user ~p :))~n", [NowCount]), +> +> output_first(Req), +> Req2 = cowboy_req:compact(Req), +> {loop, Req2, State, hibernate}. +> +> %% POST/Short Request +> info(_Any, Req, State) -> +> {loop, Req, State, hibernate}. +> +> output_first(Req) -> +> {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>, +> <<"text/html; charset=utf-8">>}, +> +> {<<"Connection">>, <<"keep-alive">>}], Req), +> cowboy_req:chunk(<<" +> ">>, +> Reply), +> cowboy_req:chunk(gen_output("1::"), Reply). +> +> gen_output(String) -> +> DescList = io_lib:format("", [String]), +> list_to_binary(DescList). +> +> terminate(Reason, _Req, _State) -> +> NowCount = count_server:bye(), +> io:format("offline user ~p :(( ~n", [NowCount]). +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Apr 26 17:21:32 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 26 Apr 2013 17:21:32 +0200 +Subject: [99s-extend] [ANN] Cowboy 0.8.4 +Message-ID: <517A9B7C.8090706@ninenines.eu> + +Hello, + +Cowboy 0.8.4 has been released! + +This release features a tentatively stable API. This means that the +complete API defined in this release should not change anymore. The API +will be augmented with many features and functions of course, but +existing code should not break anymore. Changes will only be considered +if a feature causes bugs or too much confusion to the majority of users. + +This release includes all the remaining changes that had to be done to +REST, which is now no longer experimental and has documentation that you +can find here: + + http://ninenines.eu/docs/en/cowboy/HEAD/guide/rest_handlers + +Diagrams and their explanations will be added to the documentation in +the next few days. + +The full changelog for this release can be found here: +https://github.com/extend/cowboy/commit/46b2ea0aaa7fe891bfdf3f8a0c47357393e72cf6 + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From gdesouza at gmail.com Tue Apr 30 20:59:21 2013 +From: gdesouza at gmail.com (Gregory de Souza) +Date: Tue, 30 Apr 2013 14:59:21 -0400 +Subject: [99s-extend] cowboy websocket and wamp +Message-ID: + +Hi, +I'm new to the community and am exploring cowboy for a project. + +Can anyone offer guidance/links on how to use cowboy's websocket support +with WAMP (http://wamp.ws/)? +The cowboy docs mention bullet as +a convenient client/server lib (with an AJAX fallback) which is great, but +I'd like to use WAMP's RPC and PubSub so I'm unsure how to proceed. + +Any tips would be appreciated! + +Thanks in advance +-- +Gregory | @gdesouza | http://blog.gdesouza.me +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-April/000073.html b/_build/static/archives/extend/2013-April/000073.html new file mode 100644 index 00000000..ce854d84 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000073.html @@ -0,0 +1,82 @@ + + + + [99s-extend] [ANN] Ranch 0.8.0 + + + + + + + + + + +

[99s-extend] [ANN] Ranch 0.8.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Apr 2 19:23:28 CEST 2013 +

+
+ +
Just released!
+
+We have greatly improved the performance of Ranch both for accepting 
+connections and when they get disconnected. Stability has also been much 
+improved thanks to many community provided tests.
+
+Small API changes. Sorry!
+
+  *  ListenerPid argument to Protocol:start_link/4 became Ref
+  *  as a result it's now ranch:accept_ack(Ref)
+  *  ranch_listener:remove_connection(ListenerPid) became 
+ranch:remove_connection(Ref)
+
+Unless you used ranch_listener_remove_connection/1 your old code should 
+still work without any changes.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000074.html b/_build/static/archives/extend/2013-April/000074.html new file mode 100644 index 00000000..4618e32d --- /dev/null +++ b/_build/static/archives/extend/2013-April/000074.html @@ -0,0 +1,78 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.3 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.3

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 3 17:21:16 CEST 2013 +

+
+ +
Hello!
+
+Very small release just to update Ranch to 0.8.0 (faster!) and change 
+something about streaming the body. Newly introduced init_stream/5 
+proved to be a bad idea and got removed in favor of a new stream_body/2 
+which allows specifying the maximum chunk size you want on a per chunk 
+basis.
+
+   https://github.com/extend/cowboy
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000075.html b/_build/static/archives/extend/2013-April/000075.html new file mode 100644 index 00000000..3441177d --- /dev/null +++ b/_build/static/archives/extend/2013-April/000075.html @@ -0,0 +1,66 @@ + + + + [99s-extend] Response headers + + + + + + + + + + +

[99s-extend] Response headers

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Apr 3 21:33:20 CEST 2013 +

+
+ +
Hi list,
+
+I'd like to set up my handler to use CORS.  Can anyone tell me how I can modify the headers for my handler to support this?
+
+Thanks loads,
+Lee
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000076.html b/_build/static/archives/extend/2013-April/000076.html new file mode 100644 index 00000000..243e1929 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000076.html @@ -0,0 +1,196 @@ + + + + [99s-extend] Response headers + + + + + + + + + + +

[99s-extend] Response headers

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Wed Apr 3 22:35:36 CEST 2013 +

+
+ +
+  Sure. Right now, Cowboy doesn't parse the headers, but you can manually
+parse them in your handler. I've got them working in my implementation
+pretty well, I'll try and break it down a bit here.
+
+  A good, basic overview of what the requests the browser will send, and
+what your responses should look like, is here:
+https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
+
+
+
+HANDLING PRE-FLIGHTS -
+  Pre-flights are the OPTION requests the browser automatically sends off
+when you make a CORS request using a verb other than GET, or POST with one
+of three acceptable content types. They're defined well in the above link.
+
+  You can read off the requested headers the actual call wants to send in
+the OPTIONS preflight with
+
+	{Headers, NewRequest } =
+cowboy_req:header(<<"access-control-request-headers">>, Request)
+
+  Headers will either be the binary, or undefined. If the binary, you
+either need to manually parse it and choose to allow/disallow the request
+from continuing based on it, or, if you just want to allow all headers
+trivially, just pipe that back into the request, a la -
+
+        Request2 = 
+cowboy_req:set_resp_header(<<"access-control-allow-headers">>,
+binary_to_list(Headers), NewRequest)
+
+  (As a reminder, it can be undefined. You'll need to check for that
+before passing it into the above. If it's undefined, you don't need to add
+the access-control-allow-headers header).
+
+
+
+  As part of the pre-flight request, you also need to handle what methods
+are allowed. This looks something like -
+
+	PreflightedRequest =
+cowboy_req:set_resp_header(<<"access-control-allow-methods">>, <<"GET,
+POST, DELETE, PUT">>, Request2)
+
+  If I wanted to allow gets, posts, deletes, and puts. You can also choose
+to read off the access-control-request-method header sent from the client,
+but I don't see the point; your list of allowed methods doesn't need to
+change based on that (the user is requesting a POST, why does that change
+whether you allow a POST or not? But I digress).
+
+
+
+
+
+FOR ALL CALLS (both pre-flights and the actual call)
+  Respond with acceptable origin. If you want any domain to access this
+resource (not advised, unless this is a public, readonly resource, but
+good for testing), you can do -
+
+  	NewRequest = 
+cowboy_req:set_resp_header(<<"access-control-allow-origin">>, <<"*">>,
+Request)
+
+
+  If you want to filter out the allowed domains, it looks like -
+
+	Origin = cowboy_req:header(<<"origin">>, Request) %Get the origin that
+the browser sent you
+
+        %Do logic to check Origin, and any other data that would decide
+whether this request is allowed; it will only apply on a CORS request from
+another browser.
+        
+	%If it passes, pass Origin back as the value for the
+access-control-allow-origin header.
+        NewRequest =
+cowboy_req:set_resp_header(<<"access-control-allow-origin">>, Origin,
+Request)
+
+
+
+FOR ONLY THE ACTUAL CALL
+  If you want to send custom headers back to your Javascript client (or
+read any standard header beyond content-type), you need to explicitly
+allow them. This looks like (if I wanted to expose the 'server' header so
+my client Javascript can see that it's Cowboy on the backend) -
+
+  	ExposedHeaderRequest =
+cowboy_req:set_resp_header(<<"access-control-expose-headers">>,
+<<"server">>, Request)
+
+
+
+
+  That's basically it I believe. There is also a max age, and a allow
+credentials header (which is really more of a require credentials);
+they're pretty straightforwardly explained on that page I linked above,
+but I haven't played with them personally.
+
+
+  Caveats I ran into were largely being aware that same domain requests do
+NOT supply any of the CORS headers, not even the origin header (so you can
+get undefined and have to handle those cases), as well as understanding
+the ramifications of allowing cross domain requests. Also, if you want to
+develop while disconnected (or if it's not easy to grab another domain),
+use your hosts file to declare a fake domain pointed to 127.0.0.1, load
+your page from that, explicitly define your AJAX calls to localhost. Note
+too that there is a bug in Firefox at present when you try and get all the
+request headers. It returns an empty list. You can get individual ones if
+you know the name (I.e., getResponseHeader("server") will work,
+getAllResponseHeaders() returns an empty string). This is further
+compounded by jQuery building its own XHR that loads headers by calling
+getAllResponseHeaders, so in Firefox, using jQuery, you can get back zero
+headers. Don't know if that affects you, but it's an issue it took me a
+good while to diagnose, and which we've had to bear in mind.
+
+
+
+   
+On 4/3/13 3:33 PM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+
+>Hi list,
+>
+>I'd like to set up my handler to use CORS.  Can anyone tell me how I can
+>modify the headers for my handler to support this?
+>
+>Thanks loads,
+>Lee
+>_______________________________________________
+>Extend mailing list
+>Extend at lists.ninenines.eu
+>http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000077.html b/_build/static/archives/extend/2013-April/000077.html new file mode 100644 index 00000000..1bbf7ad2 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000077.html @@ -0,0 +1,213 @@ + + + + [99s-extend] Response headers + + + + + + + + + + +

[99s-extend] Response headers

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 4 10:38:07 CEST 2013 +

+
+ +
Hi Christopher,
+
+Thank you for that.  I will attempt to go through each piece today and solve the problem.  This is good advice; maybe it belongs in a blog post?  :-)
+
+Thanks again,
+Lee
+
+
+
+
+On 3 Apr 2013, at 21:35, "Phillips, Christopher" <Christopher.Phillips at turner.com> wrote:
+
+> 
+>  Sure. Right now, Cowboy doesn't parse the headers, but you can manually
+> parse them in your handler. I've got them working in my implementation
+> pretty well, I'll try and break it down a bit here.
+> 
+>  A good, basic overview of what the requests the browser will send, and
+> what your responses should look like, is here:
+> https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS
+> 
+> 
+> 
+> HANDLING PRE-FLIGHTS -
+>  Pre-flights are the OPTION requests the browser automatically sends off
+> when you make a CORS request using a verb other than GET, or POST with one
+> of three acceptable content types. They're defined well in the above link.
+> 
+>  You can read off the requested headers the actual call wants to send in
+> the OPTIONS preflight with
+> 
+> 	{Headers, NewRequest } =
+> cowboy_req:header(<<"access-control-request-headers">>, Request)
+> 
+>  Headers will either be the binary, or undefined. If the binary, you
+> either need to manually parse it and choose to allow/disallow the request
+> from continuing based on it, or, if you just want to allow all headers
+> trivially, just pipe that back into the request, a la -
+> 
+>        Request2 = 
+> cowboy_req:set_resp_header(<<"access-control-allow-headers">>,
+> binary_to_list(Headers), NewRequest)
+> 
+>  (As a reminder, it can be undefined. You'll need to check for that
+> before passing it into the above. If it's undefined, you don't need to add
+> the access-control-allow-headers header).
+> 
+> 
+> 
+>  As part of the pre-flight request, you also need to handle what methods
+> are allowed. This looks something like -
+> 
+> 	PreflightedRequest =
+> cowboy_req:set_resp_header(<<"access-control-allow-methods">>, <<"GET,
+> POST, DELETE, PUT">>, Request2)
+> 
+>  If I wanted to allow gets, posts, deletes, and puts. You can also choose
+> to read off the access-control-request-method header sent from the client,
+> but I don't see the point; your list of allowed methods doesn't need to
+> change based on that (the user is requesting a POST, why does that change
+> whether you allow a POST or not? But I digress).
+> 
+> 
+> 
+> 
+> 
+> FOR ALL CALLS (both pre-flights and the actual call)
+>  Respond with acceptable origin. If you want any domain to access this
+> resource (not advised, unless this is a public, readonly resource, but
+> good for testing), you can do -
+> 
+>  	NewRequest = 
+> cowboy_req:set_resp_header(<<"access-control-allow-origin">>, <<"*">>,
+> Request)
+> 
+> 
+>  If you want to filter out the allowed domains, it looks like -
+> 
+> 	Origin = cowboy_req:header(<<"origin">>, Request) %Get the origin that
+> the browser sent you
+> 
+>        %Do logic to check Origin, and any other data that would decide
+> whether this request is allowed; it will only apply on a CORS request from
+> another browser.
+> 
+> 	%If it passes, pass Origin back as the value for the
+> access-control-allow-origin header.
+>        NewRequest =
+> cowboy_req:set_resp_header(<<"access-control-allow-origin">>, Origin,
+> Request)
+> 
+> 
+> 
+> FOR ONLY THE ACTUAL CALL
+>  If you want to send custom headers back to your Javascript client (or
+> read any standard header beyond content-type), you need to explicitly
+> allow them. This looks like (if I wanted to expose the 'server' header so
+> my client Javascript can see that it's Cowboy on the backend) -
+> 
+>  	ExposedHeaderRequest =
+> cowboy_req:set_resp_header(<<"access-control-expose-headers">>,
+> <<"server">>, Request)
+> 
+> 
+> 
+> 
+>  That's basically it I believe. There is also a max age, and a allow
+> credentials header (which is really more of a require credentials);
+> they're pretty straightforwardly explained on that page I linked above,
+> but I haven't played with them personally.
+> 
+> 
+>  Caveats I ran into were largely being aware that same domain requests do
+> NOT supply any of the CORS headers, not even the origin header (so you can
+> get undefined and have to handle those cases), as well as understanding
+> the ramifications of allowing cross domain requests. Also, if you want to
+> develop while disconnected (or if it's not easy to grab another domain),
+> use your hosts file to declare a fake domain pointed to 127.0.0.1, load
+> your page from that, explicitly define your AJAX calls to localhost. Note
+> too that there is a bug in Firefox at present when you try and get all the
+> request headers. It returns an empty list. You can get individual ones if
+> you know the name (I.e., getResponseHeader("server") will work,
+> getAllResponseHeaders() returns an empty string). This is further
+> compounded by jQuery building its own XHR that loads headers by calling
+> getAllResponseHeaders, so in Firefox, using jQuery, you can get back zero
+> headers. Don't know if that affects you, but it's an issue it took me a
+> good while to diagnose, and which we've had to bear in mind.
+> 
+> 
+> 
+> 
+> On 4/3/13 3:33 PM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+> 
+>> Hi list,
+>> 
+>> I'd like to set up my handler to use CORS.  Can anyone tell me how I can
+>> modify the headers for my handler to support this?
+>> 
+>> Thanks loads,
+>> Lee
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+> 
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000078.html b/_build/static/archives/extend/2013-April/000078.html new file mode 100644 index 00000000..03f7f5d0 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000078.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Bullet connection + + + + + + + + + + +

[99s-extend] Bullet connection

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 4 22:17:54 CEST 2013 +

+
+ +
Hi guys,
+
+So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT.  The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations".
+
+Does anyone know how I fix this to get past this problem?
+
+Thanks,
+Lee
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000079.html b/_build/static/archives/extend/2013-April/000079.html new file mode 100644 index 00000000..c44417d0 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000079.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Bullet connection + + + + + + + + + + +

[99s-extend] Bullet connection

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Apr 4 22:39:32 CEST 2013 +

+
+ +
On 04/04/2013 10:17 PM, Lee Sylvester wrote:
+> Hi guys,
+>
+> So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT.  The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations".
+>
+> Does anyone know how I fix this to get past this problem?
+
+You should probably disable the proxy you have configured in your 
+browser for the domain localhost.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000080.html b/_build/static/archives/extend/2013-April/000080.html new file mode 100644 index 00000000..ed41aaf8 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000080.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Bullet connection + + + + + + + + + + +

[99s-extend] Bullet connection

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 4 22:54:54 CEST 2013 +

+
+ +
D'oh!  I'm obviously tired :(  Thanks for that.  I saw the message and instantly assumed it was a Cowboy related error.  Okay, so I got that fixed.  Now I need to work out why my connections close the instant they're open :-D  Oh, the life of a developer!
+
+Thanks again.
+
+Lee
+
+
+
+
+On 4 Apr 2013, at 21:39, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 04/04/2013 10:17 PM, Lee Sylvester wrote:
+>> Hi guys,
+>> 
+>> So, I'm using bullet in my Cowboy setup. There's a lot of tasks that take place before a connection is finally requested, but when it is requested, I see that the server is first called via HTTPS using method CONNECT.  The problem I have is that, while testing this on local host, this CONNECT request is throwing a 500 error, stating "SSL Proxying not enabled for this host: enable in Proxy Settings, SSL locations".
+>> 
+>> Does anyone know how I fix this to get past this problem?
+> 
+> You should probably disable the proxy you have configured in your browser for the domain localhost.
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000081.html b/_build/static/archives/extend/2013-April/000081.html new file mode 100644 index 00000000..a19b56a9 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000081.html @@ -0,0 +1,156 @@ + + + + [99s-extend] Problems with Bullet + + + + + + + + + + +

[99s-extend] Problems with Bullet

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Mon Apr 8 15:53:38 CEST 2013 +

+
+ +
Hi all,
+
+I'm currently having problems getting a websocket to connect to a simple bare bones Bullet handler.  Unfortunately, I'm still quite an Erlang noob, so the stack traces tend to lead me in circles.  I'm hoping this is obvious stuff to you Erlang pros :-)
+
+Given the below handler:
+
+init(_Transport, Req, _Opts, _Active) ->
+	{ok, Req, undefined_state}.
+
+stream(Data, Req, State) ->
+	{ok, Req, State}.
+
+info(Info, Req, State) ->
+	{reply, Info, Req, State}.
+	
+terminate(_Req, _State) ->
+	ok.
+
+Connecting with a websocket throws the following error:
+
+=ERROR REPORT==== 8-Apr-2013::14:46:11 ===
+** Cowboy handler bullet_handler terminating in init/3
+   for the reason error:undef
+** Options were [{handler,connection_handler}]
+** Request was [{socket,#Port<0.926>},
+                {transport,ranch_tcp},
+                {connection,keepalive},
+                {pid,<0.491.0>},
+                {method,<<"GET">>},
+                {version,{1,1}},
+                {peer,{{127,0,0,1},56630}},
+                {host,<<"localhost">>},
+                {host_info,undefined},
+                {port,8080},
+                {path,<<"/">>},
+                {path_info,undefined},
+                {qs,<<"encoding=text">>},
+                {qs_vals,undefined},
+                {fragment,<<>>},
+                {bindings,[]},
+                {headers,[{<<"upgrade">>,<<"websocket">>},
+                          {<<"connection">>,<<"Upgrade">>},
+                          {<<"host">>,<<"localhost:8080">>},
+                          {<<"origin">>,<<"http://www.websocket.org">>},
+                          {<<"pragma">>,<<"no-cache">>},
+                          {<<"cache-control">>,<<"no-cache">>},
+                          {<<"sec-websocket-key">>,
+                           <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+                          {<<"sec-websocket-version">>,<<"13">>},
+                          {<<"sec-websocket-extensions">>,
+                           <<"x-webkit-deflate-frame">>}]},
+                {p_headers,[{<<"connection">>,[<<"upgrade">>]}]},
+                {cookies,undefined},
+                {meta,[]},
+                {body_state,waiting},
+                {multipart,undefined},
+                {buffer,<<>>},
+                {resp_compress,false},
+                {resp_state,waiting},
+                {resp_headers,[]},
+                {resp_body,<<>>},
+                {onresponse,undefined}]
+** Stacktrace: [{bullet_handler,init,
+                    [{tcp,http},
+                     {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>,
+                         <<"GET">>,
+                         {1,1},
+                         {{127,0,0,1},56630},
+                         <<"localhost">>,undefined,8080,<<"/">>,
+                         undefined,<<"encoding=text">>,undefined,<<>>,
+                         [],
+                         [{<<"upgrade">>,<<"websocket">>},
+                          {<<"connection">>,<<"Upgrade">>},
+                          {<<"host">>,<<"localhost:8080">>},
+                          {<<"origin">>,<<"http://www.websocket.org">>},
+                          {<<"pragma">>,<<"no-cache">>},
+                          {<<"cache-control">>,<<"no-cache">>},
+                          {<<"sec-websocket-key">>,
+                           <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+                          {<<"sec-websocket-version">>,<<"13">>},
+                          {<<"sec-websocket-extensions">>,
+                           <<"x-webkit-deflate-frame">>}],
+                         [{<<"connection">>,[<<"upgrade">>]}],
+                         undefined,[],waiting,undefined,<<>>,false,waiting,[],
+                         <<>>,undefined},
+                     [{handler,connection_handler}]],
+                    []},
+                {cowboy_handler,handler_init,4,
+                    [{file,"src/cowboy_handler.erl"},{line,69}]},
+                {cowboy_protocol,execute,4,
+                    [{file,"src/cowboy_protocol.erl"},{line,514}]}]
+
+Can anyone see what might be throwing this off?  I'd like to get a minimal handler running before I attempt to add some logic.
+
+Thanks,
+Lee
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000082.html b/_build/static/archives/extend/2013-April/000082.html new file mode 100644 index 00000000..6c776c44 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000082.html @@ -0,0 +1,172 @@ + + + + [99s-extend] Problems with Bullet + + + + + + + + + + +

[99s-extend] Problems with Bullet

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Apr 8 16:08:31 CEST 2013 +

+
+ +
Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin?
+
+On 04/08/2013 03:53 PM, Lee Sylvester wrote:
+> Hi all,
+>
+> I'm currently having problems getting a websocket to connect to a simple bare bones Bullet handler.  Unfortunately, I'm still quite an Erlang noob, so the stack traces tend to lead me in circles.  I'm hoping this is obvious stuff to you Erlang pros :-)
+>
+> Given the below handler:
+>
+> init(_Transport, Req, _Opts, _Active) ->
+> 	{ok, Req, undefined_state}.
+>
+> stream(Data, Req, State) ->
+> 	{ok, Req, State}.
+>
+> info(Info, Req, State) ->
+> 	{reply, Info, Req, State}.
+> 	
+> terminate(_Req, _State) ->
+> 	ok.
+>
+> Connecting with a websocket throws the following error:
+>
+> =ERROR REPORT==== 8-Apr-2013::14:46:11 ===
+> ** Cowboy handler bullet_handler terminating in init/3
+>     for the reason error:undef
+> ** Options were [{handler,connection_handler}]
+> ** Request was [{socket,#Port<0.926>},
+>                  {transport,ranch_tcp},
+>                  {connection,keepalive},
+>                  {pid,<0.491.0>},
+>                  {method,<<"GET">>},
+>                  {version,{1,1}},
+>                  {peer,{{127,0,0,1},56630}},
+>                  {host,<<"localhost">>},
+>                  {host_info,undefined},
+>                  {port,8080},
+>                  {path,<<"/">>},
+>                  {path_info,undefined},
+>                  {qs,<<"encoding=text">>},
+>                  {qs_vals,undefined},
+>                  {fragment,<<>>},
+>                  {bindings,[]},
+>                  {headers,[{<<"upgrade">>,<<"websocket">>},
+>                            {<<"connection">>,<<"Upgrade">>},
+>                            {<<"host">>,<<"localhost:8080">>},
+>                            {<<"origin">>,<<"http://www.websocket.org">>},
+>                            {<<"pragma">>,<<"no-cache">>},
+>                            {<<"cache-control">>,<<"no-cache">>},
+>                            {<<"sec-websocket-key">>,
+>                             <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>                            {<<"sec-websocket-version">>,<<"13">>},
+>                            {<<"sec-websocket-extensions">>,
+>                             <<"x-webkit-deflate-frame">>}]},
+>                  {p_headers,[{<<"connection">>,[<<"upgrade">>]}]},
+>                  {cookies,undefined},
+>                  {meta,[]},
+>                  {body_state,waiting},
+>                  {multipart,undefined},
+>                  {buffer,<<>>},
+>                  {resp_compress,false},
+>                  {resp_state,waiting},
+>                  {resp_headers,[]},
+>                  {resp_body,<<>>},
+>                  {onresponse,undefined}]
+> ** Stacktrace: [{bullet_handler,init,
+>                      [{tcp,http},
+>                       {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>,
+>                           <<"GET">>,
+>                           {1,1},
+>                           {{127,0,0,1},56630},
+>                           <<"localhost">>,undefined,8080,<<"/">>,
+>                           undefined,<<"encoding=text">>,undefined,<<>>,
+>                           [],
+>                           [{<<"upgrade">>,<<"websocket">>},
+>                            {<<"connection">>,<<"Upgrade">>},
+>                            {<<"host">>,<<"localhost:8080">>},
+>                            {<<"origin">>,<<"http://www.websocket.org">>},
+>                            {<<"pragma">>,<<"no-cache">>},
+>                            {<<"cache-control">>,<<"no-cache">>},
+>                            {<<"sec-websocket-key">>,
+>                             <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>                            {<<"sec-websocket-version">>,<<"13">>},
+>                            {<<"sec-websocket-extensions">>,
+>                             <<"x-webkit-deflate-frame">>}],
+>                           [{<<"connection">>,[<<"upgrade">>]}],
+>                           undefined,[],waiting,undefined,<<>>,false,waiting,[],
+>                           <<>>,undefined},
+>                       [{handler,connection_handler}]],
+>                      []},
+>                  {cowboy_handler,handler_init,4,
+>                      [{file,"src/cowboy_handler.erl"},{line,69}]},
+>                  {cowboy_protocol,execute,4,
+>                      [{file,"src/cowboy_protocol.erl"},{line,514}]}]
+>
+> Can anyone see what might be throwing this off?  I'd like to get a minimal handler running before I attempt to add some logic.
+>
+> Thanks,
+> Lee
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000083.html b/_build/static/archives/extend/2013-April/000083.html new file mode 100644 index 00000000..4ebd5c3f --- /dev/null +++ b/_build/static/archives/extend/2013-April/000083.html @@ -0,0 +1,179 @@ + + + + [99s-extend] Problems with Bullet + + + + + + + + + + +

[99s-extend] Problems with Bullet

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Mon Apr 8 16:11:44 CEST 2013 +

+
+ +
  Can you get the clock example working? I'm not sure why the initial
+upgrade request would fail; are you exporting init/4 in your handler? Are
+your dependencies consistent (I.e., blow them away and regrab them in case
+it's an older version of cowboy with a new version of bullet, or vice
+versa, maybe)? Either way, starting from the example would allow you to
+start from a set of working code and either avoid the issue entirely, or
+isolate it from your code.
+
+On 4/8/13 9:53 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+
+>Hi all,
+>
+>I'm currently having problems getting a websocket to connect to a simple
+>bare bones Bullet handler.  Unfortunately, I'm still quite an Erlang
+>noob, so the stack traces tend to lead me in circles.  I'm hoping this is
+>obvious stuff to you Erlang pros :-)
+>
+>Given the below handler:
+>
+>init(_Transport, Req, _Opts, _Active) ->
+>	{ok, Req, undefined_state}.
+>
+>stream(Data, Req, State) ->
+>	{ok, Req, State}.
+>
+>info(Info, Req, State) ->
+>	{reply, Info, Req, State}.
+>	
+>terminate(_Req, _State) ->
+>	ok.
+>
+>Connecting with a websocket throws the following error:
+>
+>=ERROR REPORT==== 8-Apr-2013::14:46:11 ===
+>** Cowboy handler bullet_handler terminating in init/3
+>   for the reason error:undef
+>** Options were [{handler,connection_handler}]
+>** Request was [{socket,#Port<0.926>},
+>                {transport,ranch_tcp},
+>                {connection,keepalive},
+>                {pid,<0.491.0>},
+>                {method,<<"GET">>},
+>                {version,{1,1}},
+>                {peer,{{127,0,0,1},56630}},
+>                {host,<<"localhost">>},
+>                {host_info,undefined},
+>                {port,8080},
+>                {path,<<"/">>},
+>                {path_info,undefined},
+>                {qs,<<"encoding=text">>},
+>                {qs_vals,undefined},
+>                {fragment,<<>>},
+>                {bindings,[]},
+>                {headers,[{<<"upgrade">>,<<"websocket">>},
+>                          {<<"connection">>,<<"Upgrade">>},
+>                          {<<"host">>,<<"localhost:8080">>},
+>                          {<<"origin">>,<<"http://www.websocket.org">>},
+>                          {<<"pragma">>,<<"no-cache">>},
+>                          {<<"cache-control">>,<<"no-cache">>},
+>                          {<<"sec-websocket-key">>,
+>                           <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>                          {<<"sec-websocket-version">>,<<"13">>},
+>                          {<<"sec-websocket-extensions">>,
+>                           <<"x-webkit-deflate-frame">>}]},
+>                {p_headers,[{<<"connection">>,[<<"upgrade">>]}]},
+>                {cookies,undefined},
+>                {meta,[]},
+>                {body_state,waiting},
+>                {multipart,undefined},
+>                {buffer,<<>>},
+>                {resp_compress,false},
+>                {resp_state,waiting},
+>                {resp_headers,[]},
+>                {resp_body,<<>>},
+>                {onresponse,undefined}]
+>** Stacktrace: [{bullet_handler,init,
+>                    [{tcp,http},
+>                     {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>,
+>                         <<"GET">>,
+>                         {1,1},
+>                         {{127,0,0,1},56630},
+>                         <<"localhost">>,undefined,8080,<<"/">>,
+>                         undefined,<<"encoding=text">>,undefined,<<>>,
+>                         [],
+>                         [{<<"upgrade">>,<<"websocket">>},
+>                          {<<"connection">>,<<"Upgrade">>},
+>                          {<<"host">>,<<"localhost:8080">>},
+>                          {<<"origin">>,<<"http://www.websocket.org">>},
+>                          {<<"pragma">>,<<"no-cache">>},
+>                          {<<"cache-control">>,<<"no-cache">>},
+>                          {<<"sec-websocket-key">>,
+>                           <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>                          {<<"sec-websocket-version">>,<<"13">>},
+>                          {<<"sec-websocket-extensions">>,
+>                           <<"x-webkit-deflate-frame">>}],
+>                         [{<<"connection">>,[<<"upgrade">>]}],
+>                  
+>undefined,[],waiting,undefined,<<>>,false,waiting,[],
+>                         <<>>,undefined},
+>                     [{handler,connection_handler}]],
+>                    []},
+>                {cowboy_handler,handler_init,4,
+>                    [{file,"src/cowboy_handler.erl"},{line,69}]},
+>                {cowboy_protocol,execute,4,
+>                    [{file,"src/cowboy_protocol.erl"},{line,514}]}]
+>
+>Can anyone see what might be throwing this off?  I'd like to get a
+>minimal handler running before I attempt to add some logic.
+>
+>Thanks,
+>Lee
+>_______________________________________________
+>Extend mailing list
+>Extend at lists.ninenines.eu
+>http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000084.html b/_build/static/archives/extend/2013-April/000084.html new file mode 100644 index 00000000..36ba2a51 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000084.html @@ -0,0 +1,192 @@ + + + + [99s-extend] Problems with Bullet + + + + + + + + + + +

[99s-extend] Problems with Bullet

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Mon Apr 8 16:18:27 CEST 2013 +

+
+ +
  *facepalm* Or that, yeah. Should have correlated the stack trace with
+the error. Not used to seeing cowboy run as the app, not a dependency.
+
+On 4/8/13 10:08 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+>Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin?
+>
+>On 04/08/2013 03:53 PM, Lee Sylvester wrote:
+>> Hi all,
+>>
+>> I'm currently having problems getting a websocket to connect to a
+>>simple bare bones Bullet handler.  Unfortunately, I'm still quite an
+>>Erlang noob, so the stack traces tend to lead me in circles.  I'm hoping
+>>this is obvious stuff to you Erlang pros :-)
+>>
+>> Given the below handler:
+>>
+>> init(_Transport, Req, _Opts, _Active) ->
+>> 	{ok, Req, undefined_state}.
+>>
+>> stream(Data, Req, State) ->
+>> 	{ok, Req, State}.
+>>
+>> info(Info, Req, State) ->
+>> 	{reply, Info, Req, State}.
+>> 	
+>> terminate(_Req, _State) ->
+>> 	ok.
+>>
+>> Connecting with a websocket throws the following error:
+>>
+>> =ERROR REPORT==== 8-Apr-2013::14:46:11 ===
+>> ** Cowboy handler bullet_handler terminating in init/3
+>>     for the reason error:undef
+>> ** Options were [{handler,connection_handler}]
+>> ** Request was [{socket,#Port<0.926>},
+>>                  {transport,ranch_tcp},
+>>                  {connection,keepalive},
+>>                  {pid,<0.491.0>},
+>>                  {method,<<"GET">>},
+>>                  {version,{1,1}},
+>>                  {peer,{{127,0,0,1},56630}},
+>>                  {host,<<"localhost">>},
+>>                  {host_info,undefined},
+>>                  {port,8080},
+>>                  {path,<<"/">>},
+>>                  {path_info,undefined},
+>>                  {qs,<<"encoding=text">>},
+>>                  {qs_vals,undefined},
+>>                  {fragment,<<>>},
+>>                  {bindings,[]},
+>>                  {headers,[{<<"upgrade">>,<<"websocket">>},
+>>                            {<<"connection">>,<<"Upgrade">>},
+>>                            {<<"host">>,<<"localhost:8080">>},
+>>                 
+>>{<<"origin">>,<<"http://www.websocket.org">>},
+>>                            {<<"pragma">>,<<"no-cache">>},
+>>                            {<<"cache-control">>,<<"no-cache">>},
+>>                            {<<"sec-websocket-key">>,
+>>                             <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>>                            {<<"sec-websocket-version">>,<<"13">>},
+>>                            {<<"sec-websocket-extensions">>,
+>>                             <<"x-webkit-deflate-frame">>}]},
+>>                  {p_headers,[{<<"connection">>,[<<"upgrade">>]}]},
+>>                  {cookies,undefined},
+>>                  {meta,[]},
+>>                  {body_state,waiting},
+>>                  {multipart,undefined},
+>>                  {buffer,<<>>},
+>>                  {resp_compress,false},
+>>                  {resp_state,waiting},
+>>                  {resp_headers,[]},
+>>                  {resp_body,<<>>},
+>>                  {onresponse,undefined}]
+>> ** Stacktrace: [{bullet_handler,init,
+>>                      [{tcp,http},
+>>                 
+>>{http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>,
+>>                           <<"GET">>,
+>>                           {1,1},
+>>                           {{127,0,0,1},56630},
+>>                           <<"localhost">>,undefined,8080,<<"/">>,
+>>                           undefined,<<"encoding=text">>,undefined,<<>>,
+>>                           [],
+>>                           [{<<"upgrade">>,<<"websocket">>},
+>>                            {<<"connection">>,<<"Upgrade">>},
+>>                            {<<"host">>,<<"localhost:8080">>},
+>>                 
+>>{<<"origin">>,<<"http://www.websocket.org">>},
+>>                            {<<"pragma">>,<<"no-cache">>},
+>>                            {<<"cache-control">>,<<"no-cache">>},
+>>                            {<<"sec-websocket-key">>,
+>>                             <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>>                            {<<"sec-websocket-version">>,<<"13">>},
+>>                            {<<"sec-websocket-extensions">>,
+>>                             <<"x-webkit-deflate-frame">>}],
+>>                           [{<<"connection">>,[<<"upgrade">>]}],
+>>                 
+>>undefined,[],waiting,undefined,<<>>,false,waiting,[],
+>>                           <<>>,undefined},
+>>                       [{handler,connection_handler}]],
+>>                      []},
+>>                  {cowboy_handler,handler_init,4,
+>>                      [{file,"src/cowboy_handler.erl"},{line,69}]},
+>>                  {cowboy_protocol,execute,4,
+>>                      [{file,"src/cowboy_protocol.erl"},{line,514}]}]
+>>
+>> Can anyone see what might be throwing this off?  I'd like to get a
+>>minimal handler running before I attempt to add some logic.
+>>
+>> Thanks,
+>> Lee
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>
+>
+>-- 
+>Loïc Hoguin
+>Erlang Cowboy
+>Nine Nines
+>http://ninenines.eu
+>_______________________________________________
+>Extend mailing list
+>Extend at lists.ninenines.eu
+>http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000085.html b/_build/static/archives/extend/2013-April/000085.html new file mode 100644 index 00000000..7d46c844 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000085.html @@ -0,0 +1,208 @@ + + + + [99s-extend] Problems with Bullet + + + + + + + + + + +

[99s-extend] Problems with Bullet

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Mon Apr 8 16:21:53 CEST 2013 +

+
+ +
Thanks guys,  that was exactly the problem.  I feel a little stupid :-)  I use Rebar to compile my apps, but none of the three books I have on Erlang describe the config files in much detail.  I probably have my entire setup wrong.
+
+Anyhow, it looks to be working, now :-)
+
+Thanks again,
+Lee
+
+
+
+On 8 Apr 2013, at 15:18, "Phillips, Christopher" <Christopher.Phillips at turner.com> wrote:
+
+>  *facepalm* Or that, yeah. Should have correlated the stack trace with
+> the error. Not used to seeing cowboy run as the app, not a dependency.
+> 
+> On 4/8/13 10:08 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+> 
+>> Sounds like Bullet isn't in your path. Forgot -pa deps/*/ebin?
+>> 
+>> On 04/08/2013 03:53 PM, Lee Sylvester wrote:
+>>> Hi all,
+>>> 
+>>> I'm currently having problems getting a websocket to connect to a
+>>> simple bare bones Bullet handler.  Unfortunately, I'm still quite an
+>>> Erlang noob, so the stack traces tend to lead me in circles.  I'm hoping
+>>> this is obvious stuff to you Erlang pros :-)
+>>> 
+>>> Given the below handler:
+>>> 
+>>> init(_Transport, Req, _Opts, _Active) ->
+>>> 	{ok, Req, undefined_state}.
+>>> 
+>>> stream(Data, Req, State) ->
+>>> 	{ok, Req, State}.
+>>> 
+>>> info(Info, Req, State) ->
+>>> 	{reply, Info, Req, State}.
+>>> 	
+>>> terminate(_Req, _State) ->
+>>> 	ok.
+>>> 
+>>> Connecting with a websocket throws the following error:
+>>> 
+>>> =ERROR REPORT==== 8-Apr-2013::14:46:11 ===
+>>> ** Cowboy handler bullet_handler terminating in init/3
+>>>    for the reason error:undef
+>>> ** Options were [{handler,connection_handler}]
+>>> ** Request was [{socket,#Port<0.926>},
+>>>                 {transport,ranch_tcp},
+>>>                 {connection,keepalive},
+>>>                 {pid,<0.491.0>},
+>>>                 {method,<<"GET">>},
+>>>                 {version,{1,1}},
+>>>                 {peer,{{127,0,0,1},56630}},
+>>>                 {host,<<"localhost">>},
+>>>                 {host_info,undefined},
+>>>                 {port,8080},
+>>>                 {path,<<"/">>},
+>>>                 {path_info,undefined},
+>>>                 {qs,<<"encoding=text">>},
+>>>                 {qs_vals,undefined},
+>>>                 {fragment,<<>>},
+>>>                 {bindings,[]},
+>>>                 {headers,[{<<"upgrade">>,<<"websocket">>},
+>>>                           {<<"connection">>,<<"Upgrade">>},
+>>>                           {<<"host">>,<<"localhost:8080">>},
+>>> 
+>>> {<<"origin">>,<<"http://www.websocket.org">>},
+>>>                           {<<"pragma">>,<<"no-cache">>},
+>>>                           {<<"cache-control">>,<<"no-cache">>},
+>>>                           {<<"sec-websocket-key">>,
+>>>                            <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>>>                           {<<"sec-websocket-version">>,<<"13">>},
+>>>                           {<<"sec-websocket-extensions">>,
+>>>                            <<"x-webkit-deflate-frame">>}]},
+>>>                 {p_headers,[{<<"connection">>,[<<"upgrade">>]}]},
+>>>                 {cookies,undefined},
+>>>                 {meta,[]},
+>>>                 {body_state,waiting},
+>>>                 {multipart,undefined},
+>>>                 {buffer,<<>>},
+>>>                 {resp_compress,false},
+>>>                 {resp_state,waiting},
+>>>                 {resp_headers,[]},
+>>>                 {resp_body,<<>>},
+>>>                 {onresponse,undefined}]
+>>> ** Stacktrace: [{bullet_handler,init,
+>>>                     [{tcp,http},
+>>> 
+>>> {http_req,#Port<0.926>,ranch_tcp,keepalive,<0.491.0>,
+>>>                          <<"GET">>,
+>>>                          {1,1},
+>>>                          {{127,0,0,1},56630},
+>>>                          <<"localhost">>,undefined,8080,<<"/">>,
+>>>                          undefined,<<"encoding=text">>,undefined,<<>>,
+>>>                          [],
+>>>                          [{<<"upgrade">>,<<"websocket">>},
+>>>                           {<<"connection">>,<<"Upgrade">>},
+>>>                           {<<"host">>,<<"localhost:8080">>},
+>>> 
+>>> {<<"origin">>,<<"http://www.websocket.org">>},
+>>>                           {<<"pragma">>,<<"no-cache">>},
+>>>                           {<<"cache-control">>,<<"no-cache">>},
+>>>                           {<<"sec-websocket-key">>,
+>>>                            <<"fEj/SOOcQgSKATOjhbNJBQ==">>},
+>>>                           {<<"sec-websocket-version">>,<<"13">>},
+>>>                           {<<"sec-websocket-extensions">>,
+>>>                            <<"x-webkit-deflate-frame">>}],
+>>>                          [{<<"connection">>,[<<"upgrade">>]}],
+>>> 
+>>> undefined,[],waiting,undefined,<<>>,false,waiting,[],
+>>>                          <<>>,undefined},
+>>>                      [{handler,connection_handler}]],
+>>>                     []},
+>>>                 {cowboy_handler,handler_init,4,
+>>>                     [{file,"src/cowboy_handler.erl"},{line,69}]},
+>>>                 {cowboy_protocol,execute,4,
+>>>                     [{file,"src/cowboy_protocol.erl"},{line,514}]}]
+>>> 
+>>> Can anyone see what might be throwing this off?  I'd like to get a
+>>> minimal handler running before I attempt to add some logic.
+>>> 
+>>> Thanks,
+>>> Lee
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>> 
+>> 
+>> 
+>> -- 
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+> 
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000086.html b/_build/static/archives/extend/2013-April/000086.html new file mode 100644 index 00000000..f17e2a4b --- /dev/null +++ b/_build/static/archives/extend/2013-April/000086.html @@ -0,0 +1,66 @@ + + + + [99s-extend] Heartbeat? + + + + + + + + + + +

[99s-extend] Heartbeat?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Apr 10 13:47:45 CEST 2013 +

+
+ +
Hey guys,
+
+So, my bullet websockets are going great.  However, I have a question.  At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds.  Therefore, should I send a heartbeat to the client from Erlang to keep this open?  The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur.
+
+Thanks,
+Lee
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000087.html b/_build/static/archives/extend/2013-April/000087.html new file mode 100644 index 00000000..b024dbf3 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000087.html @@ -0,0 +1,78 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Sasa Juric + sasa.juric at gmail.com +
+ Wed Apr 10 14:00:47 CEST 2013 +

+
+ +
Hi,
+
+I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+
+After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+
+If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+
+After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+
+However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem. 
+The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives. 
+This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+
+This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+
+Thank you very much in advance and best regards,
+Sasa
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000088.html b/_build/static/archives/extend/2013-April/000088.html new file mode 100644 index 00000000..0ba2bb7e --- /dev/null +++ b/_build/static/archives/extend/2013-April/000088.html @@ -0,0 +1,75 @@ + + + + [99s-extend] Heartbeat? + + + + + + + + + + +

[99s-extend] Heartbeat?

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 10 16:38:26 CEST 2013 +

+
+ +
On 04/10/2013 01:47 PM, Lee Sylvester wrote:
+> Hey guys,
+>
+> So, my bullet websockets are going great.  However, I have a question.  At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds.  Therefore, should I send a heartbeat to the client from Erlang to keep this open?  The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur.
+
+Send one from the client if you want it to scale. Bullet provides you 
+with one callback that you can use to send anything. If you're using 
+JSON then sending {} is generally enough.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000089.html b/_build/static/archives/extend/2013-April/000089.html new file mode 100644 index 00000000..dad65559 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000089.html @@ -0,0 +1,86 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 10 16:41:21 CEST 2013 +

+
+ +
On 04/10/2013 02:00 PM, Sasa Juric wrote:
+> Hi,
+>
+> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>
+> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>
+> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>
+> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>
+> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>
+> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+
+Haven't seen this happen on plain Cowboy. The proxy might be the 
+culprit. See if you can reproduce without the proxy.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000090.html b/_build/static/archives/extend/2013-April/000090.html new file mode 100644 index 00000000..a40dcac3 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000090.html @@ -0,0 +1,97 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Sasa Juric + sasa.juric at gmail.com +
+ Wed Apr 10 16:50:31 CEST 2013 +

+
+ +
I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+
+Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+
+Question: can I configure keep-alive timeout in Cowboy?
+
+
+On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+
+> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>> Hi,
+>> 
+>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>> 
+>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>> 
+>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>> 
+>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>> 
+>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>> 
+>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+> 
+> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000091.html b/_build/static/archives/extend/2013-April/000091.html new file mode 100644 index 00000000..0e8d39ec --- /dev/null +++ b/_build/static/archives/extend/2013-April/000091.html @@ -0,0 +1,107 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 10 16:51:50 CEST 2013 +

+
+ +
'timeout' protocol option, in milliseconds.
+
+On 04/10/2013 04:50 PM, Sasa Juric wrote:
+> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>
+> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>
+> Question: can I configure keep-alive timeout in Cowboy?
+>
+>
+> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>
+>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>> Hi,
+>>>
+>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>
+>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>
+>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>
+>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>
+>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>
+>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>
+>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000092.html b/_build/static/archives/extend/2013-April/000092.html new file mode 100644 index 00000000..7df4cb55 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000092.html @@ -0,0 +1,83 @@ + + + + [99s-extend] Heartbeat? + + + + + + + + + + +

[99s-extend] Heartbeat?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Apr 10 16:53:24 CEST 2013 +

+
+ +
Ahh, thank you.
+
+Regards,
+Lee
+
+
+
+On 10 Apr 2013, at 15:38, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 04/10/2013 01:47 PM, Lee Sylvester wrote:
+>> Hey guys,
+>> 
+>> So, my bullet websockets are going great.  However, I have a question.  At present, if I don't send any data to or from my websockets for a while, the connection closes after about 10 - 20 seconds.  Therefore, should I send a heartbeat to the client from Erlang to keep this open?  The websockets are for user to user messaging, so it's possible that large periods of inactivity could occur.
+> 
+> Send one from the client if you want it to scale. Bullet provides you with one callback that you can use to send anything. If you're using JSON then sending {} is generally enough.
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000093.html b/_build/static/archives/extend/2013-April/000093.html new file mode 100644 index 00000000..25544b4e --- /dev/null +++ b/_build/static/archives/extend/2013-April/000093.html @@ -0,0 +1,120 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Sasa Juric + sasa.juric at gmail.com +
+ Wed Apr 10 16:56:08 CEST 2013 +

+
+ +
Thanks!
+
+I was looking at the option, but was confused by description which states:
+Time in milliseconds a client has to send the full request line and headers.
+
+I'll give it a try and see how it works.
+
+Best regards,
+Sasa
+
+On Apr 10, 2013, at 4:51 PM, Loïc Hoguin wrote:
+
+> 'timeout' protocol option, in milliseconds.
+> 
+> On 04/10/2013 04:50 PM, Sasa Juric wrote:
+>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>> 
+>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>> 
+>> Question: can I configure keep-alive timeout in Cowboy?
+>> 
+>> 
+>> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>> 
+>>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>>> Hi,
+>>>> 
+>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>> 
+>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>> 
+>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>> 
+>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>> 
+>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>> 
+>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>> 
+>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000094.html b/_build/static/archives/extend/2013-April/000094.html new file mode 100644 index 00000000..48a3dac6 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000094.html @@ -0,0 +1,132 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 10 17:01:14 CEST 2013 +

+
+ +
Means it's not a read timeout, but a timeout for the whole request up to 
+and excluding the body (so an intentionally slow client will get 
+disconnected at 5s).
+
+On 04/10/2013 04:56 PM, Sasa Juric wrote:
+> Thanks!
+>
+> I was looking at the option, but was confused by description which states:
+> Time in milliseconds a client has to send the full request line and headers.
+>
+> I'll give it a try and see how it works.
+>
+> Best regards,
+> Sasa
+>
+> On Apr 10, 2013, at 4:51 PM, Loïc Hoguin wrote:
+>
+>> 'timeout' protocol option, in milliseconds.
+>>
+>> On 04/10/2013 04:50 PM, Sasa Juric wrote:
+>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>>>
+>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>>>
+>>> Question: can I configure keep-alive timeout in Cowboy?
+>>>
+>>>
+>>> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>>>
+>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>>>> Hi,
+>>>>>
+>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>>>
+>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>>>
+>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>>>
+>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>>>
+>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>>>
+>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>>>
+>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000095.html b/_build/static/archives/extend/2013-April/000095.html new file mode 100644 index 00000000..1e8cc343 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000095.html @@ -0,0 +1,137 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Sasa Juric + sasa.juric at gmail.com +
+ Wed Apr 10 17:05:51 CEST 2013 +

+
+ +
Ok, just to make sure I understand:
+When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply?
+
+
+On Apr 10, 2013, at 5:01 PM, Loïc Hoguin wrote:
+
+> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s).
+> 
+> On 04/10/2013 04:56 PM, Sasa Juric wrote:
+>> Thanks!
+>> 
+>> I was looking at the option, but was confused by description which states:
+>> Time in milliseconds a client has to send the full request line and headers.
+>> 
+>> I'll give it a try and see how it works.
+>> 
+>> Best regards,
+>> Sasa
+>> 
+>> On Apr 10, 2013, at 4:51 PM, Loïc Hoguin wrote:
+>> 
+>>> 'timeout' protocol option, in milliseconds.
+>>> 
+>>> On 04/10/2013 04:50 PM, Sasa Juric wrote:
+>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>>>> 
+>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>>>> 
+>>>> Question: can I configure keep-alive timeout in Cowboy?
+>>>> 
+>>>> 
+>>>> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>>>> 
+>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>>>>> Hi,
+>>>>>> 
+>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>>>> 
+>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>>>> 
+>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>>>> 
+>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>>>> 
+>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>>>> 
+>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>>>> 
+>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>>>> 
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> Erlang Cowboy
+>>>>> Nine Nines
+>>>>> http://ninenines.eu
+>>>> 
+>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000096.html b/_build/static/archives/extend/2013-April/000096.html new file mode 100644 index 00000000..9e31920e --- /dev/null +++ b/_build/static/archives/extend/2013-April/000096.html @@ -0,0 +1,149 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 10 17:07:18 CEST 2013 +

+
+ +
It's running from the moment Cowboy starts expecting a new request up to 
+the moment it got the request in full (excluding the body), then it's 
+reset for the next request.
+
+On 04/10/2013 05:05 PM, Sasa Juric wrote:
+> Ok, just to make sure I understand:
+> When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply?
+>
+>
+> On Apr 10, 2013, at 5:01 PM, Loïc Hoguin wrote:
+>
+>> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s).
+>>
+>> On 04/10/2013 04:56 PM, Sasa Juric wrote:
+>>> Thanks!
+>>>
+>>> I was looking at the option, but was confused by description which states:
+>>> Time in milliseconds a client has to send the full request line and headers.
+>>>
+>>> I'll give it a try and see how it works.
+>>>
+>>> Best regards,
+>>> Sasa
+>>>
+>>> On Apr 10, 2013, at 4:51 PM, Loïc Hoguin wrote:
+>>>
+>>>> 'timeout' protocol option, in milliseconds.
+>>>>
+>>>> On 04/10/2013 04:50 PM, Sasa Juric wrote:
+>>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>>>>>
+>>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+>>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+>>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>>>>>
+>>>>> Question: can I configure keep-alive timeout in Cowboy?
+>>>>>
+>>>>>
+>>>>> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>>>>>
+>>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>>>>>> Hi,
+>>>>>>>
+>>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>>>>>
+>>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>>>>>
+>>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>>>>>
+>>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>>>>>
+>>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>>>>>
+>>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>>>>>
+>>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>>>>>
+>>>>>> --
+>>>>>> Loïc Hoguin
+>>>>>> Erlang Cowboy
+>>>>>> Nine Nines
+>>>>>> http://ninenines.eu
+>>>>>
+>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000097.html b/_build/static/archives/extend/2013-April/000097.html new file mode 100644 index 00000000..0fce37e1 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000097.html @@ -0,0 +1,152 @@ + + + + [99s-extend] cowboy and chromium + + + + + + + + + + +

[99s-extend] cowboy and chromium

+ Sasa Juric + sasa.juric at gmail.com +
+ Wed Apr 10 17:11:57 CEST 2013 +

+
+ +
Thanks!
+
+On Apr 10, 2013, at 5:07 PM, Loïc Hoguin wrote:
+
+> It's running from the moment Cowboy starts expecting a new request up to the moment it got the request in full (excluding the body), then it's reset for the next request.
+> 
+> On 04/10/2013 05:05 PM, Sasa Juric wrote:
+>> Ok, just to make sure I understand:
+>> When I serve a request, and the connection is not closed due to keep-alive, will this timeout also apply?
+>> 
+>> 
+>> On Apr 10, 2013, at 5:01 PM, Loïc Hoguin wrote:
+>> 
+>>> Means it's not a read timeout, but a timeout for the whole request up to and excluding the body (so an intentionally slow client will get disconnected at 5s).
+>>> 
+>>> On 04/10/2013 04:56 PM, Sasa Juric wrote:
+>>>> Thanks!
+>>>> 
+>>>> I was looking at the option, but was confused by description which states:
+>>>> Time in milliseconds a client has to send the full request line and headers.
+>>>> 
+>>>> I'll give it a try and see how it works.
+>>>> 
+>>>> Best regards,
+>>>> Sasa
+>>>> 
+>>>> On Apr 10, 2013, at 4:51 PM, Loïc Hoguin wrote:
+>>>> 
+>>>>> 'timeout' protocol option, in milliseconds.
+>>>>> 
+>>>>> On 04/10/2013 04:50 PM, Sasa Juric wrote:
+>>>>>> I agree with you. In addition, I can't reproduce without the proxy, which confirms the suspicion.
+>>>>>> 
+>>>>>> Looking at the code of mochiweb which I was using, the connection timeout is set to 5 minutes.
+>>>>>> The other factor, which I can confirm is that when the server terminates the connection, the proxy doesn't forward this to the client. Hence, the client and proxy probably "think" that connection is still active, and try to reuse it, but this doesn't work until timeout.
+>>>>>> Other browsers probably can gracefully handle this situation, but for some reason chromium is stuck to 60 seconds and after retry it presumably opens new connection and succeeds.
+>>>>>> 
+>>>>>> Question: can I configure keep-alive timeout in Cowboy?
+>>>>>> 
+>>>>>> 
+>>>>>> On Apr 10, 2013, at 4:41 PM, Loïc Hoguin wrote:
+>>>>>> 
+>>>>>>> On 04/10/2013 02:00 PM, Sasa Juric wrote:
+>>>>>>>> Hi,
+>>>>>>>> 
+>>>>>>>> I have recently in my production system replaced mochiweb with cowboy. The server generally works fine, except for a bizarre behavior which I cannot quite explain, so I post here, hoping to get some pointers.
+>>>>>>>> 
+>>>>>>>> After replacing mochiweb with cowboy, I noticed that in chromium (other major browsers work fine) often (but not always) a request lasts a little more than a minute. Further inspection in chrome://net-internals showed that browser tries to send a request, times out after 60 sec, retries and then succeeds immediately. The key point is that it doesn't happen always. First couple of requests work fine, then all of a sudden one doesn't work. At the same time requests from other browsers (including chrome) on the same machine work fine.
+>>>>>>>> 
+>>>>>>>> If I revert to mochiweb, the problem disappears. Other than web server related code, everything else is the same: the rest of my code, the server setup etc... In addition, I return same responses and headers in both versions.
+>>>>>>>> 
+>>>>>>>> After many attempts and failures, I might have worked around the issue. Namely, I included <<"connection">>, <<"close">> in all responses. After this change, it seems that long requests are not occurring. In any case, I can't reproduce it anymore, whereas before the change I could have reproduce it easily.
+>>>>>>>> 
+>>>>>>>> However, I'm not sure if I have really resolved the issue, I'm also not happy with connection closes since it degrades performance. And finally, I'm not sure if I quite understand the problem.
+>>>>>>>> The only theory I have is that due to keep-alive, chromium holds the connection, while cowboy closes it (I read somewhere that hardcoded timeout is 5 seconds, right?). In this case it might happen that chromium sends a request to a non existing socket and then hangs for a minute, waiting for the response which never arrives.
+>>>>>>>> This might further be amplified by the fact that in production, between browser and cowboy, there is a proxy/load balancer, so maybe load balancer still holds the connection despite the fact that server had closed it.
+>>>>>>>> 
+>>>>>>>> This is the only theory I currently have, and I would like to hear if you guys have some other idea or any kind of helpful pointer?
+>>>>>>> 
+>>>>>>> Haven't seen this happen on plain Cowboy. The proxy might be the culprit. See if you can reproduce without the proxy.
+>>>>>>> 
+>>>>>>> --
+>>>>>>> Loïc Hoguin
+>>>>>>> Erlang Cowboy
+>>>>>>> Nine Nines
+>>>>>>> http://ninenines.eu
+>>>>>> 
+>>>>> 
+>>>>> 
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> Erlang Cowboy
+>>>>> Nine Nines
+>>>>> http://ninenines.eu
+>>>> 
+>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000098.html b/_build/static/archives/extend/2013-April/000098.html new file mode 100644 index 00000000..ee3ce9ba --- /dev/null +++ b/_build/static/archives/extend/2013-April/000098.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 11 07:51:12 CEST 2013 +

+
+ +
Hi guys,
+
+So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+
+I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+
+Thanks,
+Lee
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000099.html b/_build/static/archives/extend/2013-April/000099.html new file mode 100644 index 00000000..3bab2cbe --- /dev/null +++ b/_build/static/archives/extend/2013-April/000099.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Jeremy Ong + jeremy at quarkgames.com +
+ Thu Apr 11 08:29:16 CEST 2013 +

+
+ +
Make all the machines identically and add an haproxy (or equivalent)
+machine to load balance between all of them. Haproxy can handle many
+many requests. Keep in mind that with tcp, the load balancer is just
+accepting the socket but then the client communicates with the actual
+application server directly afterwards.
+
+On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+> Hi guys,
+>
+> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+>
+> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+>
+> Thanks,
+> Lee
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000100.html b/_build/static/archives/extend/2013-April/000100.html new file mode 100644 index 00000000..1efa066a --- /dev/null +++ b/_build/static/archives/extend/2013-April/000100.html @@ -0,0 +1,89 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 11 08:49:18 CEST 2013 +

+
+ +
Thanks Jeremy, but what about inter-node communication?  If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that?  Especially if this user is sending several messages and expecting replies.  Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this?
+
+Thanks,
+Lee
+
+
+On 11 Apr 2013, at 07:29, Jeremy Ong <jeremy at quarkgames.com> wrote:
+
+> Make all the machines identically and add an haproxy (or equivalent)
+> machine to load balance between all of them. Haproxy can handle many
+> many requests. Keep in mind that with tcp, the load balancer is just
+> accepting the socket but then the client communicates with the actual
+> application server directly afterwards.
+> 
+> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>> Hi guys,
+>> 
+>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+>> 
+>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+>> 
+>> Thanks,
+>> Lee
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000101.html b/_build/static/archives/extend/2013-April/000101.html new file mode 100644 index 00000000..9202db3c --- /dev/null +++ b/_build/static/archives/extend/2013-April/000101.html @@ -0,0 +1,102 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Jeremy Ong + jeremy at quarkgames.com +
+ Thu Apr 11 09:04:04 CEST 2013 +

+
+ +
I see. I assume this is for a chat server of some sort?
+
+You don't want the user process sending all these messages because the
+user process wouldn't be able to do anything useful (like receive
+messages) in the meantime.
+
+Better is to implement a pubsub process for each channel of
+communication (i.e. one process per room) or rely on Redis pubsub or
+something if speed is extremely important.
+
+There is no way to get around the O(N) complexity of broadcasting.
+
+On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+> Thanks Jeremy, but what about inter-node communication?  If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that?  Especially if this user is sending several messages and expecting replies.  Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this?
+>
+> Thanks,
+> Lee
+>
+>
+> On 11 Apr 2013, at 07:29, Jeremy Ong <jeremy at quarkgames.com> wrote:
+>
+>> Make all the machines identically and add an haproxy (or equivalent)
+>> machine to load balance between all of them. Haproxy can handle many
+>> many requests. Keep in mind that with tcp, the load balancer is just
+>> accepting the socket but then the client communicates with the actual
+>> application server directly afterwards.
+>>
+>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>>> Hi guys,
+>>>
+>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+>>>
+>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+>>>
+>>> Thanks,
+>>> Lee
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000102.html b/_build/static/archives/extend/2013-April/000102.html new file mode 100644 index 00000000..c9d55344 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000102.html @@ -0,0 +1,112 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 11 14:55:29 CEST 2013 +

+
+ +
Thank you, Jeremy, that's good advice.  It's not so much a chat platform, but I guess it would resemble one in architecture.  The part I'm concerned about, though, is should I be avoiding the internal Erlang messaging between connections (over many nodes) for heavy messaging?
+
+Thanks,
+Lee
+
+
+
+On 11 Apr 2013, at 08:04, Jeremy Ong <jeremy at quarkgames.com> wrote:
+
+> I see. I assume this is for a chat server of some sort?
+> 
+> You don't want the user process sending all these messages because the
+> user process wouldn't be able to do anything useful (like receive
+> messages) in the meantime.
+> 
+> Better is to implement a pubsub process for each channel of
+> communication (i.e. one process per room) or rely on Redis pubsub or
+> something if speed is extremely important.
+> 
+> There is no way to get around the O(N) complexity of broadcasting.
+> 
+> On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>> Thanks Jeremy, but what about inter-node communication?  If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that?  Especially if this user is sending several messages and expecting replies.  Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this?
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> On 11 Apr 2013, at 07:29, Jeremy Ong <jeremy at quarkgames.com> wrote:
+>> 
+>>> Make all the machines identically and add an haproxy (or equivalent)
+>>> machine to load balance between all of them. Haproxy can handle many
+>>> many requests. Keep in mind that with tcp, the load balancer is just
+>>> accepting the socket but then the client communicates with the actual
+>>> application server directly afterwards.
+>>> 
+>>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>>>> Hi guys,
+>>>> 
+>>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+>>>> 
+>>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+>>>> 
+>>>> Thanks,
+>>>> Lee
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000103.html b/_build/static/archives/extend/2013-April/000103.html new file mode 100644 index 00000000..28c7c536 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000103.html @@ -0,0 +1,122 @@ + + + + [99s-extend] Distributed model? + + + + + + + + + + +

[99s-extend] Distributed model?

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Apr 11 17:46:35 CEST 2013 +

+
+ +
Okay, so I've figured it out.  I will need to have a separate messaging layer.  Does anyone know of a messaging layer that can be used when all you know is the PID to send to?
+
+Thanks,
+Lee
+
+
+
+On 11 Apr 2013, at 13:55, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+
+> Thank you, Jeremy, that's good advice.  It's not so much a chat platform, but I guess it would resemble one in architecture.  The part I'm concerned about, though, is should I be avoiding the internal Erlang messaging between connections (over many nodes) for heavy messaging?
+> 
+> Thanks,
+> Lee
+> 
+> 
+> 
+> On 11 Apr 2013, at 08:04, Jeremy Ong <jeremy at quarkgames.com> wrote:
+> 
+>> I see. I assume this is for a chat server of some sort?
+>> 
+>> You don't want the user process sending all these messages because the
+>> user process wouldn't be able to do anything useful (like receive
+>> messages) in the meantime.
+>> 
+>> Better is to implement a pubsub process for each channel of
+>> communication (i.e. one process per room) or rely on Redis pubsub or
+>> something if speed is extremely important.
+>> 
+>> There is no way to get around the O(N) complexity of broadcasting.
+>> 
+>> On Wed, Apr 10, 2013 at 11:49 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>>> Thanks Jeremy, but what about inter-node communication?  If I have a user on node A sending a message to 10k users located on 10 other nodes, what is the best way to handle that?  Especially if this user is sending several messages and expecting replies.  Should I use the standard Erlang inter-process messaging or should I implement an MQ on top to handle this?
+>>> 
+>>> Thanks,
+>>> Lee
+>>> 
+>>> 
+>>> On 11 Apr 2013, at 07:29, Jeremy Ong <jeremy at quarkgames.com> wrote:
+>>> 
+>>>> Make all the machines identically and add an haproxy (or equivalent)
+>>>> machine to load balance between all of them. Haproxy can handle many
+>>>> many requests. Keep in mind that with tcp, the load balancer is just
+>>>> accepting the socket but then the client communicates with the actual
+>>>> application server directly afterwards.
+>>>> 
+>>>> On Wed, Apr 10, 2013 at 10:51 PM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>>>>> Hi guys,
+>>>>> 
+>>>>> So, I have my Cowboy / Bullet server working nicely, now, with much thanks to members on this list.  I'm now looking at the best means of clustering this app.  I want to set this up so that, should the connection count get very high (which it will), then I should only have to throw more machines at this problem and it'll all go away.
+>>>>> 
+>>>>> I've got most of the logic working for this, but what I'm worried about is sending a lot of content over the erlang inter-node connection.  I've heard hogging this line can be both a bottleneck and can potentially interrupt the heartbeat between nodes.  With this in mind, should I look at adding a ZMQ layer or some such to facilitate this?  What is the general solution to high traffic between nodes?
+>>>>> 
+>>>>> Thanks,
+>>>>> Lee
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>> 
+> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000104.html b/_build/static/archives/extend/2013-April/000104.html new file mode 100644 index 00000000..692c6f64 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000104.html @@ -0,0 +1,127 @@ + + + + [99s-extend] populating #http_req for unit testing + + + + + + + + + + +

[99s-extend] populating #http_req for unit testing

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Fri Apr 12 01:37:18 CEST 2013 +

+
+ +
+Cowfolk,
+
+I am doing something like this to create an #http_req suitable for unit
+testing my resource callbacks:
+
+-define (HTTP_REQ_ENCODERS_PORT_8000,  #http_req{host= <<"www.foo.com">> ,
+port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>, fragment=
+<<>> }).
+
+Notice that I needed to set the transport to a Cowboy specific atom
+because I wanted to get cowboy_req:host_url and cowboy_req:path to work
+properly.  
+
+I'm sure there is a method that Cowboy uses internally to populate an
+#http_req from a URL that I could use for testing.  What might that be?
+How else should I be populating this record.
+
+Cheers,
+
+-kb
+
+
+
+
+
+
+On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu"
+<extend-request at lists.ninenines.eu> wrote:
+
+>Welcome to the Extend at lists.ninenines.eu mailing list!
+>
+>To post to this list, send your message to:
+>
+>  extend at lists.ninenines.eu
+>
+>General information about the mailing list is at:
+>
+>  http://lists.ninenines.eu:81/listinfo/extend
+>
+>If you ever want to unsubscribe or change your options (eg, switch to
+>or from digest mode, change your password, etc.), visit your
+>subscription page at:
+>
+>  http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com
+>
+>You can also make such adjustments via email by sending a message to:
+>
+>  Extend-request at lists.ninenines.eu
+>
+>with the word `help' in the subject or body (don't include the
+>quotes), and you will get back a message with instructions.
+>
+>You must know your password to change your options (including changing
+>the password, itself) or to unsubscribe without confirmation.  It is:
+>
+>  doofus1
+>
+>Normally, Mailman will remind you of your lists.ninenines.eu mailing
+>list passwords once every month, although you can disable this if you
+>prefer.  This reminder will also include instructions on how to
+>unsubscribe or change your account options.  There is also a button on
+>your options page that will email your current password to you.
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000105.html b/_build/static/archives/extend/2013-April/000105.html new file mode 100644 index 00000000..001e12f6 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000105.html @@ -0,0 +1,143 @@ + + + + [99s-extend] populating #http_req for unit testing + + + + + + + + + + +

[99s-extend] populating #http_req for unit testing

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 12 02:07:26 CEST 2013 +

+
+ +
There's a few undocumented functions in cowboy_req, like new, set and 
+get, used by Cowboy internally.
+
+On 04/12/2013 01:37 AM, Brown, Kevin wrote:
+>
+> Cowfolk,
+>
+> I am doing something like this to create an #http_req suitable for unit
+> testing my resource callbacks:
+>
+> -define (HTTP_REQ_ENCODERS_PORT_8000,  #http_req{host= <<"www.foo.com">> ,
+> port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>, fragment=
+> <<>> }).
+>
+> Notice that I needed to set the transport to a Cowboy specific atom
+> because I wanted to get cowboy_req:host_url and cowboy_req:path to work
+> properly.
+>
+> I'm sure there is a method that Cowboy uses internally to populate an
+> #http_req from a URL that I could use for testing.  What might that be?
+> How else should I be populating this record.
+>
+> Cheers,
+>
+> -kb
+>
+>
+>
+>
+>
+>
+> On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu"
+> <extend-request at lists.ninenines.eu> wrote:
+>
+>> Welcome to the Extend at lists.ninenines.eu mailing list!
+>>
+>> To post to this list, send your message to:
+>>
+>>   extend at lists.ninenines.eu
+>>
+>> General information about the mailing list is at:
+>>
+>>   http://lists.ninenines.eu:81/listinfo/extend
+>>
+>> If you ever want to unsubscribe or change your options (eg, switch to
+>> or from digest mode, change your password, etc.), visit your
+>> subscription page at:
+>>
+>>   http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com
+>>
+>> You can also make such adjustments via email by sending a message to:
+>>
+>>   Extend-request at lists.ninenines.eu
+>>
+>> with the word `help' in the subject or body (don't include the
+>> quotes), and you will get back a message with instructions.
+>>
+>> You must know your password to change your options (including changing
+>> the password, itself) or to unsubscribe without confirmation.  It is:
+>>
+>>   doofus1
+>>
+>> Normally, Mailman will remind you of your lists.ninenines.eu mailing
+>> list passwords once every month, although you can disable this if you
+>> prefer.  This reminder will also include instructions on how to
+>> unsubscribe or change your account options.  There is also a button on
+>> your options page that will email your current password to you.
+>>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000106.html b/_build/static/archives/extend/2013-April/000106.html new file mode 100644 index 00000000..fc45bb84 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000106.html @@ -0,0 +1,152 @@ + + + + [99s-extend] populating #http_req for unit testing + + + + + + + + + + +

[99s-extend] populating #http_req for unit testing

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Fri Apr 12 02:30:15 CEST 2013 +

+
+ +
Thanks.
+
+On 4/11/13 8:07 PM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+>There's a few undocumented functions in cowboy_req, like new, set and
+>get, used by Cowboy internally.
+>
+>On 04/12/2013 01:37 AM, Brown, Kevin wrote:
+>>
+>> Cowfolk,
+>>
+>> I am doing something like this to create an #http_req suitable for unit
+>> testing my resource callbacks:
+>>
+>> -define (HTTP_REQ_ENCODERS_PORT_8000,  #http_req{host=
+>><<"www.foo.com">> ,
+>> port=8000, path= <<"/encoders">>,transport=ranch_tcp, qs= <<>>,
+>>fragment=
+>> <<>> }).
+>>
+>> Notice that I needed to set the transport to a Cowboy specific atom
+>> because I wanted to get cowboy_req:host_url and cowboy_req:path to work
+>> properly.
+>>
+>> I'm sure there is a method that Cowboy uses internally to populate an
+>> #http_req from a URL that I could use for testing.  What might that be?
+>> How else should I be populating this record.
+>>
+>> Cheers,
+>>
+>> -kb
+>>
+>>
+>>
+>>
+>>
+>>
+>> On 4/11/13 7:07 PM, "extend-request at lists.ninenines.eu"
+>> <extend-request at lists.ninenines.eu> wrote:
+>>
+>>> Welcome to the Extend at lists.ninenines.eu mailing list!
+>>>
+>>> To post to this list, send your message to:
+>>>
+>>>   extend at lists.ninenines.eu
+>>>
+>>> General information about the mailing list is at:
+>>>
+>>>   http://lists.ninenines.eu:81/listinfo/extend
+>>>
+>>> If you ever want to unsubscribe or change your options (eg, switch to
+>>> or from digest mode, change your password, etc.), visit your
+>>> subscription page at:
+>>>
+>>>   http://lists.ninenines.eu:81/options/extend/kevin.brown%40turner.com
+>>>
+>>> You can also make such adjustments via email by sending a message to:
+>>>
+>>>   Extend-request at lists.ninenines.eu
+>>>
+>>> with the word `help' in the subject or body (don't include the
+>>> quotes), and you will get back a message with instructions.
+>>>
+>>> You must know your password to change your options (including changing
+>>> the password, itself) or to unsubscribe without confirmation.  It is:
+>>>
+>>>   doofus1
+>>>
+>>> Normally, Mailman will remind you of your lists.ninenines.eu mailing
+>>> list passwords once every month, although you can disable this if you
+>>> prefer.  This reminder will also include instructions on how to
+>>> unsubscribe or change your account options.  There is also a button on
+>>> your options page that will email your current password to you.
+>>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>
+>
+>-- 
+>Loïc Hoguin
+>Erlang Cowboy
+>Nine Nines
+>http://ninenines.eu
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000107.html b/_build/static/archives/extend/2013-April/000107.html new file mode 100644 index 00000000..dfdb80fa --- /dev/null +++ b/_build/static/archives/extend/2013-April/000107.html @@ -0,0 +1,93 @@ + + + + [99s-extend] populating #http_req for unit testing + + + + + + + + + + +

[99s-extend] populating #http_req for unit testing

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Sat Apr 13 13:12:39 CEST 2013 +

+
+ +
On Thu, Apr 11, 2013 at 8:37 PM, Brown, Kevin <Kevin.Brown at turner.com>wrote:
+
+>
+> Cowfolk,
+>
+> I am doing something like this to create an #http_req suitable for unit
+> testing my resource callbacks:
+>
+
+
+I use the library meck(https://github.com/eproxus/meck) to test stuff doing
+something like this:
+
+some_test() ->
+  meck:expect(cowboy_req, binding, 2, {<<"app_key">>, req} )
+  ?assertEqual({ok, req, empty},
+                 websocket_handler:websocket_init(transport, req, opts)),
+  ?assert(meck:validate(cowboy_req)).
+
+I use simple atoms as input and mock the cowboy_req functions to return
+atoms that would represent the correct or the wrong answer.
+
+The real implementation or how cowboy represent stuff is not important
+here, just the output pattern like {Binding, Req}.
+
+That's it
+
+-- 
+
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130413/f1b70800/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000108.html b/_build/static/archives/extend/2013-April/000108.html new file mode 100644 index 00000000..b5cf96b3 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000108.html @@ -0,0 +1,88 @@ + + + + [99s-extend] Reading body_qs multiple times + + + + + + + + + + +

[99s-extend] Reading body_qs multiple times

+ rambocoder + erlang at rambocoder.com +
+ Mon Apr 15 22:45:42 CEST 2013 +

+
+ +
Hello group,
+
+I am trying to put together a CSRF middleware
+https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693
+and
+if the body of the request contains "_csrf" token, I check to make sure it
+matches the csrf token in the session.
+
+Currently I am doing it in middleware using cowboy_req:body_qs/1 however
+when in the handler I need to read another body parameter, such as in the
+rest_pastebin example:
+
+{ok, BodyQs, Req3} = cowboy_req:body_qs(Req),
+Paste = proplists:get_value(<<"paste">>, BodyQs),
+
+cowboy_req:body_qs/1 returns [] due to the body of the request being
+already read {body_state,done}
+
+Is it pointless to have the type of CSRF middleware that I am writing and
+just do the CSRF in the handler's callback, where I can deal with all the
+body_qs at once?
+
+Thank you,
+
+rambocoder
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130415/03f35a62/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000109.html b/_build/static/archives/extend/2013-April/000109.html new file mode 100644 index 00000000..4d048b76 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000109.html @@ -0,0 +1,104 @@ + + + + [99s-extend] Reading body_qs multiple times + + + + + + + + + + +

[99s-extend] Reading body_qs multiple times

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Apr 15 22:47:47 CEST 2013 +

+
+ +
Why not just put the token in the URL instead? if it's CSRF then it's 
+probably used only once and only for POST and the like, so not cached or 
+anything.
+
+On 04/15/2013 10:45 PM, rambocoder wrote:
+> Hello group,
+>
+> I am trying to put together a CSRF middleware
+> https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693 and
+> if the body of the request contains "_csrf" token, I check to make sure
+> it matches the csrf token in the session.
+>
+> Currently I am doing it in middleware using cowboy_req:body_qs/1 however
+> when in the handler I need to read another body parameter, such as in
+> the rest_pastebin example:
+>
+> {ok, BodyQs, Req3} = cowboy_req:body_qs(Req),
+> Paste = proplists:get_value(<<"paste">>, BodyQs),
+>
+> cowboy_req:body_qs/1 returns [] due to the body of the request being
+> already read {body_state,done}
+>
+> Is it pointless to have the type of CSRF middleware that I am writing
+> and just do the CSRF in the handler's callback, where I can deal with
+> all the body_qs at once?
+>
+> Thank you,
+>
+> rambocoder
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000110.html b/_build/static/archives/extend/2013-April/000110.html new file mode 100644 index 00000000..7bf621ee --- /dev/null +++ b/_build/static/archives/extend/2013-April/000110.html @@ -0,0 +1,149 @@ + + + + [99s-extend] Reading body_qs multiple times + + + + + + + + + + +

[99s-extend] Reading body_qs multiple times

+ rambocoder + erlang at rambocoder.com +
+ Tue Apr 16 02:13:44 CEST 2013 +

+
+ +
Loic,
+
+After giving the CSRF middleware some thought and reading
+https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
+I
+came to conclusion that it is best to just not create the middleware and
+instead deal with CSRF on as needed basis.
+
+I know that node's Connect middleware
+http://www.senchalabs.org/connect/csrf.html#defaultValue for example allows
+for the csrf token to be passed as a query string parameter, however, the
+OWASP article made me think that it is not the most secure approach.
+
+For example, AngularJS http://docs.angularjs.org/api/ng.$http has a section
+on how their AJAX component behaves to do CSRF out of the box, and they are
+talking about the server sending a cookie XSRF-TOKEN that is not HttpOnly.
+That makes me realize that csrf is a process more than just slapping some
+middleware into the pipeline.
+
+Btw, I noticed that when the result of the middleware execute function is:
+{error, StatusCode, Req}
+if I set the reply on the request via cowboy_req:reply before returning the
+{error.. , the status code of that reply will be used.
+
+Such as:
+{ok, Req3} = cowboy_req:reply(403, [], "Invalid CSRF Token.", Req2),
+{error, 500, Req3}; % 500 is ignored, 403 is returned
+
+Is that by design?
+
+Sincerely,
+
+rambocoder
+
+
+
+On Mon, Apr 15, 2013 at 4:47 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Why not just put the token in the URL instead? if it's CSRF then it's
+> probably used only once and only for POST and the like, so not cached or
+> anything.
+>
+>
+> On 04/15/2013 10:45 PM, rambocoder wrote:
+>
+>> Hello group,
+>>
+>> I am trying to put together a CSRF middleware
+>> https://github.com/rambocoder/**stable/commit/**
+>> b26980d292ac42aadfe9921a961436**e28cdbb693<https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693>and
+>> if the body of the request contains "_csrf" token, I check to make sure
+>> it matches the csrf token in the session.
+>>
+>> Currently I am doing it in middleware using cowboy_req:body_qs/1 however
+>> when in the handler I need to read another body parameter, such as in
+>> the rest_pastebin example:
+>>
+>> {ok, BodyQs, Req3} = cowboy_req:body_qs(Req),
+>> Paste = proplists:get_value(<<"paste">**>, BodyQs),
+>>
+>> cowboy_req:body_qs/1 returns [] due to the body of the request being
+>> already read {body_state,done}
+>>
+>> Is it pointless to have the type of CSRF middleware that I am writing
+>> and just do the CSRF in the handler's callback, where I can deal with
+>> all the body_qs at once?
+>>
+>> Thank you,
+>>
+>> rambocoder
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130415/59aaeef2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000111.html b/_build/static/archives/extend/2013-April/000111.html new file mode 100644 index 00000000..95e1e1f5 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000111.html @@ -0,0 +1,165 @@ + + + + [99s-extend] Reading body_qs multiple times + + + + + + + + + + +

[99s-extend] Reading body_qs multiple times

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Apr 16 13:34:14 CEST 2013 +

+
+ +
On 04/16/2013 02:13 AM, rambocoder wrote:
+> Loic,
+>
+> After giving the CSRF middleware some thought and reading
+> https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL I
+> came to conclusion that it is best to just not create the middleware and
+> instead deal with CSRF on as needed basis.
+
+Your link says what I said too, except I probably wasn't explicit enough.
+
+If you have a form that does POST (or PUT or PATCH or DELETE), put the 
+token in "<form action="/path/to/resource?csrf=$TOKEN">". The token must 
+be only valid once, it must not be reused, not even between different 
+forms (each form gets its own token). Since it is not a GET request, 
+then you don't have cache or referer issues.
+
+You can still have issues if you allow another site to run JS on yours 
+(but you probably shouldn't) or if there is a malevolent proxy (use SSL 
+where needed), but these are different issues entirely.
+
+> Btw, I noticed that when the result of the middleware execute function is:
+> {error, StatusCode, Req}
+> if I set the reply on the request via cowboy_req:reply before returning
+> the {error.. , the status code of that reply will be used.
+>
+> Such as:
+> {ok, Req3} = cowboy_req:reply(403, [], "Invalid CSRF Token.", Req2),
+> {error, 500, Req3}; % 500 is ignored, 403 is returned
+
+Yes, the response was already sent, therefore the second one is ignored.
+
+> Is that by design?
+>
+> Sincerely,
+>
+> rambocoder
+>
+>
+>
+> On Mon, Apr 15, 2013 at 4:47 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Why not just put the token in the URL instead? if it's CSRF then
+>     it's probably used only once and only for POST and the like, so not
+>     cached or anything.
+>
+>
+>     On 04/15/2013 10:45 PM, rambocoder wrote:
+>
+>         Hello group,
+>
+>         I am trying to put together a CSRF middleware
+>         https://github.com/rambocoder/__stable/commit/__b26980d292ac42aadfe9921a961436__e28cdbb693
+>         <https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693>
+>         and
+>         if the body of the request contains "_csrf" token, I check to
+>         make sure
+>         it matches the csrf token in the session.
+>
+>         Currently I am doing it in middleware using cowboy_req:body_qs/1
+>         however
+>         when in the handler I need to read another body parameter, such
+>         as in
+>         the rest_pastebin example:
+>
+>         {ok, BodyQs, Req3} = cowboy_req:body_qs(Req),
+>         Paste = proplists:get_value(<<"paste">__>, BodyQs),
+>
+>         cowboy_req:body_qs/1 returns [] due to the body of the request being
+>         already read {body_state,done}
+>
+>         Is it pointless to have the type of CSRF middleware that I am
+>         writing
+>         and just do the CSRF in the handler's callback, where I can deal
+>         with
+>         all the body_qs at once?
+>
+>         Thank you,
+>
+>         rambocoder
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>
+>
+>
+>
+>     --
+>     Loďc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000112.html b/_build/static/archives/extend/2013-April/000112.html new file mode 100644 index 00000000..d2d82a89 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000112.html @@ -0,0 +1,119 @@ + + + + [99s-extend] Cowboy CORS + + + + + + + + + + +

[99s-extend] Cowboy CORS

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Fri Apr 19 16:47:09 CEST 2013 +

+
+ +
Hi guys,
+
+So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (test.localhost.com and cowboy.localhost.com).  However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy.  Here's the OPTIONS response from Chrome's console:
+
+
+Request URL:http://www.example.com/
+Request Method:OPTIONS
+Status Code:200 OK
+Request Headersview source
+Accept:*/*
+Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+Accept-Encoding:gzip,deflate,sdch
+Accept-Language:en-US,en;q=0.8
+Access-Control-Request-Headers:origin, method, content-type
+Access-Control-Request-Method:POST
+Connection:keep-alive
+Host:www.example.com
+Origin:http://test.localhost.com:8889
+Referer:http://test.localhost.com:8889/
+User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+Response Headersview source
+Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method
+Access-Control-Allow-Methods:GET, POST, OPTIONS
+Access-Control-Allow-Origin:*
+connection:keep-alive
+content-length:0
+date:Fri, 19 Apr 2013 14:40:00 GMT
+server:Cowboy
+
+And then this is the POST response:
+
+Request URL:http://www.example.com/
+Request Headersview parsed
+POST http://www.example.com/ HTTP/1.1
+Origin: http://test.localhost.com:8889
+Referer: http://test.localhost.com:8889/
+method: POST http://www.example.com/ HTTP/1.1
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+content-type: application/x-www-form-urlencoded
+Form Dataview parsed
+data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"www.example.com","Application":"test_app","Ident":"lee"}
+
+I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working.  Can anyone spot what I might be doing wrong?
+
+The cowboy_req:set_resp_header is happening in the handle… So
+
+handle(Req, State) ->
+	Reply = case cowboy_req:method(Req) of
+		{<<"POST">>, Req2} ->
+			Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2),
+[snip]
+
+
+Thanks,
+Lee
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130419/bf0e8ef9/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000113.html b/_build/static/archives/extend/2013-April/000113.html new file mode 100644 index 00000000..26913530 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000113.html @@ -0,0 +1,172 @@ + + + + [99s-extend] Cowboy CORS + + + + + + + + + + +

[99s-extend] Cowboy CORS

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Fri Apr 19 17:08:03 CEST 2013 +

+
+ +
  When querying to the VM from a browser, is Chrome complaining that it's a cross domain request in the console? Or something else?
+
+  Is the OPTIONS request firing and failing, or is it the POST that is failing (in the network tab)?
+
+  If it's working in a cross origin context for you locally across different domains (I.e., the browser is sending the CORS headers on the request, and you're seeing the right headers on the response, and the browser is handling them properly, such that you can retrieve the response from your Javascript), then it seems unlikely to be a CORS issue, but maybe a config or proxy or code issue in your handler.
+
+
+From: Lee Sylvester <lee.sylvester at gmail.com<mailto:lee.sylvester at gmail.com>>
+Date: Friday, April 19, 2013 10:47 AM
+To: "extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>" <extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>>
+Subject: [99s-extend] Cowboy CORS
+
+Hi guys,
+
+So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (test.localhost.com<http://test.localhost.com> and cowboy.localhost.com<http://cowboy.localhost.com>).  However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy.  Here's the OPTIONS response from Chrome's console:
+
+
+
+  1.
+Request URL:
+http://www.example.com/
+  2.
+Request Method:
+OPTIONS
+  3.
+Status Code:
+200 OK
+  4.  Request Headersview source
+     *
+Accept:
+*/*
+     *
+Accept-Charset:
+ISO-8859-1,utf-8;q=0.7,*;q=0.3
+     *
+Accept-Encoding:
+gzip,deflate,sdch
+     *
+Accept-Language:
+en-US,en;q=0.8
+     *
+Access-Control-Request-Headers:
+origin, method, content-type
+     *
+Access-Control-Request-Method:
+POST
+     *
+Connection:
+keep-alive
+     *
+Host:
+www.example.com<http://www.example.com>
+     *
+Origin:
+http://test.localhost.com:8889
+     *
+Referer:
+http://test.localhost.com:8889/
+     *
+User-Agent:
+Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+  5.  Response Headersview source
+     *
+Access-Control-Allow-Headers:
+Content-Type, X-Requested-With, Origin, Method
+     *
+Access-Control-Allow-Methods:
+GET, POST, OPTIONS
+     *
+Access-Control-Allow-Origin:
+*
+     *
+connection:
+keep-alive
+     *
+content-length:
+0
+     *
+date:
+Fri, 19 Apr 2013 14:40:00 GMT
+     *
+server:
+Cowboy
+
+And then this is the POST response:
+
+
+  1.
+Request URL:
+http://www.example.com/
+  2.  Request Headersview parsed
+     *   POST http://www.example.com/ HTTP/1.1 Origin: http://test.localhost.com:8889 Referer: http://test.localhost.com:8889/ method: POST http://www.example.com/ HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 content-type: application/x-www-form-urlencoded
+  3.  Form Dataview parsed
+     *   data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"www.example.com<http://www.example.com>","Application":"test_app","Ident":"lee"}
+
+I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working.  Can anyone spot what I might be doing wrong?
+
+The cowboy_req:set_resp_header is happening in the handle… So
+
+handle(Req, State) ->
+Reply = case cowboy_req:method(Req) of
+{<<"POST">>, Req2} ->
+Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2),
+[snip]
+
+
+Thanks,
+Lee
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130419/383515dd/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000114.html b/_build/static/archives/extend/2013-April/000114.html new file mode 100644 index 00000000..9f107a90 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000114.html @@ -0,0 +1,98 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Mon Apr 22 14:59:54 CEST 2013 +

+
+ +
Hi guys,
+
+So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed.  I am now able to use these from many machines from many locations.  However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance:
+
+Request URL:http://www.example.com
+Request Method:OPTIONS
+Status Code:505 HTTP Version Not Supported
+Request Headersview source
+Accept:*/*
+Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+Accept-Encoding:gzip,deflate,sdch
+Accept-Language:en-US,en;q=0.8
+Access-Control-Request-Headers:origin, method, content-type
+Access-Control-Request-Method:POST
+Connection:keep-alive
+Host:www.example.com
+Origin:http://www.test.com
+Referer:http://www.test.com/
+User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+Response Headersview source
+connection:close
+content-length:0
+date:Mon, 22 Apr 2013 12:22:50 GMT
+server:Cowboy
+
+To get around the CORS issue, I set up an onrequest hook, which points to the function:
+
+set_request_cors(Req) ->
+	Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req),
+	Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+	cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3).
+
+I'm afraid I don't have any more info, but this issue is completely eluding me.
+
+Thanks,
+Lee
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000115.html b/_build/static/archives/extend/2013-April/000115.html new file mode 100644 index 00000000..e6e5ba97 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000115.html @@ -0,0 +1,110 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Mon Apr 22 16:28:11 CEST 2013 +

+
+ +
What is the exact http request sent on the failing and successful machines?  How do the differ?
+
+Stack trace?
+
+On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+
+> Hi guys,
+> 
+> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed.  I am now able to use these from many machines from many locations.  However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance:
+> 
+> Request URL:http://www.example.com
+> Request Method:OPTIONS
+> Status Code:505 HTTP Version Not Supported
+> Request Headersview source
+> Accept:*/*
+> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+> Accept-Encoding:gzip,deflate,sdch
+> Accept-Language:en-US,en;q=0.8
+> Access-Control-Request-Headers:origin, method, content-type
+> Access-Control-Request-Method:POST
+> Connection:keep-alive
+> Host:www.example.com
+> Origin:http://www.test.com
+> Referer:http://www.test.com/
+> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+> Response Headersview source
+> connection:close
+> content-length:0
+> date:Mon, 22 Apr 2013 12:22:50 GMT
+> server:Cowboy
+> 
+> To get around the CORS issue, I set up an onrequest hook, which points to the function:
+> 
+> set_request_cors(Req) ->
+>    Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req),
+>    Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>    cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3).
+> 
+> I'm afraid I don't have any more info, but this issue is completely eluding me.
+> 
+> Thanks,
+> Lee
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000116.html b/_build/static/archives/extend/2013-April/000116.html new file mode 100644 index 00000000..0375b7de --- /dev/null +++ b/_build/static/archives/extend/2013-April/000116.html @@ -0,0 +1,151 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Mon Apr 22 16:40:19 CEST 2013 +

+
+ +
Well, the below is the sent and return headers on the failing machine.  On a succeeding machine, the headers are
+
+Request URL:http://www.example.com
+Request Method:OPTIONS
+Status Code:200 OK
+
+Request Headersview source
+Accept:*/*
+Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+Accept-Encoding:gzip,deflate,sdch
+Accept-Language:en-US,en;q=0.8
+Access-Control-Request-Headers:origin, method, content-type
+Access-Control-Request-Method:POST
+Connection:keep-alive
+Host:www.example.com
+Origin:http://www.test.com
+Referer:http://www.test.com/
+User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+
+Response Headersview source
+Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method
+Access-Control-Allow-Methods:GET, POST, OPTIONS
+Access-Control-Allow-Origin:*
+connection:keep-alive
+content-length:68
+date:Mon, 22 Apr 2013 14:33:30 GMT
+server:Cowboy
+
+As you can see, the header control and content isn't being sent back and the connection is closed.
+
+Thanks,
+Lee
+
+
+
+
+On 22 Apr 2013, at 15:28, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+
+> What is the exact http request sent on the failing and successful machines?  How do the differ?
+> 
+> Stack trace?
+> 
+> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+> 
+>> Hi guys,
+>> 
+>> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed.  I am now able to use these from many machines from many locations.  However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance:
+>> 
+>> Request URL:http://www.example.com
+>> Request Method:OPTIONS
+>> Status Code:505 HTTP Version Not Supported
+>> 
+>> Request Headersview source
+>> Accept:*/*
+>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>> Accept-Encoding:gzip,deflate,sdch
+>> Accept-Language:en-US,en;q=0.8
+>> Access-Control-Request-Headers:origin, method, content-type
+>> Access-Control-Request-Method:POST
+>> Connection:keep-alive
+>> Host:www.example.com
+>> Origin:http://www.test.com
+>> Referer:http://www.test.com/
+>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+>> 
+>> Response Headersview source
+>> connection:close
+>> content-length:0
+>> date:Mon, 22 Apr 2013 12:22:50 GMT
+>> server:Cowboy
+>> 
+>> To get around the CORS issue, I set up an onrequest hook, which points to the function:
+>> 
+>> set_request_cors(Req) ->
+>>   Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req),
+>>   Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>>   cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3).
+>> 
+>> I'm afraid I don't have any more info, but this issue is completely eluding me.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000117.html b/_build/static/archives/extend/2013-April/000117.html new file mode 100644 index 00000000..12ba1f47 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000117.html @@ -0,0 +1,166 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Apr 22 17:53:44 CEST 2013 +

+
+ +
Headers are one thing but it'd be useful to know the request line itself.
+
+On 04/22/2013 04:40 PM, Lee Sylvester wrote:
+> Well, the below is the sent and return headers on the failing machine.  On a succeeding machine, the headers are
+>
+> Request URL:http://www.example.com
+> Request Method:OPTIONS
+> Status Code:200 OK
+>
+> Request Headersview source
+> Accept:*/*
+> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+> Accept-Encoding:gzip,deflate,sdch
+> Accept-Language:en-US,en;q=0.8
+> Access-Control-Request-Headers:origin, method, content-type
+> Access-Control-Request-Method:POST
+> Connection:keep-alive
+> Host:www.example.com
+> Origin:http://www.test.com
+> Referer:http://www.test.com/
+> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+>
+> Response Headersview source
+> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin, Method
+> Access-Control-Allow-Methods:GET, POST, OPTIONS
+> Access-Control-Allow-Origin:*
+> connection:keep-alive
+> content-length:68
+> date:Mon, 22 Apr 2013 14:33:30 GMT
+> server:Cowboy
+>
+> As you can see, the header control and content isn't being sent back and the connection is closed.
+>
+> Thanks,
+> Lee
+>
+>
+>
+>
+> On 22 Apr 2013, at 15:28, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+>
+>> What is the exact http request sent on the failing and successful machines?  How do the differ?
+>>
+>> Stack trace?
+>>
+>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+>>
+>>> Hi guys,
+>>>
+>>> So, I was getting a CORS issue when connecting to my Bullet impl, which I have since fixed.  I am now able to use these from many machines from many locations.  However, I have found some machines to be getting a 505 error when making a POST request to the Cowboy instance:
+>>>
+>>> Request URL:http://www.example.com
+>>> Request Method:OPTIONS
+>>> Status Code:505 HTTP Version Not Supported
+>>>
+>>> Request Headersview source
+>>> Accept:*/*
+>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>>> Accept-Encoding:gzip,deflate,sdch
+>>> Accept-Language:en-US,en;q=0.8
+>>> Access-Control-Request-Headers:origin, method, content-type
+>>> Access-Control-Request-Method:POST
+>>> Connection:keep-alive
+>>> Host:www.example.com
+>>> Origin:http://www.test.com
+>>> Referer:http://www.test.com/
+>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+>>>
+>>> Response Headersview source
+>>> connection:close
+>>> content-length:0
+>>> date:Mon, 22 Apr 2013 12:22:50 GMT
+>>> server:Cowboy
+>>>
+>>> To get around the CORS issue, I set up an onrequest hook, which points to the function:
+>>>
+>>> set_request_cors(Req) ->
+>>>    Req2 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET, POST, OPTIONS">>, Req),
+>>>    Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>, <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>>>    cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req3).
+>>>
+>>> I'm afraid I don't have any more info, but this issue is completely eluding me.
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>
+>>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000118.html b/_build/static/archives/extend/2013-April/000118.html new file mode 100644 index 00000000..b9a0d0b2 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000118.html @@ -0,0 +1,178 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Mon Apr 22 17:55:11 CEST 2013 +

+
+ +
You might see if "view source" (rather than the parsed view you sent)
+yields any clues.  You'd like to see HTTP version being sent.
+
+
+On 4/22/13 10:40 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+
+>Well, the below is the sent and return headers on the failing machine.
+>On a succeeding machine, the headers are
+>
+>Request URL:http://www.example.com
+>Request Method:OPTIONS
+>Status Code:200 OK
+>
+>Request Headersview source
+>Accept:*/*
+>Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>Accept-Encoding:gzip,deflate,sdch
+>Accept-Language:en-US,en;q=0.8
+>Access-Control-Request-Headers:origin, method, content-type
+>Access-Control-Request-Method:POST
+>Connection:keep-alive
+>Host:www.example.com
+>Origin:http://www.test.com
+>Referer:http://www.test.com/
+>User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
+>AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+>
+>Response Headersview source
+>Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin,
+>Method
+>Access-Control-Allow-Methods:GET, POST, OPTIONS
+>Access-Control-Allow-Origin:*
+>connection:keep-alive
+>content-length:68
+>date:Mon, 22 Apr 2013 14:33:30 GMT
+>server:Cowboy
+>
+>As you can see, the header control and content isn't being sent back and
+>the connection is closed.
+>
+>Thanks,
+>Lee
+>
+>
+>
+>
+>On 22 Apr 2013, at 15:28, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+>
+>> What is the exact http request sent on the failing and successful
+>>machines?  How do the differ?
+>> 
+>> Stack trace?
+>> 
+>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com>
+>>wrote:
+>> 
+>>> Hi guys,
+>>> 
+>>> So, I was getting a CORS issue when connecting to my Bullet impl,
+>>>which I have since fixed.  I am now able to use these from many
+>>>machines from many locations.  However, I have found some machines to
+>>>be getting a 505 error when making a POST request to the Cowboy
+>>>instance:
+>>> 
+>>> Request URL:http://www.example.com
+>>> Request Method:OPTIONS
+>>> Status Code:505 HTTP Version Not Supported
+>>> 
+>>> Request Headersview source
+>>> Accept:*/*
+>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>>> Accept-Encoding:gzip,deflate,sdch
+>>> Accept-Language:en-US,en;q=0.8
+>>> Access-Control-Request-Headers:origin, method, content-type
+>>> Access-Control-Request-Method:POST
+>>> Connection:keep-alive
+>>> Host:www.example.com
+>>> Origin:http://www.test.com
+>>> Referer:http://www.test.com/
+>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31
+>>>(KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+>>> 
+>>> Response Headersview source
+>>> connection:close
+>>> content-length:0
+>>> date:Mon, 22 Apr 2013 12:22:50 GMT
+>>> server:Cowboy
+>>> 
+>>> To get around the CORS issue, I set up an onrequest hook, which points
+>>>to the function:
+>>> 
+>>> set_request_cors(Req) ->
+>>>   Req2 = 
+>>>cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET,
+>>>POST, OPTIONS">>, Req),
+>>>   Req3 = 
+>>>cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>,
+>>><<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>>>   cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>,
+>>><<"*">>, Req3).
+>>> 
+>>> I'm afraid I don't have any more info, but this issue is completely
+>>>eluding me.
+>>> 
+>>> Thanks,
+>>> Lee
+>>> 
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>> 
+>> 
+>
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000119.html b/_build/static/archives/extend/2013-April/000119.html new file mode 100644 index 00000000..0f58a6e7 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000119.html @@ -0,0 +1,212 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Mon Apr 22 20:30:08 CEST 2013 +

+
+ +
Does this help?
+
+Request URL:http://www.example.com
+Request Method:OPTIONS
+Status Code:505 HTTP Version Not Supported
+
+Request Headersview parsed
+OPTIONS http://www.example.com HTTP/1.1
+Host: www.example.com
+Proxy-Connection: keep-alive
+Access-Control-Request-Method: POST
+Origin: http://localhost
+User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+Access-Control-Request-Headers: origin, method, content-type
+Accept: */*
+Referer: http://localhost/p/
+Accept-Encoding: gzip,deflate,sdch
+Accept-Language: en-US,en;q=0.8
+Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
+
+Response Headersview parsed
+HTTP/1.1 505 HTTP Version Not Supported
+connection: close
+server: Cowboy
+date: Mon, 22 Apr 2013 17:42:39 GMT
+content-length: 0
+
+Thanks,
+Lee
+
+
+On 22 Apr 2013, at 16:55, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+
+> You might see if "view source" (rather than the parsed view you sent)
+> yields any clues.  You'd like to see HTTP version being sent.
+> 
+> 
+> On 4/22/13 10:40 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+> 
+>> Well, the below is the sent and return headers on the failing machine.
+>> On a succeeding machine, the headers are
+>> 
+>> Request URL:http://www.example.com
+>> Request Method:OPTIONS
+>> Status Code:200 OK
+>> 
+>> Request Headersview source
+>> Accept:*/*
+>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>> Accept-Encoding:gzip,deflate,sdch
+>> Accept-Language:en-US,en;q=0.8
+>> Access-Control-Request-Headers:origin, method, content-type
+>> Access-Control-Request-Method:POST
+>> Connection:keep-alive
+>> Host:www.example.com
+>> Origin:http://www.test.com
+>> Referer:http://www.test.com/
+>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
+>> AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+>> 
+>> Response Headersview source
+>> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin,
+>> Method
+>> Access-Control-Allow-Methods:GET, POST, OPTIONS
+>> Access-Control-Allow-Origin:*
+>> connection:keep-alive
+>> content-length:68
+>> date:Mon, 22 Apr 2013 14:33:30 GMT
+>> server:Cowboy
+>> 
+>> As you can see, the header control and content isn't being sent back and
+>> the connection is closed.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> 
+>> 
+>> On 22 Apr 2013, at 15:28, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+>> 
+>>> What is the exact http request sent on the failing and successful
+>>> machines?  How do the differ?
+>>> 
+>>> Stack trace?
+>>> 
+>>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com>
+>>> wrote:
+>>> 
+>>>> Hi guys,
+>>>> 
+>>>> So, I was getting a CORS issue when connecting to my Bullet impl,
+>>>> which I have since fixed.  I am now able to use these from many
+>>>> machines from many locations.  However, I have found some machines to
+>>>> be getting a 505 error when making a POST request to the Cowboy
+>>>> instance:
+>>>> 
+>>>> Request URL:http://www.example.com
+>>>> Request Method:OPTIONS
+>>>> Status Code:505 HTTP Version Not Supported
+>>>> 
+>>>> Request Headersview source
+>>>> Accept:*/*
+>>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>>>> Accept-Encoding:gzip,deflate,sdch
+>>>> Accept-Language:en-US,en;q=0.8
+>>>> Access-Control-Request-Headers:origin, method, content-type
+>>>> Access-Control-Request-Method:POST
+>>>> Connection:keep-alive
+>>>> Host:www.example.com
+>>>> Origin:http://www.test.com
+>>>> Referer:http://www.test.com/
+>>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31
+>>>> (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+>>>> 
+>>>> Response Headersview source
+>>>> connection:close
+>>>> content-length:0
+>>>> date:Mon, 22 Apr 2013 12:22:50 GMT
+>>>> server:Cowboy
+>>>> 
+>>>> To get around the CORS issue, I set up an onrequest hook, which points
+>>>> to the function:
+>>>> 
+>>>> set_request_cors(Req) ->
+>>>>  Req2 = 
+>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET,
+>>>> POST, OPTIONS">>, Req),
+>>>>  Req3 = 
+>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>,
+>>>> <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>>>>  cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>,
+>>>> <<"*">>, Req3).
+>>>> 
+>>>> I'm afraid I don't have any more info, but this issue is completely
+>>>> eluding me.
+>>>> 
+>>>> Thanks,
+>>>> Lee
+>>>> 
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>> 
+>>> 
+>> 
+>> 
+> 
+> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000120.html b/_build/static/archives/extend/2013-April/000120.html new file mode 100644 index 00000000..1c18db93 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000120.html @@ -0,0 +1,229 @@ + + + + [99s-extend] 505 error + + + + + + + + + + +

[99s-extend] 505 error

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Apr 22 21:19:39 CEST 2013 +

+
+ +
I'm going to need the exact request line to make sense of it. 
+Something's missing in the parser I think, not sure what in your case 
+though. Feel free to private email it.
+
+On 04/22/2013 08:30 PM, Lee Sylvester wrote:
+> Does this help?
+>
+> Request URL:http://www.example.com
+> Request Method:OPTIONS
+> Status Code:505 HTTP Version Not Supported
+>
+> Request Headersview parsed
+> OPTIONS http://www.example.com HTTP/1.1
+> Host: www.example.com
+> Proxy-Connection: keep-alive
+> Access-Control-Request-Method: POST
+> Origin: http://localhost
+> User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+> Access-Control-Request-Headers: origin, method, content-type
+> Accept: */*
+> Referer: http://localhost/p/
+> Accept-Encoding: gzip,deflate,sdch
+> Accept-Language: en-US,en;q=0.8
+> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>
+> Response Headersview parsed
+> HTTP/1.1 505 HTTP Version Not Supported
+> connection: close
+> server: Cowboy
+> date: Mon, 22 Apr 2013 17:42:39 GMT
+> content-length: 0
+>
+> Thanks,
+> Lee
+>
+>
+> On 22 Apr 2013, at 16:55, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+>
+>> You might see if "view source" (rather than the parsed view you sent)
+>> yields any clues.  You'd like to see HTTP version being sent.
+>>
+>>
+>> On 4/22/13 10:40 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+>>
+>>> Well, the below is the sent and return headers on the failing machine.
+>>> On a succeeding machine, the headers are
+>>>
+>>> Request URL:http://www.example.com
+>>> Request Method:OPTIONS
+>>> Status Code:200 OK
+>>>
+>>> Request Headersview source
+>>> Accept:*/*
+>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>>> Accept-Encoding:gzip,deflate,sdch
+>>> Accept-Language:en-US,en;q=0.8
+>>> Access-Control-Request-Headers:origin, method, content-type
+>>> Access-Control-Request-Method:POST
+>>> Connection:keep-alive
+>>> Host:www.example.com
+>>> Origin:http://www.test.com
+>>> Referer:http://www.test.com/
+>>> User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)
+>>> AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+>>>
+>>> Response Headersview source
+>>> Access-Control-Allow-Headers:Content-Type, X-Requested-With, Origin,
+>>> Method
+>>> Access-Control-Allow-Methods:GET, POST, OPTIONS
+>>> Access-Control-Allow-Origin:*
+>>> connection:keep-alive
+>>> content-length:68
+>>> date:Mon, 22 Apr 2013 14:33:30 GMT
+>>> server:Cowboy
+>>>
+>>> As you can see, the header control and content isn't being sent back and
+>>> the connection is closed.
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>>
+>>>
+>>>
+>>> On 22 Apr 2013, at 15:28, "Brown, Kevin" <Kevin.Brown at turner.com> wrote:
+>>>
+>>>> What is the exact http request sent on the failing and successful
+>>>> machines?  How do the differ?
+>>>>
+>>>> Stack trace?
+>>>>
+>>>> On Apr 22, 2013, at 9:00 AM, "Lee Sylvester" <lee.sylvester at gmail.com>
+>>>> wrote:
+>>>>
+>>>>> Hi guys,
+>>>>>
+>>>>> So, I was getting a CORS issue when connecting to my Bullet impl,
+>>>>> which I have since fixed.  I am now able to use these from many
+>>>>> machines from many locations.  However, I have found some machines to
+>>>>> be getting a 505 error when making a POST request to the Cowboy
+>>>>> instance:
+>>>>>
+>>>>> Request URL:http://www.example.com
+>>>>> Request Method:OPTIONS
+>>>>> Status Code:505 HTTP Version Not Supported
+>>>>>
+>>>>> Request Headersview source
+>>>>> Accept:*/*
+>>>>> Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
+>>>>> Accept-Encoding:gzip,deflate,sdch
+>>>>> Accept-Language:en-US,en;q=0.8
+>>>>> Access-Control-Request-Headers:origin, method, content-type
+>>>>> Access-Control-Request-Method:POST
+>>>>> Connection:keep-alive
+>>>>> Host:www.example.com
+>>>>> Origin:http://www.test.com
+>>>>> Referer:http://www.test.com/
+>>>>> User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31
+>>>>> (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
+>>>>>
+>>>>> Response Headersview source
+>>>>> connection:close
+>>>>> content-length:0
+>>>>> date:Mon, 22 Apr 2013 12:22:50 GMT
+>>>>> server:Cowboy
+>>>>>
+>>>>> To get around the CORS issue, I set up an onrequest hook, which points
+>>>>> to the function:
+>>>>>
+>>>>> set_request_cors(Req) ->
+>>>>>   Req2 =
+>>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Methods">>, <<"GET,
+>>>>> POST, OPTIONS">>, Req),
+>>>>>   Req3 =
+>>>>> cowboy_req:set_resp_header(<<"Access-Control-Allow-Headers">>,
+>>>>> <<"Content-Type, X-Requested-With, Origin, Method">>, Req2),
+>>>>>   cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>,
+>>>>> <<"*">>, Req3).
+>>>>>
+>>>>> I'm afraid I don't have any more info, but this issue is completely
+>>>>> eluding me.
+>>>>>
+>>>>> Thanks,
+>>>>> Lee
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>>
+>>>>
+>>>
+>>>
+>>
+>>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000121.html b/_build/static/archives/extend/2013-April/000121.html new file mode 100644 index 00000000..a1fc20ce --- /dev/null +++ b/_build/static/archives/extend/2013-April/000121.html @@ -0,0 +1,66 @@ + + + + [99s-extend] does cowboy support hot code reload/replace ? + + + + + + + + + + +

[99s-extend] does cowboy support hot code reload/replace ?

+ yongboy + yongboy at gmail.com +
+ Thu Apr 25 05:46:24 CEST 2013 +

+
+ +
You know, the OTP's code_change so heavy, sometimes, you just want to
+debug, or change a little, does not want to rewrite the rel appup file.
+Any help is appreciated, thanks.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130425/35ee7614/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000122.html b/_build/static/archives/extend/2013-April/000122.html new file mode 100644 index 00000000..1c5d02fb --- /dev/null +++ b/_build/static/archives/extend/2013-April/000122.html @@ -0,0 +1,76 @@ + + + + [99s-extend] does cowboy support hot code reload/replace ? + + + + + + + + + + +

[99s-extend] does cowboy support hot code reload/replace ?

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Apr 25 13:42:15 CEST 2013 +

+
+ +
On 04/25/2013 05:46 AM, yongboy wrote:
+> You know, the OTP's code_change so heavy, sometimes, you just want to
+> debug, or change a little, does not want to rewrite the rel appup file.
+> Any help is appreciated, thanks.
+
+At this time there is no code_change mechanism in Cowboy. Reloading a 
+module works, modifying the protocol options with 
+ranch:set_protocol_options can be used, but it doesn't change the 
+running processes.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000123.html b/_build/static/archives/extend/2013-April/000123.html new file mode 100644 index 00000000..1876b3f4 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000123.html @@ -0,0 +1,87 @@ + + + + [99s-extend] does cowboy support hot code reload/replace ? + + + + + + + + + + +

[99s-extend] does cowboy support hot code reload/replace ?

+ yongboy + yongboy at gmail.com +
+ Fri Apr 26 07:57:00 CEST 2013 +

+
+ +
Thanks very much !
+Maybe we can use the code:load_file() function I had just found it .
+
+
+2013/4/25 Loïc Hoguin <essen at ninenines.eu>
+
+> On 04/25/2013 05:46 AM, yongboy wrote:
+>
+>> You know, the OTP's code_change so heavy, sometimes, you just want to
+>> debug, or change a little, does not want to rewrite the rel appup file.
+>> Any help is appreciated, thanks.
+>>
+>
+> At this time there is no code_change mechanism in Cowboy. Reloading a
+> module works, modifying the protocol options with
+> ranch:set_protocol_options can be used, but it doesn't change the running
+> processes.
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130426/09f3ed34/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000124.html b/_build/static/archives/extend/2013-April/000124.html new file mode 100644 index 00000000..08b363e5 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000124.html @@ -0,0 +1,122 @@ + + + + [99s-extend] cowboy how to ruduce the memory usage per long-hold connection + + + + + + + + + + +

[99s-extend] cowboy how to ruduce the memory usage per long-hold connection

+ yongboy + yongboy at gmail.com +
+ Fri Apr 26 08:11:56 CEST 2013 +

+
+ +
I have tested one long-hold webapp, when 512000 user connected, the app
+used
+6801M memory, 6801M*1024K / 512000 = 13.6K/Connection.
+
+Does anyone give me some advice on how to reduce the memory usage per one
+connection, thanks very much !
+
+Here is the code snippet:
+
+start(_Type, _Args) ->
+        Dispatch = cowboy_router:compile([
+            {'_', [{'_', htmlfile_handler, []}]}
+        ]),
+        cowboy:start_http(my_http_listener, 100,
+            [{port, 8000}, {max_connections, infinity}],
+            [{env, [{dispatch, Dispatch}]}]
+        ),
+        count_server:start(),
+        htmlfilesimple_sup:start_link().
+
+......
+
+-module(htmlfile_handler).
+-behaviour(cowboy_loop_handler).
+-export([init/3, info/3, terminate/3]).
+-define(HEARBEAT_TIMEOUT, 20*1000).
+-record(status, {count=0}).
+
+init(_Any, Req, State) ->
+        NowCount = count_server:welcome(),
+        io:format("online user ~p :))~n", [NowCount]),
+
+        output_first(Req),
+        Req2 = cowboy_req:compact(Req),
+        {loop, Req2, State, hibernate}.
+
+%% POST/Short Request
+info(_Any, Req, State) ->
+        {loop, Req, State, hibernate}.
+
+output_first(Req) ->
+        {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>,
+<<"text/html; charset=utf-8">>},
+
+{<<"Connection">>, <<"keep-alive">>}], Req),
+        cowboy_req:chunk(<<"<html><body><script>var _ = function (msg) {
+parent.s._(msg, document);
+};</script>
+">>,
+                                                                Reply),
+        cowboy_req:chunk(gen_output("1::"), Reply).
+
+gen_output(String) ->
+        DescList = io_lib:format("<script>_('~s');</script>", [String]),
+        list_to_binary(DescList).
+
+terminate(Reason, _Req, _State) ->
+        NowCount = count_server:bye(),
+        io:format("offline user ~p :(( ~n", [NowCount]).
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130426/9d234e27/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000125.html b/_build/static/archives/extend/2013-April/000125.html new file mode 100644 index 00000000..6fd69519 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000125.html @@ -0,0 +1,140 @@ + + + + [99s-extend] cowboy how to ruduce the memory usage per long-hold connection + + + + + + + + + + +

[99s-extend] cowboy how to ruduce the memory usage per long-hold connection

+ rambocoder + erlang at rambocoder.com +
+ Fri Apr 26 15:11:53 CEST 2013 +

+
+ +
Is 13.6K/connection considered a lot? Once you start doing SSL, each
+connection will be about 80K, IMHO the most important factor for huge
+ammount of COMET users is latency, which Cowboy and Erlang do great.
+
+-rambocoder
+
+On Fri, Apr 26, 2013 at 2:11 AM, yongboy <yongboy at gmail.com> wrote:
+
+> I have tested one long-hold webapp, when 512000 user connected, the app
+> used
+> 6801M memory, 6801M*1024K / 512000 = 13.6K/Connection.
+>
+> Does anyone give me some advice on how to reduce the memory usage per one
+> connection, thanks very much !
+>
+> Here is the code snippet:
+>
+> start(_Type, _Args) ->
+>         Dispatch = cowboy_router:compile([
+>             {'_', [{'_', htmlfile_handler, []}]}
+>         ]),
+>         cowboy:start_http(my_http_listener, 100,
+>             [{port, 8000}, {max_connections, infinity}],
+>             [{env, [{dispatch, Dispatch}]}]
+>         ),
+>         count_server:start(),
+>         htmlfilesimple_sup:start_link().
+>
+> ......
+>
+> -module(htmlfile_handler).
+> -behaviour(cowboy_loop_handler).
+> -export([init/3, info/3, terminate/3]).
+> -define(HEARBEAT_TIMEOUT, 20*1000).
+> -record(status, {count=0}).
+>
+> init(_Any, Req, State) ->
+>         NowCount = count_server:welcome(),
+>         io:format("online user ~p :))~n", [NowCount]),
+>
+>         output_first(Req),
+>         Req2 = cowboy_req:compact(Req),
+>         {loop, Req2, State, hibernate}.
+>
+> %% POST/Short Request
+> info(_Any, Req, State) ->
+>         {loop, Req, State, hibernate}.
+>
+> output_first(Req) ->
+>         {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>,
+> <<"text/html; charset=utf-8">>},
+>
+> {<<"Connection">>, <<"keep-alive">>}], Req),
+>         cowboy_req:chunk(<<"<html><body><script>var _ = function (msg) {
+> parent.s._(msg, document);
+> };</script>
+> ">>,
+>                                                                 Reply),
+>         cowboy_req:chunk(gen_output("1::"), Reply).
+>
+> gen_output(String) ->
+>         DescList = io_lib:format("<script>_('~s');</script>", [String]),
+>         list_to_binary(DescList).
+>
+> terminate(Reason, _Req, _State) ->
+>         NowCount = count_server:bye(),
+>         io:format("offline user ~p :(( ~n", [NowCount]).
+>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130426/b1e8ae7a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000126.html b/_build/static/archives/extend/2013-April/000126.html new file mode 100644 index 00000000..093d494d --- /dev/null +++ b/_build/static/archives/extend/2013-April/000126.html @@ -0,0 +1,90 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.4 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.4

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 26 17:21:32 CEST 2013 +

+
+ +
Hello,
+
+Cowboy 0.8.4 has been released!
+
+This release features a tentatively stable API. This means that the 
+complete API defined in this release should not change anymore. The API 
+will be augmented with many features and functions of course, but 
+existing code should not break anymore. Changes will only be considered 
+if a feature causes bugs or too much confusion to the majority of users.
+
+This release includes all the remaining changes that had to be done to 
+REST, which is now no longer experimental and has documentation that you 
+can find here:
+
+   http://ninenines.eu/docs/en/cowboy/HEAD/guide/rest_handlers
+
+Diagrams and their explanations will be added to the documentation in 
+the next few days.
+
+The full changelog for this release can be found here: 
+https://github.com/extend/cowboy/commit/46b2ea0aaa7fe891bfdf3f8a0c47357393e72cf6
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/000127.html b/_build/static/archives/extend/2013-April/000127.html new file mode 100644 index 00000000..cc767686 --- /dev/null +++ b/_build/static/archives/extend/2013-April/000127.html @@ -0,0 +1,75 @@ + + + + [99s-extend] cowboy websocket and wamp + + + + + + + + + + +

[99s-extend] cowboy websocket and wamp

+ Gregory de Souza + gdesouza at gmail.com +
+ Tue Apr 30 20:59:21 CEST 2013 +

+
+ +
Hi,
+I'm new to the community and am exploring cowboy for a project.
+
+Can anyone offer guidance/links on how to use cowboy's websocket support
+with WAMP (http://wamp.ws/)?
+The cowboy docs mention bullet <https://github.com/extend/bullet?source=cr> as
+a convenient client/server lib (with an AJAX fallback) which is great, but
+I'd like to use WAMP's RPC and PubSub so I'm unsure how to proceed.
+
+Any tips would be appreciated!
+
+Thanks in advance
+-- 
+Gregory | @gdesouza <http://twitter.com/gdesouza> | http://blog.gdesouza.me
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130430/c86f8fdb/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-April/author.html b/_build/static/archives/extend/2013-April/author.html new file mode 100644 index 00000000..f8edc33c --- /dev/null +++ b/_build/static/archives/extend/2013-April/author.html @@ -0,0 +1,322 @@ + + + + The Extend April 2013 Archive by author + + + + + +

April 2013 Archives by author

+ +

Starting: Tue Apr 2 19:23:28 CEST 2013
+ Ending: Tue Apr 30 20:59:21 CEST 2013
+ Messages: 55

+

+

+ Last message date: + Tue Apr 30 20:59:21 CEST 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-April/date.html b/_build/static/archives/extend/2013-April/date.html new file mode 100644 index 00000000..a3b39452 --- /dev/null +++ b/_build/static/archives/extend/2013-April/date.html @@ -0,0 +1,322 @@ + + + + The Extend April 2013 Archive by date + + + + + +

April 2013 Archives by date

+ +

Starting: Tue Apr 2 19:23:28 CEST 2013
+ Ending: Tue Apr 30 20:59:21 CEST 2013
+ Messages: 55

+

+

+ Last message date: + Tue Apr 30 20:59:21 CEST 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-April/index.html b/_build/static/archives/extend/2013-April/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-April/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-April/subject.html b/_build/static/archives/extend/2013-April/subject.html new file mode 100644 index 00000000..741c7962 --- /dev/null +++ b/_build/static/archives/extend/2013-April/subject.html @@ -0,0 +1,322 @@ + + + + The Extend April 2013 Archive by subject + + + + + +

April 2013 Archives by subject

+ +

Starting: Tue Apr 2 19:23:28 CEST 2013
+ Ending: Tue Apr 30 20:59:21 CEST 2013
+ Messages: 55

+

+

+ Last message date: + Tue Apr 30 20:59:21 CEST 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-April/thread.html b/_build/static/archives/extend/2013-April/thread.html new file mode 100644 index 00000000..eafeca8a --- /dev/null +++ b/_build/static/archives/extend/2013-April/thread.html @@ -0,0 +1,431 @@ + + + + The Extend April 2013 Archive by thread + + + + + +

April 2013 Archives by thread

+ +

Starting: Tue Apr 2 19:23:28 CEST 2013
+ Ending: Tue Apr 30 20:59:21 CEST 2013
+ Messages: 55

+

+

+ Last message date: + Tue Apr 30 20:59:21 CEST 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-August.txt b/_build/static/archives/extend/2013-August.txt new file mode 100644 index 00000000..6dde6851 --- /dev/null +++ b/_build/static/archives/extend/2013-August.txt @@ -0,0 +1,2765 @@ +From fgallaire at gmail.com Fri Aug 2 17:01:26 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:01:26 +0200 +Subject: [99s-extend] Mailing lists +Message-ID: + +The extend projets are great and very popular, they need to have each +one a different mailing list. + +And mailman has a really useless web interface. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From fgallaire at gmail.com Fri Aug 2 17:06:42 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:06:42 +0200 +Subject: [99s-extend] Riak in Farwest +Message-ID: + +I love the farwest technical choices. But Riak seems to only be the +"prototype' database, and PostgreSQL the real target. + +FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +want Riak, who really wants PostgresSQL ?? + +Florent + +-- +FLOSS Engineer & Lawyer + + +From essen at ninenines.eu Fri Aug 2 17:08:47 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:08:47 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: +References: +Message-ID: <51FBCB7F.5080803@ninenines.eu> + +Please tell us what you think makes Riak superior. + +On 08/02/2013 05:06 PM, Florent Gallaire wrote: +> I love the farwest technical choices. But Riak seems to only be the +> "prototype' database, and PostgreSQL the real target. +> +> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +> want Riak, who really wants PostgresSQL ?? +> +> Florent +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Aug 2 17:09:58 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:09:58 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: +Message-ID: <51FBCBC6.60805@ninenines.eu> + +On 08/02/2013 05:01 PM, Florent Gallaire wrote: +> The extend projets are great and very popular, they need to have each +> one a different mailing list. + +That would be true if there was actual activity on the mailing lists. +There isn't. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From fgallaire at gmail.com Fri Aug 2 17:14:00 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:14:00 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: <51FBCBC6.60805@ninenines.eu> +References: + <51FBCBC6.60805@ninenines.eu> +Message-ID: + +On Fri, Aug 2, 2013 at 5:09 PM, Lo?c Hoguin wrote: +> On 08/02/2013 05:01 PM, Florent Gallaire wrote: +>> +>> The extend projets are great and very popular, they need to have each +>> one a different mailing list. +> +> +> That would be true if there was actual activity on the mailing lists. There +> isn't. + +There is no activity because Mailman is useless. + +Florent + +-- +FLOSS Engineer & Lawye + + +From lee.sylvester at gmail.com Fri Aug 2 17:20:05 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Fri, 2 Aug 2013 16:20:05 +0100 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <51FBCB7F.5080803@ninenines.eu> +References: + <51FBCB7F.5080803@ninenines.eu> +Message-ID: <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + +It's a bit like comparing sports cars to superbikes. Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc. Plus, it's built on Erlang :-) PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc. Each has their place. For typical websites, PostgreSQL is the better choice. For distributed applications, Riak is often the better choice. *** + +Lee + +*** Mostly my opinion, only. + + + +On 2 Aug 2013, at 16:08, Lo?c Hoguin wrote: + +> Please tell us what you think makes Riak superior. +> +> On 08/02/2013 05:06 PM, Florent Gallaire wrote: +>> I love the farwest technical choices. But Riak seems to only be the +>> "prototype' database, and PostgreSQL the real target. +>> +>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +>> want Riak, who really wants PostgresSQL ?? +>> +>> Florent +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From essen at ninenines.eu Fri Aug 2 17:21:39 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:21:39 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + +Message-ID: <51FBCE83.1010706@ninenines.eu> + +On 08/02/2013 05:14 PM, Florent Gallaire wrote: +> On Fri, Aug 2, 2013 at 5:09 PM, Lo?c Hoguin wrote: +>> On 08/02/2013 05:01 PM, Florent Gallaire wrote: +>>> +>>> The extend projets are great and very popular, they need to have each +>>> one a different mailing list. +>> +>> +>> That would be true if there was actual activity on the mailing lists. There +>> isn't. +> +> There is no activity because Mailman is useless. + +I said no activity, I didn't say no members. Please keep your complaints +about the tool down, it's got nothing to do with it, and you just end up +spamming people here. + +All development happens on IRC, so this leaves the mailing lists only +useful for questions, which should be rarer over time considering the +docs keep improving and the archives provide great answers for the rest. +It's all good. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From fgallaire at gmail.com Fri Aug 2 17:25:22 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:25:22 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <51FBCB7F.5080803@ninenines.eu> +References: + <51FBCB7F.5080803@ninenines.eu> +Message-ID: + +On Fri, Aug 2, 2013 at 5:08 PM, Lo?c Hoguin wrote: +> Please tell us what you think makes Riak superior. + +Riak is written in Erlang. See your own argumentations on why Erlang +is the best langage to program high load/fault-tolerent web software. + +Riak is written in Erlang, as all the 99 other soft -> good +integration of the whole. + +Riak is a NoSQL Dynamo database with Availability and Partition +tolerance, and this is what I want for my web applications. PostgreSQL +is a SQL Availability and Consistency old school database. + +Riak is just what want a developer who use erlang to have a scaling platform. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From Kevin.Brown at turner.com Fri Aug 2 17:29:35 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Fri, 2 Aug 2013 15:29:35 +0000 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> +References: + <51FBCB7F.5080803@ninenines.eu>, + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> +Message-ID: <5320D978-2DD2-4E4F-98DD-D61ED6E6D270@turner.com> + +Postgres has been made to scale well in GIS applications. Apple is using Postgres for their current Maps geo point storage. + +On Aug 2, 2013, at 11:20 AM, "Lee Sylvester" wrote: + +> It's a bit like comparing sports cars to superbikes. Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc. Plus, it's built on Erlang :-) PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc. Each has their place. For typical websites, PostgreSQL is the better choice. For distributed applications, Riak is often the better choice. *** +> +> Lee +> +> *** Mostly my opinion, only. +> +> +> +> On 2 Aug 2013, at 16:08, Lo?c Hoguin wrote: +> +>> Please tell us what you think makes Riak superior. +>> +>> On 08/02/2013 05:06 PM, Florent Gallaire wrote: +>>> I love the farwest technical choices. But Riak seems to only be the +>>> "prototype' database, and PostgreSQL the real target. +>>> +>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +>>> want Riak, who really wants PostgresSQL ?? +>>> +>>> Florent +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + + +From fgallaire at gmail.com Fri Aug 2 17:33:32 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:33:32 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: <51FBCE83.1010706@ninenines.eu> +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> +Message-ID: + +> I said no activity, I didn't say no members. Please keep your complaints +> about the tool down, it's got nothing to do with it, and you just end up +> spamming people here. +> +> All development happens on IRC, so this leaves the mailing lists only useful +> for questions, which should be rarer over time considering the docs keep +> improving and the archives provide great answers for the rest. It's all +> good. + +I don't agree. More you have users, more you should have questions on +the mailing list, even if the documentation is improving. + +I'm on the mailing lists of **a lot** of free software with great +documentations, and they are very active. + +Where is the history of the choices/debates made on IRC ? + +Florent + +-- +FLOSS Engineer & Lawyer + + +From lee.sylvester at gmail.com Fri Aug 2 17:33:53 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Fri, 2 Aug 2013 16:33:53 +0100 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: +References: + <51FBCB7F.5080803@ninenines.eu> + +Message-ID: <3F6842C8-00E0-4235-8C01-59015B7E2B83@gmail.com> + +NoSQL is a trend, but is often not the best choice for data storage. The reason it has had a strong revival recently (no, NoSQL is not a new thing) is because it is simpler for non-SQL developers to jump into and requires less thought on structuring your data. However, there are many scenarios where NoSQL is a bad choice. For example, I would certainly hope my bank doesn't log my transactions using NoSQL! + +Lee + + + + +On 2 Aug 2013, at 16:25, Florent Gallaire wrote: + +> On Fri, Aug 2, 2013 at 5:08 PM, Lo?c Hoguin wrote: +>> Please tell us what you think makes Riak superior. +> +> Riak is written in Erlang. See your own argumentations on why Erlang +> is the best langage to program high load/fault-tolerent web software. +> +> Riak is written in Erlang, as all the 99 other soft -> good +> integration of the whole. +> +> Riak is a NoSQL Dynamo database with Availability and Partition +> tolerance, and this is what I want for my web applications. PostgreSQL +> is a SQL Availability and Consistency old school database. +> +> Riak is just what want a developer who use erlang to have a scaling platform. +> +> Florent +> +> -- +> FLOSS Engineer & Lawyer +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From essen at ninenines.eu Fri Aug 2 17:35:13 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:35:13 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> +Message-ID: <51FBD1B1.7060206@ninenines.eu> + +Let me clarify a few misconceptions here. (Mostly to show the choice +isn't random, don't take it wrong.) + +Riak and Riak CS are two different things. You most likely don't want to +run them together, especially considering the hardware requirements will +differ. + +Riak core, pipes, etc. are not really useful if you only use Riak as a +data store. It's cool that your DB has a great distributed processing +framework but pretty useless when you just want to retrieve some data +and format it in a web page. + +Riak has clustering, yes. PostgreSQL has clustering too. + +Riak has data-center aware clustering also if you get Riak Enterprise. +But it costs a lot (per node!). You can do the same with PostgreSQL at a +fraction of the price. + +Riak is built on Erlang, sure. But why should I care? I only want it to +handle my data. I don't want to look at the code. PostgreSQL is a much +proven piece of software. + +On 08/02/2013 05:20 PM, Lee Sylvester wrote: +> It's a bit like comparing sports cars to superbikes. Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc. Plus, it's built on Erlang :-) PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc. Each has their place. For typical websites, PostgreSQL is the better choice. For distributed applications, Riak is often the better choice. *** +> +> Lee +> +> *** Mostly my opinion, only. +> +> +> +> On 2 Aug 2013, at 16:08, Lo?c Hoguin wrote: +> +>> Please tell us what you think makes Riak superior. +>> +>> On 08/02/2013 05:06 PM, Florent Gallaire wrote: +>>> I love the farwest technical choices. But Riak seems to only be the +>>> "prototype' database, and PostgreSQL the real target. +>>> +>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +>>> want Riak, who really wants PostgresSQL ?? +>>> +>>> Florent +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From fgallaire at gmail.com Fri Aug 2 17:35:58 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:35:58 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <3F6842C8-00E0-4235-8C01-59015B7E2B83@gmail.com> +References: + <51FBCB7F.5080803@ninenines.eu> + + <3F6842C8-00E0-4235-8C01-59015B7E2B83@gmail.com> +Message-ID: + +> For example, I would certainly hope my bank doesn't log my transactions using NoSQL! + +You're right, but is Farwest designed to develop banf software ? I +don't think so. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From fgallaire at gmail.com Fri Aug 2 17:39:04 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:39:04 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <51FBD1B1.7060206@ninenines.eu> +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + <51FBD1B1.7060206@ninenines.eu> +Message-ID: + +> PostgreSQL is a much proven piece of software. + +Ouch !! And Apache is a much proven piece of software than cowboy, why +don't use it for Farwest ? + +Florent + + +-- +FLOSS Engineer & Lawyer + + +From essen at ninenines.eu Fri Aug 2 17:39:58 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:39:58 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: +References: + <51FBCB7F.5080803@ninenines.eu> + +Message-ID: <51FBD2CE.8070302@ninenines.eu> + +On 08/02/2013 05:25 PM, Florent Gallaire wrote: +> On Fri, Aug 2, 2013 at 5:08 PM, Lo?c Hoguin wrote: +>> Please tell us what you think makes Riak superior. +> +> Riak is written in Erlang. See your own argumentations on why Erlang +> is the best langage to program high load/fault-tolerent web software. + > +> Riak is written in Erlang, as all the 99 other soft -> good +> integration of the whole. + +See the post I just sent. I have no reason to care about the language +here. It's not going to run in the same node. I'm not going to look at +it. And PostgreSQL is a much proven software, much more than Riak who's +had issues with the Erlang schedulers and more and is still young. + +> Riak is a NoSQL Dynamo database with Availability and Partition +> tolerance, and this is what I want for my web applications. PostgreSQL +> is a SQL Availability and Consistency old school database. + +The need for partitioning comes a *lot* later for SQL databases. They +can deal with big amounts of data just fine. And Farwest is made for +small to medium applications, therefore the issue will likely never come +up until Farwest itself becomes the issue. + +> Riak is just what want a developer who use erlang to have a scaling platform. + +This is the first time I hear complaints about choosing PostgreSQL. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Aug 2 17:41:39 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:41:39 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + <51FBD1B1.7060206@ninenines.eu> + +Message-ID: <51FBD333.7090803@ninenines.eu> + +On 08/02/2013 05:39 PM, Florent Gallaire wrote: +>> PostgreSQL is a much proven piece of software. +> +> Ouch !! And Apache is a much proven piece of software than cowboy, why +> don't use it for Farwest ? + +Because CGI, PHP, Perl, ... aren't. But you can put Apache in front of +Farwest just fine if you need to. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Fri Aug 2 17:43:49 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Fri, 2 Aug 2013 16:43:49 +0100 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <51FBD1B1.7060206@ninenines.eu> +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + <51FBD1B1.7060206@ninenines.eu> +Message-ID: <05D94CB9-3D85-45D1-96AB-3C356A40656E@gmail.com> + +Hey, don't direct that at me :-S I was agreeing with you :-D + +The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better. I'd much rather the dynamo model than a master-to-many slaves model. + +Lee + + + +On 2 Aug 2013, at 16:35, Lo?c Hoguin wrote: + +> Let me clarify a few misconceptions here. (Mostly to show the choice isn't random, don't take it wrong.) +> +> Riak and Riak CS are two different things. You most likely don't want to run them together, especially considering the hardware requirements will differ. +> +> Riak core, pipes, etc. are not really useful if you only use Riak as a data store. It's cool that your DB has a great distributed processing framework but pretty useless when you just want to retrieve some data and format it in a web page. +> +> Riak has clustering, yes. PostgreSQL has clustering too. +> +> Riak has data-center aware clustering also if you get Riak Enterprise. But it costs a lot (per node!). You can do the same with PostgreSQL at a fraction of the price. +> +> Riak is built on Erlang, sure. But why should I care? I only want it to handle my data. I don't want to look at the code. PostgreSQL is a much proven piece of software. +> +> On 08/02/2013 05:20 PM, Lee Sylvester wrote: +>> It's a bit like comparing sports cars to superbikes. Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc. Plus, it's built on Erlang :-) PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc. Each has their place. For typical websites, PostgreSQL is the better choice. For distributed applications, Riak is often the better choice. *** +>> +>> Lee +>> +>> *** Mostly my opinion, only. +>> +>> +>> +>> On 2 Aug 2013, at 16:08, Lo?c Hoguin wrote: +>> +>>> Please tell us what you think makes Riak superior. +>>> +>>> On 08/02/2013 05:06 PM, Florent Gallaire wrote: +>>>> I love the farwest technical choices. But Riak seems to only be the +>>>> "prototype' database, and PostgreSQL the real target. +>>>> +>>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +>>>> want Riak, who really wants PostgresSQL ?? +>>>> +>>>> Florent +>>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Fri Aug 2 17:45:07 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:45:07 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + +Message-ID: <51FBD403.6020008@ninenines.eu> + +On 08/02/2013 05:33 PM, Florent Gallaire wrote: +> Where is the history of the choices/debates made on IRC ? + +No such thing. No need for it either, the choices tend to change a few +times until things stabilize. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From fgallaire at gmail.com Fri Aug 2 17:46:53 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:46:53 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <05D94CB9-3D85-45D1-96AB-3C356A40656E@gmail.com> +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + <51FBD1B1.7060206@ninenines.eu> + <05D94CB9-3D85-45D1-96AB-3C356A40656E@gmail.com> +Message-ID: + +> The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better. I'd much rather the dynamo model than a master-to-many slaves model. + +Yes you're right, all clustering are far to be equal. Dynamo is really +great, and master-to-master is just an archaic way to do things you +don't really know to do. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From essen at ninenines.eu Fri Aug 2 17:47:39 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:47:39 +0200 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: <05D94CB9-3D85-45D1-96AB-3C356A40656E@gmail.com> +References: + <51FBCB7F.5080803@ninenines.eu> + <1832C7FD-55D1-4B4E-B29D-CABD5B31A651@gmail.com> + <51FBD1B1.7060206@ninenines.eu> + <05D94CB9-3D85-45D1-96AB-3C356A40656E@gmail.com> +Message-ID: <51FBD49B.9090107@ninenines.eu> + +I know, hence the "don't take it wrong". + +You have a few different projects enabling multi-master replication for +PostgreSQL. It's not an issue. + +On 08/02/2013 05:43 PM, Lee Sylvester wrote: +> Hey, don't direct that at me :-S I was agreeing with you :-D +> +> The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better. I'd much rather the dynamo model than a master-to-many slaves model. +> +> Lee +> +> +> +> On 2 Aug 2013, at 16:35, Lo?c Hoguin wrote: +> +>> Let me clarify a few misconceptions here. (Mostly to show the choice isn't random, don't take it wrong.) +>> +>> Riak and Riak CS are two different things. You most likely don't want to run them together, especially considering the hardware requirements will differ. +>> +>> Riak core, pipes, etc. are not really useful if you only use Riak as a data store. It's cool that your DB has a great distributed processing framework but pretty useless when you just want to retrieve some data and format it in a web page. +>> +>> Riak has clustering, yes. PostgreSQL has clustering too. +>> +>> Riak has data-center aware clustering also if you get Riak Enterprise. But it costs a lot (per node!). You can do the same with PostgreSQL at a fraction of the price. +>> +>> Riak is built on Erlang, sure. But why should I care? I only want it to handle my data. I don't want to look at the code. PostgreSQL is a much proven piece of software. +>> +>> On 08/02/2013 05:20 PM, Lee Sylvester wrote: +>>> It's a bit like comparing sports cars to superbikes. Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc. Plus, it's built on Erlang :-) PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc. Each has their place. For typical websites, PostgreSQL is the better choice. For distributed applications, Riak is often the better choice. *** +>>> +>>> Lee +>>> +>>> *** Mostly my opinion, only. +>>> +>>> +>>> +>>> On 2 Aug 2013, at 16:08, Lo?c Hoguin wrote: +>>> +>>>> Please tell us what you think makes Riak superior. +>>>> +>>>> On 08/02/2013 05:06 PM, Florent Gallaire wrote: +>>>>> I love the farwest technical choices. But Riak seems to only be the +>>>>> "prototype' database, and PostgreSQL the real target. +>>>>> +>>>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +>>>>> want Riak, who really wants PostgresSQL ?? +>>>>> +>>>>> Florent +>>>>> +>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From fgallaire at gmail.com Fri Aug 2 17:49:00 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:49:00 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: <51FBD403.6020008@ninenines.eu> +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> +Message-ID: + +> No such thing. No need for it either, the choices tend to change a few times +> until things stabilize. + +This is a really wrong way. Free software needs public transparency. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From essen at ninenines.eu Fri Aug 2 17:50:32 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 02 Aug 2013 17:50:32 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + +Message-ID: <51FBD548.3010705@ninenines.eu> + +On 08/02/2013 05:49 PM, Florent Gallaire wrote: +>> No such thing. No need for it either, the choices tend to change a few times +>> until things stabilize. +> +> This is a really wrong way. Free software needs public transparency. + +The regular contributors don't seem to complain. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From tristan.sloughter at gmail.com Fri Aug 2 17:52:17 2013 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Fri, 02 Aug 2013 08:52:17 -0700 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + +Message-ID: <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> + +Public transparency like a public IRC channel anyone can join and log? + +On Fri, Aug 2, 2013, at 08:49 AM, Florent Gallaire wrote: +> > No such thing. No need for it either, the choices tend to change a few times +> > until things stabilize. +> +> This is a really wrong way. Free software needs public transparency. +> +> Florent +> +> -- +> FLOSS Engineer & Lawyer +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From fgallaire at gmail.com Fri Aug 2 17:54:34 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Fri, 2 Aug 2013 17:54:34 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + + <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> +Message-ID: + +On Fri, Aug 2, 2013 at 5:52 PM, Tristan Sloughter + wrote: +> Public transparency like a public IRC channel anyone can join and log? + +Haha, what a joke. It's a pity you don't understand that. + +Florent + +-- +FLOSS Engineer & Lawyer + + +From tristan.sloughter at gmail.com Fri Aug 2 17:54:38 2013 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Fri, 02 Aug 2013 08:54:38 -0700 +Subject: [99s-extend] Riak in Farwest +In-Reply-To: +References: +Message-ID: <1375458878.3163.5088023.2D292459@webmail.messagingengine.com> + +Me for one. Rarely have a use case that fits Riak but daily have use +cases that fit a RDBMS, and Postgres is the best of those in my opinion. + +On Fri, Aug 2, 2013, at 08:06 AM, Florent Gallaire wrote: +> I love the farwest technical choices. But Riak seems to only be the +> "prototype' database, and PostgreSQL the real target. +> +> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I +> want Riak, who really wants PostgresSQL ?? +> +> Florent +> +> -- +> FLOSS Engineer & Lawyer +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From jeremy at quarkgames.com Fri Aug 2 21:33:59 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Fri, 2 Aug 2013 12:33:59 -0700 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + + <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> + +Message-ID: + +Florent, I suggest you actually contribute something before telling +the project maintainer how to run things and flaming people who *have* +contributed. + +On Fri, Aug 2, 2013 at 8:54 AM, Florent Gallaire wrote: +> On Fri, Aug 2, 2013 at 5:52 PM, Tristan Sloughter +> wrote: +>> Public transparency like a public IRC channel anyone can join and log? +> +> Haha, what a joke. It's a pity you don't understand that. +> +> Florent +> +> -- +> FLOSS Engineer & Lawyer +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From edgurgel at gmail.com Fri Aug 2 21:57:22 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Fri, 2 Aug 2013 16:57:22 -0300 +Subject: [99s-extend] Fwd: Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + + <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> + + + +Message-ID: + +Forgot to reply to all + +---------- Forwarded message ---------- +From: Eduardo Gurgel +Date: Fri, Aug 2, 2013 at 4:57 PM +Subject: Re: [99s-extend] Mailing lists +To: Jeremy Ong + + + + +On Fri, Aug 2, 2013 at 4:33 PM, Jeremy Ong wrote: + +> Florent, I suggest you actually contribute something before telling +> the project maintainer how to run things and flaming people who *have* +> contributed. +> + +Agreed. + +Too much pointing finger on this thread... + +-- +Eduardo + + + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From fgallaire at gmail.com Sat Aug 3 00:16:30 2013 +From: fgallaire at gmail.com (Florent Gallaire) +Date: Sat, 3 Aug 2013 00:16:30 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + + <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> + + +Message-ID: + +> Florent, I suggest you actually contribute something before telling +> the project maintainer how to run things and flaming people who *have* +> contributed. + +Jeremy, I tried to test farwest very early : +https://github.com/extend/farwest/pull/4 + +My "bad idee" of a server-sent events handler is now part of bullet : +https://github.com/extend/bullet/issues/16 + +Jeremy, maybe I haven't contribute something on this project because : +- I spend a lot of time working as a lawyer +- I spend a lot of time working on other free software +- I'm not yet a great Erlang programmer + +AND + +- There's no visibility on what is really doing, and who is doing it, +and why, and how it's decided. So I can't lose more time on that +because I can't know what is happened and what will happen. + +I flame nobody. I give the 2 cents of help I can give. This is a +contribution. You can think it's useless, but I don't think so. + +In free software, if you want a great success, you should be more open +that just have a free software licence. +You should do the life easier for the people interested in this +project and who want to help. You can think it's not a problem, but I +think it is. Is that a flame ? + +Florent + +FLOSS Engineer & Lawyer + + +From essen at ninenines.eu Sat Aug 3 09:13:50 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sat, 03 Aug 2013 09:13:50 +0200 +Subject: [99s-extend] Mailing lists +In-Reply-To: +References: + <51FBCBC6.60805@ninenines.eu> + + <51FBCE83.1010706@ninenines.eu> + + <51FBD403.6020008@ninenines.eu> + + <1375458737.2850.5087359.7E431257@webmail.messagingengine.com> + + + +Message-ID: <51FCADAE.5070804@ninenines.eu> + +On 08/03/2013 12:16 AM, Florent Gallaire wrote: +> - There's no visibility on what is really doing, and who is doing it, +> and why, and how it's decided. So I can't lose more time on that +> because I can't know what is happened and what will happen. + +Or, you know, you could just open a ticket or ask like anyone else, +preferrably the former. Chances are whatever you're thinking of doing +has no chance of being merged at all, or could be interesting but only +if certain implementation details are respected, or needs to involve +other people. + +Even if we did put more info on who does what, this still wouldn't +remove the necessity for you to ask if you want to avoid losing your time. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thebullno1 at gmail.com Mon Aug 5 07:38:04 2013 +From: thebullno1 at gmail.com (Bach Le) +Date: Mon, 5 Aug 2013 13:38:04 +0800 +Subject: [99s-extend] Mailing lists +Message-ID: + +>You can think it's not a problem, but Ithink it is. Is that a flame ? +This is a flame: +> Haha, what a joke. It's a pity you don't understand that. + +I for one, prefer Postgres. Not everything can be mapped to kv and that's +the only thing Riak is good for. It's not fit for a general purpose +database. +To me, NoSQL is about specialization. Each db excels at one type of +operation (and then there's mongo, but that's for another time), while +RDBMSs offer general purpose solutions. I begin my projects with an RDBMS +(usually Postgres) and when a particular piece of data is the bottleneck, I +move it to the appropriate NoSQL db. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Aug 14 19:50:18 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 14 Aug 2013 19:50:18 +0200 +Subject: [99s-extend] [ANN] Farwest 0.3.0 +Message-ID: <520BC35A.9060507@ninenines.eu> + +It's finally here! + + * https://github.com/extend/farwest/ + +It's still a mess in the two other repositories so I recommend waiting +before digging in too much. This is just a direct port of the prototype +to a more workable build suite and repository structure. + + * https://github.com/extend/farwest_core/ + * https://github.com/extend/farwest_ui/ + +A lot of work will be done on farwest_core next, while at the same time +the frontend dude takes care of making the UI good. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Thu Aug 15 16:19:42 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 15 Aug 2013 16:19:42 +0200 +Subject: [99s-extend] [ANN] erlang.mk build tool +Message-ID: <520CE37E.4090909@ninenines.eu> + +Hello friendly people, + +I would like to make an official announcement of erlang.mk now that all +the features I wanted are in. + +erlang.mk is a rebar replacement. It was initially created for allowing +a faster development process than rebar and for better compatibility +with Linux build tools. It should work on Linux and OSX with GNU Make +installed. + +Projects using erlang.mk are still compatible with rebar. Dependencies +fetched by rebar are stored in the same deps/ directory, and projects +using erlang.mk can still be used as rebar dependencies, with or without +a rebar.config file. + +erlang.mk also features a simple package index. Try `make pkg-list` to +list all packages currently available. All the packages listed are +compatible with erlang.mk with no tweaking required. + +Makefiles written with erlang.mk are *VERY* simple, here are two examples: + + * https://github.com/extend/farwest/blob/master/Makefile + * https://github.com/extend/cowboy/blob/master/Makefile + +I wrote about erlang.mk and relx recently on the Nine Nines blog. +erlang.mk is the perfect companion to relx. + + * http://ninenines.eu/articles/erlang.mk-and-relx + +Here are examples of projects that are using and compatible with erlang.mk: + + * https://github.com/jlouis/etorrent + * https://github.com/extend/cowboy + * https://github.com/extend/farwest + +You can find erlang.mk at the following URL: + + * https://github.com/extend/erlang.mk + +Contributions to the package index are of course welcome! The only +requirement is that the package is to be compatible with erlang.mk +itself. Just send a PR to the erlang.mk project updating the +packages.v1.txt! + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From desired.mta at gmail.com Thu Aug 15 17:07:42 2013 +From: desired.mta at gmail.com (=?UTF-8?Q?Motiejus_Jak=C5=A1tys?=) +Date: Thu, 15 Aug 2013 17:07:42 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520CE37E.4090909@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> +Message-ID: + +On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin wrote: +> Hello friendly people, +> +> I would like to make an official announcement of erlang.mk now that all the +> features I wanted are in. + +Please include an ability to cleanly override any target so make does +not emit warnings about overwritten target. There are a few ways to do +it, but I find this the easiest: prefix every target in erlang.mk with +a variable: + +$(.erlang-mk-all)all: + + +That way, if $(.erlang-mk-all) is defined (from my application +Makefile before including erlang.mk), your 'all' target will be the +one that does not cause me warnings. + +Motiejus Jak?tys + + +From essen at ninenines.eu Thu Aug 15 18:32:04 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 15 Aug 2013 18:32:04 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: +References: <520CE37E.4090909@ninenines.eu> + +Message-ID: <520D0284.6070408@ninenines.eu> + +On 08/15/2013 05:07 PM, Motiejus Jak?tys wrote: +> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin wrote: +>> Hello friendly people, +>> +>> I would like to make an official announcement of erlang.mk now that all the +>> features I wanted are in. +> +> Please include an ability to cleanly override any target so make does +> not emit warnings about overwritten target. There are a few ways to do +> it, but I find this the easiest: prefix every target in erlang.mk with +> a variable: +> +> $(.erlang-mk-all)all: +> +> +> That way, if $(.erlang-mk-all) is defined (from my application +> Makefile before including erlang.mk), your 'all' target will be the +> one that does not cause me warnings. + +Yes I was thinking about this, but so far nobody needed it. If you do, +though, patches welcome! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Aug 16 16:34:56 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 16 Aug 2013 16:34:56 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: +References: <520CE37E.4090909@ninenines.eu> + +Message-ID: <520E3890.5020000@ninenines.eu> + +On 08/16/2013 10:39 AM, Benoit Chesneau wrote: +> The big problem with erlang.mk is requiring to have +> gmake and more importantly wget installed imo. + +wget is only used for fetching the package index file. I'm sure if it +doesn't work somewhere it'll be patched eventually. + +> Which makes it quite annoying to distribute on systems that have none of +> them. It would be interrestin to have the support for curl for example. +> Also what are the makefile extensions that you really need to require gmake? + +No idea. Patches are welcome for compatibility with different OS/build +tools (as long as it's not "rewrite the whole file" of course, then +you're better off just using gmake). + +> - benoit +> +> +> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin > wrote: +> +> Hello friendly people, +> +> I would like to make an official announcement of erlang.mk +> now that all the features I wanted are in. +> +> erlang.mk is a rebar replacement. It was +> initially created for allowing a faster development process than +> rebar and for better compatibility with Linux build tools. It should +> work on Linux and OSX with GNU Make installed. +> +> Projects using erlang.mk are still compatible +> with rebar. Dependencies fetched by rebar are stored in the same +> deps/ directory, and projects using erlang.mk can +> still be used as rebar dependencies, with or without a rebar.config +> file. +> +> erlang.mk also features a simple package index. +> Try `make pkg-list` to list all packages currently available. All +> the packages listed are compatible with erlang.mk +> with no tweaking required. +> +> Makefiles written with erlang.mk are *VERY* +> simple, here are two examples: +> +> * https://github.com/extend/__farwest/blob/master/Makefile +> +> * https://github.com/extend/__cowboy/blob/master/Makefile +> +> +> I wrote about erlang.mk and relx recently on the +> Nine Nines blog. erlang.mk is the perfect +> companion to relx. +> +> * http://ninenines.eu/articles/__erlang.mk-and-relx +> +> +> Here are examples of projects that are using and compatible with +> erlang.mk : +> +> * https://github.com/jlouis/__etorrent +> +> * https://github.com/extend/__cowboy +> +> * https://github.com/extend/__farwest +> +> +> You can find erlang.mk at the following URL: +> +> * https://github.com/extend/__erlang.mk +> +> +> Contributions to the package index are of course welcome! The only +> requirement is that the package is to be compatible with erlang.mk +> itself. Just send a PR to the erlang.mk +> project updating the packages.v1.txt! +> +> Enjoy! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/__listinfo/erlang-questions +> +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From jesper.louis.andersen at erlang-solutions.com Fri Aug 16 10:01:01 2013 +From: jesper.louis.andersen at erlang-solutions.com (Jesper Louis Andersen) +Date: Fri, 16 Aug 2013 10:01:01 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520CE37E.4090909@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> +Message-ID: + +On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin wrote: + +> I would like to make an official announcement of erlang.mk now that all +> the features I wanted are in. +> + +I have been using erlang.mk for a while now, and recently I converted +etorrent to use it as a test of the viability in larger projects. Typical +gotchas: + +* Projects has no Makefile. erlang.mk needs one. So add one! +* No `modules` section in the .app file. erlang.mk needs one to replace it. +Not adding this makes relx behave badly. +* If you use relx, it is more strict in what it accepts. +* Relx can't yet overlay sys.config :/ + +Apart from that, erlang.mk is a bliss to work with. In one project I am +working with: + +Core i5 2.4Ghz approx 2010 Macbook Pro, encrypted disk (this hurts +performance like mad): + +Cold build: + +Rebar: 40 secs +elrang.mk: 42 secs + +Build where each file is compiled in advance: + +Rebar: 20 secs +erlang.mk: 0.4 secs + +For my development cycle, this is important enough to spend time rewriting +projects to use erlang.mk. Also note that rebar.config and erlang.mk can +co-exist, so you don't need to abandon rebar for erlang.mk, which is +important. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From bchesneau at gmail.com Fri Aug 16 10:39:27 2013 +From: bchesneau at gmail.com (Benoit Chesneau) +Date: Fri, 16 Aug 2013 10:39:27 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520CE37E.4090909@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> +Message-ID: + +The big problem with erlang.mk is requiring to have gmake and more +importantly wget installed imo. + +Which makes it quite annoying to distribute on systems that have none of +them. It would be interrestin to have the support for curl for example. +Also what are the makefile extensions that you really need to require gmake? + +- benoit + + +On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin wrote: + +> Hello friendly people, +> +> I would like to make an official announcement of erlang.mk now that all +> the features I wanted are in. +> +> erlang.mk is a rebar replacement. It was initially created for allowing a +> faster development process than rebar and for better compatibility with +> Linux build tools. It should work on Linux and OSX with GNU Make installed. +> +> Projects using erlang.mk are still compatible with rebar. Dependencies +> fetched by rebar are stored in the same deps/ directory, and projects using +> erlang.mk can still be used as rebar dependencies, with or without a +> rebar.config file. +> +> erlang.mk also features a simple package index. Try `make pkg-list` to +> list all packages currently available. All the packages listed are +> compatible with erlang.mk with no tweaking required. +> +> Makefiles written with erlang.mk are *VERY* simple, here are two examples: +> +> * https://github.com/extend/**farwest/blob/master/Makefile +> * https://github.com/extend/**cowboy/blob/master/Makefile +> +> I wrote about erlang.mk and relx recently on the Nine Nines blog. +> erlang.mk is the perfect companion to relx. +> +> * http://ninenines.eu/articles/**erlang.mk-and-relx +> +> Here are examples of projects that are using and compatible with erlang.mk +> : +> +> * https://github.com/jlouis/**etorrent +> * https://github.com/extend/**cowboy +> * https://github.com/extend/**farwest +> +> You can find erlang.mk at the following URL: +> +> * https://github.com/extend/**erlang.mk +> +> Contributions to the package index are of course welcome! The only +> requirement is that the package is to be compatible with erlang.mkitself. Just send a PR to the +> erlang.mk project updating the packages.v1.txt! +> +> Enjoy! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/**listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From dronnikov at gmail.com Fri Aug 16 13:25:20 2013 +From: dronnikov at gmail.com (Vladimir Dronnikov) +Date: Fri, 16 Aug 2013 15:25:20 +0400 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: +References: <520CE37E.4090909@ninenines.eu> + +Message-ID: + +I believe +curl -L $(PKG_FILE_URL) >$(PKG_FILE) +is kinda drop-in replacement for +wget -O $(PKG_FILE) $(PKG_FILE_URL) +used in erlang.mk. + +Should be tested + + +On Fri, Aug 16, 2013 at 12:39 PM, Benoit Chesneau wrote: + +> The big problem with erlang.mk is requiring to have gmake and more +> importantly wget installed imo. +> +> Which makes it quite annoying to distribute on systems that have none of +> them. It would be interrestin to have the support for curl for example. +> Also what are the makefile extensions that you really need to require gmake? +> +> - benoit +> +> +> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin wrote: +> +>> Hello friendly people, +>> +>> I would like to make an official announcement of erlang.mk now that all +>> the features I wanted are in. +>> +>> erlang.mk is a rebar replacement. It was initially created for allowing +>> a faster development process than rebar and for better compatibility with +>> Linux build tools. It should work on Linux and OSX with GNU Make installed. +>> +>> Projects using erlang.mk are still compatible with rebar. Dependencies +>> fetched by rebar are stored in the same deps/ directory, and projects using +>> erlang.mk can still be used as rebar dependencies, with or without a +>> rebar.config file. +>> +>> erlang.mk also features a simple package index. Try `make pkg-list` to +>> list all packages currently available. All the packages listed are +>> compatible with erlang.mk with no tweaking required. +>> +>> Makefiles written with erlang.mk are *VERY* simple, here are two +>> examples: +>> +>> * https://github.com/extend/**farwest/blob/master/Makefile +>> * https://github.com/extend/**cowboy/blob/master/Makefile +>> +>> I wrote about erlang.mk and relx recently on the Nine Nines blog. +>> erlang.mk is the perfect companion to relx. +>> +>> * http://ninenines.eu/articles/**erlang.mk-and-relx +>> +>> Here are examples of projects that are using and compatible with +>> erlang.mk: +>> +>> * https://github.com/jlouis/**etorrent +>> * https://github.com/extend/**cowboy +>> * https://github.com/extend/**farwest +>> +>> You can find erlang.mk at the following URL: +>> +>> * https://github.com/extend/**erlang.mk +>> +>> Contributions to the package index are of course welcome! The only +>> requirement is that the package is to be compatible with erlang.mkitself. Just send a PR to the +>> erlang.mk project updating the packages.v1.txt! +>> +>> Enjoy! +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> ______________________________**_________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/**listinfo/erlang-questions +>> +> +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From steve at srstrong.com Fri Aug 16 14:27:48 2013 +From: steve at srstrong.com (Steve Strong) +Date: Fri, 16 Aug 2013 14:27:48 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520CE37E.4090909@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> +Message-ID: <05C075301D714F86AD3DF71B5DE6A0C0@srstrong.com> + +Looks good - I like simple! Quick question, does it support multiple applications, for example a project laid out as: + +/proj +/deps +/stuff + +/apps +/app1 +/app2 + +Most of our stuff is in that form, with shared dependencies between the various apps. Rebar is quite happy with that format, but I can't see how to persuade erlang.mk to handle that. + +Cheers, + +Steve + +-- +Steve Strong +Sent with Sparrow (http://www.sparrowmailapp.com/?sig) + + +On Thursday, 15 August 2013 at 16:19, Lo?c Hoguin wrote: + +> Hello friendly people, +> +> I would like to make an official announcement of erlang.mk now that all +> the features I wanted are in. +> +> erlang.mk is a rebar replacement. It was initially created for allowing +> a faster development process than rebar and for better compatibility +> with Linux build tools. It should work on Linux and OSX with GNU Make +> installed. +> +> Projects using erlang.mk are still compatible with rebar. Dependencies +> fetched by rebar are stored in the same deps/ directory, and projects +> using erlang.mk can still be used as rebar dependencies, with or without +> a rebar.config file. +> +> erlang.mk also features a simple package index. Try `make pkg-list` to +> list all packages currently available. All the packages listed are +> compatible with erlang.mk with no tweaking required. +> +> Makefiles written with erlang.mk are *VERY* simple, here are two examples: +> +> * https://github.com/extend/farwest/blob/master/Makefile +> * https://github.com/extend/cowboy/blob/master/Makefile +> +> I wrote about erlang.mk and relx recently on the Nine Nines blog. +> erlang.mk is the perfect companion to relx. +> +> * http://ninenines.eu/articles/erlang.mk-and-relx +> +> Here are examples of projects that are using and compatible with erlang.mk: +> +> * https://github.com/jlouis/etorrent +> * https://github.com/extend/cowboy +> * https://github.com/extend/farwest +> +> You can find erlang.mk at the following URL: +> +> * https://github.com/extend/erlang.mk +> +> Contributions to the package index are of course welcome! The only +> requirement is that the package is to be compatible with erlang.mk +> itself. Just send a PR to the erlang.mk project updating the +> packages.v1.txt! +> +> Enjoy! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org (mailto:erlang-questions at erlang.org) +> http://erlang.org/mailman/listinfo/erlang-questions +> +> + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From list1 at gjunka.com Fri Aug 16 16:42:28 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Fri, 16 Aug 2013 15:42:28 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E3890.5020000@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> +Message-ID: <520E3A54.7040208@gjunka.com> + +Why not use Erlang for downloading? Surely if erlang.mk is a tool for +Erlang then it will be very likely installed. For example this target +downloads Rebar: + +# Erlang Rebar downloading, see: +# +https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y +rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar +./rebar: +$(ERL) -noshell -s inets -s ssl \ +-eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, +"./rebar"}])' \ +-s init stop +chmod +x ./rebar +REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk +'{ print $$NF }') + + +It could be used to download anything, not just REBAR. + +- Greg + + +On 16/08/2013 15:34, Lo?c Hoguin wrote: +> On 08/16/2013 10:39 AM, Benoit Chesneau wrote: +>> The big problem with erlang.mk is requiring to have +>> gmake and more importantly wget installed imo. +> +> wget is only used for fetching the package index file. I'm sure if it +> doesn't work somewhere it'll be patched eventually. +> +>> Which makes it quite annoying to distribute on systems that have none of +>> them. It would be interrestin to have the support for curl for example. +>> Also what are the makefile extensions that you really need to require +>> gmake? +> +> No idea. Patches are welcome for compatibility with different OS/build +> tools (as long as it's not "rewrite the whole file" of course, then +> you're better off just using gmake). +> +>> - benoit +>> +>> +>> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin > > wrote: +>> +>> Hello friendly people, +>> +>> I would like to make an official announcement of erlang.mk +>> now that all the features I wanted are in. +>> +>> erlang.mk is a rebar replacement. It was +>> initially created for allowing a faster development process than +>> rebar and for better compatibility with Linux build tools. It should +>> work on Linux and OSX with GNU Make installed. +>> +>> Projects using erlang.mk are still compatible +>> with rebar. Dependencies fetched by rebar are stored in the same +>> deps/ directory, and projects using erlang.mk can +>> still be used as rebar dependencies, with or without a rebar.config +>> file. +>> +>> erlang.mk also features a simple package index. +>> Try `make pkg-list` to list all packages currently available. All +>> the packages listed are compatible with erlang.mk +>> with no tweaking required. +>> +>> Makefiles written with erlang.mk are *VERY* +>> simple, here are two examples: +>> +>> * https://github.com/extend/__farwest/blob/master/Makefile +>> +>> * https://github.com/extend/__cowboy/blob/master/Makefile +>> +>> +>> I wrote about erlang.mk and relx recently on the +>> Nine Nines blog. erlang.mk is the perfect +>> companion to relx. +>> +>> * http://ninenines.eu/articles/__erlang.mk-and-relx +>> +>> +>> Here are examples of projects that are using and compatible with +>> erlang.mk : +>> +>> * https://github.com/jlouis/__etorrent +>> +>> * https://github.com/extend/__cowboy +>> +>> * https://github.com/extend/__farwest +>> +>> +>> You can find erlang.mk at the following URL: +>> +>> * https://github.com/extend/__erlang.mk +>> +>> +>> Contributions to the package index are of course welcome! The only +>> requirement is that the package is to be compatible with erlang.mk +>> itself. Just send a PR to the erlang.mk +>> project updating the packages.v1.txt! +>> +>> Enjoy! +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _________________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/__listinfo/erlang-questions +>> +>> +>> +> +> + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Aug 16 16:42:39 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 16 Aug 2013 16:42:39 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <05C075301D714F86AD3DF71B5DE6A0C0@srstrong.com> +References: <520CE37E.4090909@ninenines.eu> + <05C075301D714F86AD3DF71B5DE6A0C0@srstrong.com> +Message-ID: <520E3A5F.7000800@ninenines.eu> + +Well I'm sure if you create a base Makefile (without erlang.mk) that +exports DEPS_DIR and then call $(MAKE) on all folders in /apps (which +would themselves contain Makefiles that use erlang.mk), it would work +just fine. You can still keep only one erlang.mk in your repos and use +include ../../erlang.mk instead for example. + +But know that this folder structure is a rebar thing and not standard +(just like /deps you'll say, but that one is insanely useful regardless +of the project structure otherwise). + +On 08/16/2013 02:27 PM, Steve Strong wrote: +> Looks good - I like simple! Quick question, does it support multiple +> applications, for example a project laid out as: +> +> /proj +> /deps +> /stuff +> +> /apps +> /app1 +> /app2 +> +> Most of our stuff is in that form, with shared dependencies between the +> various apps. Rebar is quite happy with that format, but I can't see +> how to persuade erlang.mk to handle that. +> +> Cheers, +> +> Steve +> +> -- +> Steve Strong +> Sent with Sparrow +> +> On Thursday, 15 August 2013 at 16:19, Lo?c Hoguin wrote: +> +>> Hello friendly people, +>> +>> I would like to make an official announcement of erlang.mk now that all +>> the features I wanted are in. +>> +>> erlang.mk is a rebar replacement. It was initially created for allowing +>> a faster development process than rebar and for better compatibility +>> with Linux build tools. It should work on Linux and OSX with GNU Make +>> installed. +>> +>> Projects using erlang.mk are still compatible with rebar. Dependencies +>> fetched by rebar are stored in the same deps/ directory, and projects +>> using erlang.mk can still be used as rebar dependencies, with or without +>> a rebar.config file. +>> +>> erlang.mk also features a simple package index. Try `make pkg-list` to +>> list all packages currently available. All the packages listed are +>> compatible with erlang.mk with no tweaking required. +>> +>> Makefiles written with erlang.mk are *VERY* simple, here are two examples: +>> +>> * https://github.com/extend/farwest/blob/master/Makefile +>> * https://github.com/extend/cowboy/blob/master/Makefile +>> +>> I wrote about erlang.mk and relx recently on the Nine Nines blog. +>> erlang.mk is the perfect companion to relx. +>> +>> * http://ninenines.eu/articles/erlang.mk-and-relx +>> +>> Here are examples of projects that are using and compatible with +>> erlang.mk: +>> +>> * https://github.com/jlouis/etorrent +>> * https://github.com/extend/cowboy +>> * https://github.com/extend/farwest +>> +>> You can find erlang.mk at the following URL: +>> +>> * https://github.com/extend/erlang.mk +>> +>> Contributions to the package index are of course welcome! The only +>> requirement is that the package is to be compatible with erlang.mk +>> itself. Just send a PR to the erlang.mk project updating the +>> packages.v1.txt! +>> +>> Enjoy! +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/listinfo/erlang-questions +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Aug 16 16:44:58 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 16 Aug 2013 16:44:58 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E3A54.7040208@gjunka.com> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> +Message-ID: <520E3AEA.2070402@ninenines.eu> + +Starting Erlang takes too long. That's a big reason why erlang.mk was +created. :) + +I recall NetBSD being able to download things with a shell script only +(as it comes with nothing installed), this would be a more interesting +solution especially since we can bundle it in the erlang.mk file too. + +On 08/16/2013 04:42 PM, Grzegorz Junka wrote: +> Why not use Erlang for downloading? Surely if erlang.mk is a tool for +> Erlang then it will be very likely installed. For example this target +> downloads Rebar: +> +> # Erlang Rebar downloading, see: +> # +> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y +> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar +> ./rebar: +> $(ERL) -noshell -s inets -s ssl \ +> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, +> "./rebar"}])' \ +> -s init stop +> chmod +x ./rebar +> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk +> '{ print $$NF }') +> +> +> It could be used to download anything, not just REBAR. +> +> - Greg +> +> +> On 16/08/2013 15:34, Lo?c Hoguin wrote: +>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote: +>>> The big problem with erlang.mk is requiring to have +>>> gmake and more importantly wget installed imo. +>> +>> wget is only used for fetching the package index file. I'm sure if it +>> doesn't work somewhere it'll be patched eventually. +>> +>>> Which makes it quite annoying to distribute on systems that have none of +>>> them. It would be interrestin to have the support for curl for example. +>>> Also what are the makefile extensions that you really need to require +>>> gmake? +>> +>> No idea. Patches are welcome for compatibility with different OS/build +>> tools (as long as it's not "rewrite the whole file" of course, then +>> you're better off just using gmake). +>> +>>> - benoit +>>> +>>> +>>> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin >> > wrote: +>>> +>>> Hello friendly people, +>>> +>>> I would like to make an official announcement of erlang.mk +>>> now that all the features I wanted are in. +>>> +>>> erlang.mk is a rebar replacement. It was +>>> initially created for allowing a faster development process than +>>> rebar and for better compatibility with Linux build tools. It should +>>> work on Linux and OSX with GNU Make installed. +>>> +>>> Projects using erlang.mk are still compatible +>>> with rebar. Dependencies fetched by rebar are stored in the same +>>> deps/ directory, and projects using erlang.mk can +>>> still be used as rebar dependencies, with or without a rebar.config +>>> file. +>>> +>>> erlang.mk also features a simple package index. +>>> Try `make pkg-list` to list all packages currently available. All +>>> the packages listed are compatible with erlang.mk +>>> with no tweaking required. +>>> +>>> Makefiles written with erlang.mk are *VERY* +>>> simple, here are two examples: +>>> +>>> * https://github.com/extend/__farwest/blob/master/Makefile +>>> +>>> * https://github.com/extend/__cowboy/blob/master/Makefile +>>> +>>> +>>> I wrote about erlang.mk and relx recently on the +>>> Nine Nines blog. erlang.mk is the perfect +>>> companion to relx. +>>> +>>> * http://ninenines.eu/articles/__erlang.mk-and-relx +>>> +>>> +>>> Here are examples of projects that are using and compatible with +>>> erlang.mk : +>>> +>>> * https://github.com/jlouis/__etorrent +>>> +>>> * https://github.com/extend/__cowboy +>>> +>>> * https://github.com/extend/__farwest +>>> +>>> +>>> You can find erlang.mk at the following URL: +>>> +>>> * https://github.com/extend/__erlang.mk +>>> +>>> +>>> Contributions to the package index are of course welcome! The only +>>> requirement is that the package is to be compatible with erlang.mk +>>> itself. Just send a PR to the erlang.mk +>>> project updating the packages.v1.txt! +>>> +>>> Enjoy! +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>>> _________________________________________________ +>>> erlang-questions mailing list +>>> erlang-questions at erlang.org +>>> http://erlang.org/mailman/__listinfo/erlang-questions +>>> +>>> +>>> +>> +>> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From steve at srstrong.com Fri Aug 16 16:44:07 2013 +From: steve at srstrong.com (Steve Strong) +Date: Fri, 16 Aug 2013 16:44:07 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E3A5F.7000800@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> + <05C075301D714F86AD3DF71B5DE6A0C0@srstrong.com> + <520E3A5F.7000800@ninenines.eu> +Message-ID: <4BEA9D47600B462DAAA7D339E9AE47B5@srstrong.com> + +Was guessing that was the answer - I'll give it a go... + +-- +Steve Strong +Sent with Sparrow (http://www.sparrowmailapp.com/?sig) + + +On Friday, 16 August 2013 at 16:42, Lo?c Hoguin wrote: + +> Well I'm sure if you create a base Makefile (without erlang.mk) that +> exports DEPS_DIR and then call $(MAKE) on all folders in /apps (which +> would themselves contain Makefiles that use erlang.mk), it would work +> just fine. You can still keep only one erlang.mk in your repos and use +> include ../../erlang.mk instead for example. +> +> But know that this folder structure is a rebar thing and not standard +> (just like /deps you'll say, but that one is insanely useful regardless +> of the project structure otherwise). +> +> On 08/16/2013 02:27 PM, Steve Strong wrote: +> > Looks good - I like simple! Quick question, does it support multiple +> > applications, for example a project laid out as: +> > +> > /proj +> > /deps +> > /stuff +> > +> > /apps +> > /app1 +> > /app2 +> > +> > Most of our stuff is in that form, with shared dependencies between the +> > various apps. Rebar is quite happy with that format, but I can't see +> > how to persuade erlang.mk to handle that. +> > +> > Cheers, +> > +> > Steve +> > +> > -- +> > Steve Strong +> > Sent with Sparrow +> > +> > On Thursday, 15 August 2013 at 16:19, Lo?c Hoguin wrote: +> > +> > > Hello friendly people, +> > > +> > > I would like to make an official announcement of erlang.mk now that all +> > > the features I wanted are in. +> > > +> > > erlang.mk is a rebar replacement. It was initially created for allowing +> > > a faster development process than rebar and for better compatibility +> > > with Linux build tools. It should work on Linux and OSX with GNU Make +> > > installed. +> > > +> > > Projects using erlang.mk are still compatible with rebar. Dependencies +> > > fetched by rebar are stored in the same deps/ directory, and projects +> > > using erlang.mk can still be used as rebar dependencies, with or without +> > > a rebar.config file. +> > > +> > > erlang.mk also features a simple package index. Try `make pkg-list` to +> > > list all packages currently available. All the packages listed are +> > > compatible with erlang.mk with no tweaking required. +> > > +> > > Makefiles written with erlang.mk are *VERY* simple, here are two examples: +> > > +> > > * https://github.com/extend/farwest/blob/master/Makefile +> > > * https://github.com/extend/cowboy/blob/master/Makefile +> > > +> > > I wrote about erlang.mk and relx recently on the Nine Nines blog. +> > > erlang.mk is the perfect companion to relx. +> > > +> > > * http://ninenines.eu/articles/erlang.mk-and-relx +> > > +> > > Here are examples of projects that are using and compatible with +> > > erlang.mk: +> > > +> > > * https://github.com/jlouis/etorrent +> > > * https://github.com/extend/cowboy +> > > * https://github.com/extend/farwest +> > > +> > > You can find erlang.mk at the following URL: +> > > +> > > * https://github.com/extend/erlang.mk +> > > +> > > Contributions to the package index are of course welcome! The only +> > > requirement is that the package is to be compatible with erlang.mk +> > > itself. Just send a PR to the erlang.mk project updating the +> > > packages.v1.txt! +> > > +> > > Enjoy! +> > > +> > > -- +> > > Lo?c Hoguin +> > > Erlang Cowboy +> > > Nine Nines +> > > http://ninenines.eu +> > > _______________________________________________ +> > > erlang-questions mailing list +> > > erlang-questions at erlang.org +> > > http://erlang.org/mailman/listinfo/erlang-questions +> > > +> > +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From list1 at gjunka.com Fri Aug 16 17:02:00 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Fri, 16 Aug 2013 16:02:00 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E3AEA.2070402@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> + <520E3AEA.2070402@ninenines.eu> +Message-ID: <520E3EE8.70303@gjunka.com> + +But it "is only used for fetching the package index file"... :) If the +target is up to date there is no starting of Erlang. But on the other +hand it could be used conditionally, e.g. use wget on systems on which +it is installed and Erlang otherwise. It's just down to creating a +properly structured target, isn't? + +On 16/08/2013 15:44, Lo?c Hoguin wrote: +> Starting Erlang takes too long. That's a big reason why erlang.mk was +> created. :) +> +> I recall NetBSD being able to download things with a shell script only +> (as it comes with nothing installed), this would be a more interesting +> solution especially since we can bundle it in the erlang.mk file too. +> +> On 08/16/2013 04:42 PM, Grzegorz Junka wrote: +>> Why not use Erlang for downloading? Surely if erlang.mk is a tool for +>> Erlang then it will be very likely installed. For example this target +>> downloads Rebar: +>> +>> # Erlang Rebar downloading, see: +>> # +>> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y +>> +>> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar +>> ./rebar: +>> $(ERL) -noshell -s inets -s ssl \ +>> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, +>> "./rebar"}])' \ +>> -s init stop +>> chmod +x ./rebar +>> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk +>> '{ print $$NF }') +>> +>> +>> It could be used to download anything, not just REBAR. +>> +>> - Greg +>> +>> +>> On 16/08/2013 15:34, Lo?c Hoguin wrote: +>>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote: +>>>> The big problem with erlang.mk is requiring to have +>>>> gmake and more importantly wget installed imo. +>>> +>>> wget is only used for fetching the package index file. I'm sure if it +>>> doesn't work somewhere it'll be patched eventually. +>>> +>>>> Which makes it quite annoying to distribute on systems that have +>>>> none of +>>>> them. It would be interrestin to have the support for curl for +>>>> example. +>>>> Also what are the makefile extensions that you really need to require +>>>> gmake? +>>> +>>> No idea. Patches are welcome for compatibility with different OS/build +>>> tools (as long as it's not "rewrite the whole file" of course, then +>>> you're better off just using gmake). +>>> +>>>> - benoit +>>>> +>>>> +>>>> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin >>> > wrote: +>>>> +>>>> Hello friendly people, +>>>> +>>>> I would like to make an official announcement of erlang.mk +>>>> now that all the features I wanted are in. +>>>> +>>>> erlang.mk is a rebar replacement. It was +>>>> initially created for allowing a faster development process than +>>>> rebar and for better compatibility with Linux build tools. It +>>>> should +>>>> work on Linux and OSX with GNU Make installed. +>>>> +>>>> Projects using erlang.mk are still compatible +>>>> with rebar. Dependencies fetched by rebar are stored in the same +>>>> deps/ directory, and projects using erlang.mk +>>>> can +>>>> still be used as rebar dependencies, with or without a +>>>> rebar.config +>>>> file. +>>>> +>>>> erlang.mk also features a simple package index. +>>>> Try `make pkg-list` to list all packages currently available. All +>>>> the packages listed are compatible with erlang.mk +>>>> +>>>> with no tweaking required. +>>>> +>>>> Makefiles written with erlang.mk are *VERY* +>>>> simple, here are two examples: +>>>> +>>>> * https://github.com/extend/__farwest/blob/master/Makefile +>>>> +>>>> * https://github.com/extend/__cowboy/blob/master/Makefile +>>>> +>>>> +>>>> I wrote about erlang.mk and relx recently on +>>>> the +>>>> Nine Nines blog. erlang.mk is the perfect +>>>> companion to relx. +>>>> +>>>> * http://ninenines.eu/articles/__erlang.mk-and-relx +>>>> +>>>> +>>>> Here are examples of projects that are using and compatible with +>>>> erlang.mk : +>>>> +>>>> * https://github.com/jlouis/__etorrent +>>>> +>>>> * https://github.com/extend/__cowboy +>>>> +>>>> * https://github.com/extend/__farwest +>>>> +>>>> +>>>> You can find erlang.mk at the following URL: +>>>> +>>>> * https://github.com/extend/__erlang.mk +>>>> +>>>> +>>>> Contributions to the package index are of course welcome! The only +>>>> requirement is that the package is to be compatible with erlang.mk +>>>> itself. Just send a PR to the erlang.mk +>>>> project updating the packages.v1.txt! +>>>> +>>>> Enjoy! +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>>>> _________________________________________________ +>>>> erlang-questions mailing list +>>>> erlang-questions at erlang.org +>>>> http://erlang.org/mailman/__listinfo/erlang-questions +>>>> +>>>> +>>>> +>>> +>>> +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> + + + +From essen at ninenines.eu Fri Aug 16 17:10:19 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 16 Aug 2013 17:10:19 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E3EE8.70303@gjunka.com> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> + <520E3AEA.2070402@ninenines.eu> <520E3EE8.70303@gjunka.com> +Message-ID: <520E40DB.5070401@ninenines.eu> + +I know, and if it makes it work where it currently doesn't I'd merge it. +But ultimately we want to avoid starting Erlang unless strictly necessary. + +On 08/16/2013 05:02 PM, Grzegorz Junka wrote: +> But it "is only used for fetching the package index file"... :) If the +> target is up to date there is no starting of Erlang. But on the other +> hand it could be used conditionally, e.g. use wget on systems on which +> it is installed and Erlang otherwise. It's just down to creating a +> properly structured target, isn't? +> +> On 16/08/2013 15:44, Lo?c Hoguin wrote: +>> Starting Erlang takes too long. That's a big reason why erlang.mk was +>> created. :) +>> +>> I recall NetBSD being able to download things with a shell script only +>> (as it comes with nothing installed), this would be a more interesting +>> solution especially since we can bundle it in the erlang.mk file too. +>> +>> On 08/16/2013 04:42 PM, Grzegorz Junka wrote: +>>> Why not use Erlang for downloading? Surely if erlang.mk is a tool for +>>> Erlang then it will be very likely installed. For example this target +>>> downloads Rebar: +>>> +>>> # Erlang Rebar downloading, see: +>>> # +>>> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y +>>> +>>> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar +>>> ./rebar: +>>> $(ERL) -noshell -s inets -s ssl \ +>>> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, +>>> "./rebar"}])' \ +>>> -s init stop +>>> chmod +x ./rebar +>>> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk +>>> '{ print $$NF }') +>>> +>>> +>>> It could be used to download anything, not just REBAR. +>>> +>>> - Greg +>>> +>>> +>>> On 16/08/2013 15:34, Lo?c Hoguin wrote: +>>>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote: +>>>>> The big problem with erlang.mk is requiring to have +>>>>> gmake and more importantly wget installed imo. +>>>> +>>>> wget is only used for fetching the package index file. I'm sure if it +>>>> doesn't work somewhere it'll be patched eventually. +>>>> +>>>>> Which makes it quite annoying to distribute on systems that have +>>>>> none of +>>>>> them. It would be interrestin to have the support for curl for +>>>>> example. +>>>>> Also what are the makefile extensions that you really need to require +>>>>> gmake? +>>>> +>>>> No idea. Patches are welcome for compatibility with different OS/build +>>>> tools (as long as it's not "rewrite the whole file" of course, then +>>>> you're better off just using gmake). +>>>> +>>>>> - benoit +>>>>> +>>>>> +>>>>> On Thu, Aug 15, 2013 at 4:19 PM, Lo?c Hoguin >>>> > wrote: +>>>>> +>>>>> Hello friendly people, +>>>>> +>>>>> I would like to make an official announcement of erlang.mk +>>>>> now that all the features I wanted are in. +>>>>> +>>>>> erlang.mk is a rebar replacement. It was +>>>>> initially created for allowing a faster development process than +>>>>> rebar and for better compatibility with Linux build tools. It +>>>>> should +>>>>> work on Linux and OSX with GNU Make installed. +>>>>> +>>>>> Projects using erlang.mk are still compatible +>>>>> with rebar. Dependencies fetched by rebar are stored in the same +>>>>> deps/ directory, and projects using erlang.mk +>>>>> can +>>>>> still be used as rebar dependencies, with or without a +>>>>> rebar.config +>>>>> file. +>>>>> +>>>>> erlang.mk also features a simple package index. +>>>>> Try `make pkg-list` to list all packages currently available. All +>>>>> the packages listed are compatible with erlang.mk +>>>>> +>>>>> with no tweaking required. +>>>>> +>>>>> Makefiles written with erlang.mk are *VERY* +>>>>> simple, here are two examples: +>>>>> +>>>>> * https://github.com/extend/__farwest/blob/master/Makefile +>>>>> +>>>>> * https://github.com/extend/__cowboy/blob/master/Makefile +>>>>> +>>>>> +>>>>> I wrote about erlang.mk and relx recently on +>>>>> the +>>>>> Nine Nines blog. erlang.mk is the perfect +>>>>> companion to relx. +>>>>> +>>>>> * http://ninenines.eu/articles/__erlang.mk-and-relx +>>>>> +>>>>> +>>>>> Here are examples of projects that are using and compatible with +>>>>> erlang.mk : +>>>>> +>>>>> * https://github.com/jlouis/__etorrent +>>>>> +>>>>> * https://github.com/extend/__cowboy +>>>>> +>>>>> * https://github.com/extend/__farwest +>>>>> +>>>>> +>>>>> You can find erlang.mk at the following URL: +>>>>> +>>>>> * https://github.com/extend/__erlang.mk +>>>>> +>>>>> +>>>>> Contributions to the package index are of course welcome! The only +>>>>> requirement is that the package is to be compatible with erlang.mk +>>>>> itself. Just send a PR to the erlang.mk +>>>>> project updating the packages.v1.txt! +>>>>> +>>>>> Enjoy! +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> Erlang Cowboy +>>>>> Nine Nines +>>>>> http://ninenines.eu +>>>>> _________________________________________________ +>>>>> erlang-questions mailing list +>>>>> erlang-questions at erlang.org +>>>>> http://erlang.org/mailman/__listinfo/erlang-questions +>>>>> +>>>>> +>>>>> +>>>> +>>>> +>>> +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +>> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From wbin00 at gmail.com Fri Aug 16 17:40:22 2013 +From: wbin00 at gmail.com (Bin Wang) +Date: Fri, 16 Aug 2013 23:40:22 +0800 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E40DB.5070401@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> + <520E3AEA.2070402@ninenines.eu> <520E3EE8.70303@gjunka.com> + <520E40DB.5070401@ninenines.eu> +Message-ID: + +Will it support protobuf(https://github.com/basho/erlang_protobuffs), +I cannot compile *.proto file from src/ with erlang.mk. + + +From essen at ninenines.eu Fri Aug 16 17:55:30 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 16 Aug 2013 17:55:30 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> + <520E3AEA.2070402@ninenines.eu> <520E3EE8.70303@gjunka.com> + <520E40DB.5070401@ninenines.eu> + +Message-ID: <520E4B72.8010608@ninenines.eu> + +On 08/16/2013 05:40 PM, Bin Wang wrote: +> Will it support protobuf(https://github.com/basho/erlang_protobuffs), +> I cannot compile *.proto file from src/ with erlang.mk. + +That's a good question. I probably would merge such a patch right now, +but if it ends up being too many different compilers we'll probably need +a better solution (something like having you include both erlang.mk and +protobuffs.mk to enable it?). + +I don't use protobuffs myself so don't count on me though. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From jeremy at quarkgames.com Fri Aug 16 18:29:36 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Fri, 16 Aug 2013 09:29:36 -0700 +Subject: [99s-extend] [erlang-questions] [ANN] erlang.mk build tool +In-Reply-To: <520E4B72.8010608@ninenines.eu> +References: <520CE37E.4090909@ninenines.eu> + + <520E3890.5020000@ninenines.eu> <520E3A54.7040208@gjunka.com> + <520E3AEA.2070402@ninenines.eu> <520E3EE8.70303@gjunka.com> + <520E40DB.5070401@ninenines.eu> + + <520E4B72.8010608@ninenines.eu> +Message-ID: + +I'd prefer it if there were more generalized hooks for files of +different names rather than hardcoding usage of a particular library. +In the case of protobuffers, some people use piqi, others use basho's +library, and still others use their own library. + +On Fri, Aug 16, 2013 at 8:55 AM, Lo?c Hoguin wrote: +> On 08/16/2013 05:40 PM, Bin Wang wrote: +>> +>> Will it support protobuf(https://github.com/basho/erlang_protobuffs), +>> I cannot compile *.proto file from src/ with erlang.mk. +> +> +> That's a good question. I probably would merge such a patch right now, but +> if it ends up being too many different compilers we'll probably need a +> better solution (something like having you include both erlang.mk and +> protobuffs.mk to enable it?). +> +> I don't use protobuffs myself so don't count on me though. +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From wbin00 at gmail.com Sat Aug 17 10:00:04 2013 +From: wbin00 at gmail.com (Bin Wang) +Date: Sat, 17 Aug 2013 16:00:04 +0800 +Subject: [99s-extend] How to broadcaset with ranch? +Message-ID: + +Hi, + +I'm new to ranch. In my application, I need to send some message to +all connections. So I'd like to know can I get all connections from +ranch, so I could use Transport:send to send them, or I must manage +all the created connections by myself? Or is there any other better +way? + +Thanks. + +Bin Wang + + +From essen at ninenines.eu Sat Aug 17 10:10:41 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sat, 17 Aug 2013 10:10:41 +0200 +Subject: [99s-extend] How to broadcaset with ranch? +In-Reply-To: +References: +Message-ID: <520F3001.5010504@ninenines.eu> + +On 08/17/2013 10:00 AM, Bin Wang wrote: +> Hi, +> +> I'm new to ranch. In my application, I need to send some message to +> all connections. So I'd like to know can I get all connections from +> ranch, so I could use Transport:send to send them, or I must manage +> all the created connections by myself? Or is there any other better +> way? + +The best way to do that is on your end, using gproc properties. When the +connection is accepted, register the process with the property and use +the property to send messages to all processes. You don't need to +unregister when the connection ends, gproc does that automatically. + +The hackish way to do that would be to call supervisor:which_children on +the ranch_conns_sup supervisor of your listener, but that will slow down +the accepting of new connections, so don't do this if you need high +accept rates. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From seancribbs at gmail.com Wed Aug 21 05:18:19 2013 +From: seancribbs at gmail.com (Sean Cribbs) +Date: Tue, 20 Aug 2013 22:18:19 -0500 +Subject: [99s-extend] [erlang-questions] How to broadcaset with ranch? +In-Reply-To: <520F3001.5010504@ninenines.eu> +References: + <520F3001.5010504@ninenines.eu> +Message-ID: + +This is exactly the sort of thing gen_event is for. I would make each +server process register a handler at startup using +gen_event:add_sup_handler() and then have the handle_event callback simply +relay the event to the server processes. Yes, gproc can do this, but why +incur its extra features and overhead? + + +On Sat, Aug 17, 2013 at 3:10 AM, Lo?c Hoguin wrote: + +> On 08/17/2013 10:00 AM, Bin Wang wrote: +> +>> Hi, +>> +>> I'm new to ranch. In my application, I need to send some message to +>> all connections. So I'd like to know can I get all connections from +>> ranch, so I could use Transport:send to send them, or I must manage +>> all the created connections by myself? Or is there any other better +>> way? +>> +> +> The best way to do that is on your end, using gproc properties. When the +> connection is accepted, register the process with the property and use the +> property to send messages to all processes. You don't need to unregister +> when the connection ends, gproc does that automatically. +> +> The hackish way to do that would be to call supervisor:which_children on +> the ranch_conns_sup supervisor of your listener, but that will slow down +> the accepting of new connections, so don't do this if you need high accept +> rates. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> ______________________________**_________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/**listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-August/000176.html b/_build/static/archives/extend/2013-August/000176.html new file mode 100644 index 00000000..cbbe96ab --- /dev/null +++ b/_build/static/archives/extend/2013-August/000176.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:01:26 CEST 2013 +

+
+ +
The extend projets are great and very popular, they need to have each
+one a different mailing list.
+
+And mailman has a really useless web interface.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000177.html b/_build/static/archives/extend/2013-August/000177.html new file mode 100644 index 00000000..cf868ba2 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000177.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:06:42 CEST 2013 +

+
+ +
I love the farwest technical choices. But Riak seems to only be the
+"prototype' database, and PostgreSQL the real target.
+
+FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+want Riak, who really wants PostgresSQL ??
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000178.html b/_build/static/archives/extend/2013-August/000178.html new file mode 100644 index 00000000..5083ed82 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000178.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:08:47 CEST 2013 +

+
+ +
Please tell us what you think makes Riak superior.
+
+On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+> I love the farwest technical choices. But Riak seems to only be the
+> "prototype' database, and PostgreSQL the real target.
+>
+> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+> want Riak, who really wants PostgresSQL ??
+>
+> Florent
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000179.html b/_build/static/archives/extend/2013-August/000179.html new file mode 100644 index 00000000..ed0bf2c0 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000179.html @@ -0,0 +1,73 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:09:58 CEST 2013 +

+
+ +
On 08/02/2013 05:01 PM, Florent Gallaire wrote:
+> The extend projets are great and very popular, they need to have each
+> one a different mailing list.
+
+That would be true if there was actual activity on the mailing lists. 
+There isn't.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000180.html b/_build/static/archives/extend/2013-August/000180.html new file mode 100644 index 00000000..e949c4d6 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000180.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:14:00 CEST 2013 +

+
+ +
On Fri, Aug 2, 2013 at 5:09 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> On 08/02/2013 05:01 PM, Florent Gallaire wrote:
+>>
+>> The extend projets are great and very popular, they need to have each
+>> one a different mailing list.
+>
+>
+> That would be true if there was actual activity on the mailing lists. There
+> isn't.
+
+There is no activity because Mailman is useless.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawye
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000181.html b/_build/static/archives/extend/2013-August/000181.html new file mode 100644 index 00000000..ce4c1fc2 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000181.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Fri Aug 2 17:20:05 CEST 2013 +

+
+ +
It's a bit like comparing sports cars to superbikes.  Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc.  Plus, it's built on Erlang :-)  PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc.  Each has their place.  For typical websites, PostgreSQL is the better choice.  For distributed applications, Riak is often the better choice. ***
+
+Lee 
+
+*** Mostly my opinion, only.
+
+
+
+On 2 Aug 2013, at 16:08, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Please tell us what you think makes Riak superior.
+> 
+> On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+>> I love the farwest technical choices. But Riak seems to only be the
+>> "prototype' database, and PostgreSQL the real target.
+>> 
+>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+>> want Riak, who really wants PostgresSQL ??
+>> 
+>> Florent
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000182.html b/_build/static/archives/extend/2013-August/000182.html new file mode 100644 index 00000000..18e0a832 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000182.html @@ -0,0 +1,88 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:21:39 CEST 2013 +

+
+ +
On 08/02/2013 05:14 PM, Florent Gallaire wrote:
+> On Fri, Aug 2, 2013 at 5:09 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> On 08/02/2013 05:01 PM, Florent Gallaire wrote:
+>>>
+>>> The extend projets are great and very popular, they need to have each
+>>> one a different mailing list.
+>>
+>>
+>> That would be true if there was actual activity on the mailing lists. There
+>> isn't.
+>
+> There is no activity because Mailman is useless.
+
+I said no activity, I didn't say no members. Please keep your complaints 
+about the tool down, it's got nothing to do with it, and you just end up 
+spamming people here.
+
+All development happens on IRC, so this leaves the mailing lists only 
+useful for questions, which should be rarer over time considering the 
+docs keep improving and the archives provide great answers for the rest. 
+It's all good.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000183.html b/_build/static/archives/extend/2013-August/000183.html new file mode 100644 index 00000000..156bb411 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000183.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:25:22 CEST 2013 +

+
+ +
On Fri, Aug 2, 2013 at 5:08 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> Please tell us what you think makes Riak superior.
+
+Riak is written in Erlang. See your own argumentations on why Erlang
+is the best langage to program high load/fault-tolerent web software.
+
+Riak is written in Erlang, as all the 99 other soft -> good
+integration of the whole.
+
+Riak is a NoSQL Dynamo database with Availability and Partition
+tolerance, and this is what I want for my web applications. PostgreSQL
+is a SQL Availability and Consistency old school database.
+
+Riak is just what want a developer who use erlang to have a scaling platform.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000184.html b/_build/static/archives/extend/2013-August/000184.html new file mode 100644 index 00000000..6d1e2ff4 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000184.html @@ -0,0 +1,103 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Fri Aug 2 17:29:35 CEST 2013 +

+
+ +
Postgres has been made to scale well in GIS applications.  Apple is using Postgres for their current Maps geo point storage.  
+
+On Aug 2, 2013, at 11:20 AM, "Lee Sylvester" <lee.sylvester at gmail.com> wrote:
+
+> It's a bit like comparing sports cars to superbikes.  Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc.  Plus, it's built on Erlang :-)  PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc.  Each has their place.  For typical websites, PostgreSQL is the better choice.  For distributed applications, Riak is often the better choice. ***
+> 
+> Lee 
+> 
+> *** Mostly my opinion, only.
+> 
+> 
+> 
+> On 2 Aug 2013, at 16:08, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+>> Please tell us what you think makes Riak superior.
+>> 
+>> On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+>>> I love the farwest technical choices. But Riak seems to only be the
+>>> "prototype' database, and PostgreSQL the real target.
+>>> 
+>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+>>> want Riak, who really wants PostgresSQL ??
+>>> 
+>>> Florent
+>> 
+>> 
+>> -- 
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000185.html b/_build/static/archives/extend/2013-August/000185.html new file mode 100644 index 00000000..2c2f697b --- /dev/null +++ b/_build/static/archives/extend/2013-August/000185.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:33:32 CEST 2013 +

+
+ +
> I said no activity, I didn't say no members. Please keep your complaints
+> about the tool down, it's got nothing to do with it, and you just end up
+> spamming people here.
+>
+> All development happens on IRC, so this leaves the mailing lists only useful
+> for questions, which should be rarer over time considering the docs keep
+> improving and the archives provide great answers for the rest. It's all
+> good.
+
+I don't agree. More you have users, more you should have questions on
+the mailing list, even if the documentation is improving.
+
+I'm on the mailing lists of **a lot** of free software with great
+documentations, and they are very active.
+
+Where is the history of the choices/debates made on IRC ?
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000186.html b/_build/static/archives/extend/2013-August/000186.html new file mode 100644 index 00000000..12b8019e --- /dev/null +++ b/_build/static/archives/extend/2013-August/000186.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Fri Aug 2 17:33:53 CEST 2013 +

+
+ +
NoSQL is a trend, but is often not the best choice for data storage.  The reason it has had a strong revival recently (no, NoSQL is not a new thing) is because it is simpler for non-SQL developers to jump into and requires less thought on structuring your data.  However, there are many scenarios where NoSQL is a bad choice.  For example, I would certainly hope my bank doesn't log my transactions using NoSQL!
+
+Lee
+
+
+
+
+On 2 Aug 2013, at 16:25, Florent Gallaire <fgallaire at gmail.com> wrote:
+
+> On Fri, Aug 2, 2013 at 5:08 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> Please tell us what you think makes Riak superior.
+> 
+> Riak is written in Erlang. See your own argumentations on why Erlang
+> is the best langage to program high load/fault-tolerent web software.
+> 
+> Riak is written in Erlang, as all the 99 other soft -> good
+> integration of the whole.
+> 
+> Riak is a NoSQL Dynamo database with Availability and Partition
+> tolerance, and this is what I want for my web applications. PostgreSQL
+> is a SQL Availability and Consistency old school database.
+> 
+> Riak is just what want a developer who use erlang to have a scaling platform.
+> 
+> Florent
+> 
+> -- 
+> FLOSS Engineer & Lawyer
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000187.html b/_build/static/archives/extend/2013-August/000187.html new file mode 100644 index 00000000..42fc23ef --- /dev/null +++ b/_build/static/archives/extend/2013-August/000187.html @@ -0,0 +1,124 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:35:13 CEST 2013 +

+
+ +
Let me clarify a few misconceptions here. (Mostly to show the choice 
+isn't random, don't take it wrong.)
+
+Riak and Riak CS are two different things. You most likely don't want to 
+run them together, especially considering the hardware requirements will 
+differ.
+
+Riak core, pipes, etc. are not really useful if you only use Riak as a 
+data store. It's cool that your DB has a great distributed processing 
+framework but pretty useless when you just want to retrieve some data 
+and format it in a web page.
+
+Riak has clustering, yes. PostgreSQL has clustering too.
+
+Riak has data-center aware clustering also if you get Riak Enterprise. 
+But it costs a lot (per node!). You can do the same with PostgreSQL at a 
+fraction of the price.
+
+Riak is built on Erlang, sure. But why should I care? I only want it to 
+handle my data. I don't want to look at the code. PostgreSQL is a much 
+proven piece of software.
+
+On 08/02/2013 05:20 PM, Lee Sylvester wrote:
+> It's a bit like comparing sports cars to superbikes.  Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc.  Plus, it's built on Erlang :-)  PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc.  Each has their place.  For typical websites, PostgreSQL is the better choice.  For distributed applications, Riak is often the better choice. ***
+>
+> Lee
+>
+> *** Mostly my opinion, only.
+>
+>
+>
+> On 2 Aug 2013, at 16:08, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> Please tell us what you think makes Riak superior.
+>>
+>> On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+>>> I love the farwest technical choices. But Riak seems to only be the
+>>> "prototype' database, and PostgreSQL the real target.
+>>>
+>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+>>> want Riak, who really wants PostgresSQL ??
+>>>
+>>> Florent
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000188.html b/_build/static/archives/extend/2013-August/000188.html new file mode 100644 index 00000000..cf612c6a --- /dev/null +++ b/_build/static/archives/extend/2013-August/000188.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:35:58 CEST 2013 +

+
+ +
> For example, I would certainly hope my bank doesn't log my transactions using NoSQL!
+
+You're right, but is Farwest designed to develop banf software ? I
+don't think so.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000189.html b/_build/static/archives/extend/2013-August/000189.html new file mode 100644 index 00000000..1ecda7d4 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000189.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:39:04 CEST 2013 +

+
+ +
> PostgreSQL is a much proven piece of software.
+
+Ouch !! And Apache is a much proven piece of software than cowboy, why
+don't use it for Farwest ?
+
+Florent
+
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000190.html b/_build/static/archives/extend/2013-August/000190.html new file mode 100644 index 00000000..e08b6ac5 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000190.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:39:58 CEST 2013 +

+
+ +
On 08/02/2013 05:25 PM, Florent Gallaire wrote:
+> On Fri, Aug 2, 2013 at 5:08 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> Please tell us what you think makes Riak superior.
+>
+> Riak is written in Erlang. See your own argumentations on why Erlang
+> is the best langage to program high load/fault-tolerent web software.
+ >
+> Riak is written in Erlang, as all the 99 other soft -> good
+> integration of the whole.
+
+See the post I just sent. I have no reason to care about the language 
+here. It's not going to run in the same node. I'm not going to look at 
+it. And PostgreSQL is a much proven software, much more than Riak who's 
+had issues with the Erlang schedulers and more and is still young.
+
+> Riak is a NoSQL Dynamo database with Availability and Partition
+> tolerance, and this is what I want for my web applications. PostgreSQL
+> is a SQL Availability and Consistency old school database.
+
+The need for partitioning comes a *lot* later for SQL databases. They 
+can deal with big amounts of data just fine. And Farwest is made for 
+small to medium applications, therefore the issue will likely never come 
+up until Farwest itself becomes the issue.
+
+> Riak is just what want a developer who use erlang to have a scaling platform.
+
+This is the first time I hear complaints about choosing PostgreSQL.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000191.html b/_build/static/archives/extend/2013-August/000191.html new file mode 100644 index 00000000..7f3c02b3 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000191.html @@ -0,0 +1,75 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:41:39 CEST 2013 +

+
+ +
On 08/02/2013 05:39 PM, Florent Gallaire wrote:
+>> PostgreSQL is a much proven piece of software.
+>
+> Ouch !! And Apache is a much proven piece of software than cowboy, why
+> don't use it for Farwest ?
+
+Because CGI, PHP, Perl, ... aren't. But you can put Apache in front of 
+Farwest just fine if you need to.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000192.html b/_build/static/archives/extend/2013-August/000192.html new file mode 100644 index 00000000..4af73b25 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000192.html @@ -0,0 +1,125 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Fri Aug 2 17:43:49 CEST 2013 +

+
+ +
Hey, don't direct that at me :-S  I was agreeing with you :-D
+
+The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better.  I'd much rather the dynamo model than a master-to-many slaves model.
+
+Lee
+
+
+
+On 2 Aug 2013, at 16:35, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Let me clarify a few misconceptions here. (Mostly to show the choice isn't random, don't take it wrong.)
+> 
+> Riak and Riak CS are two different things. You most likely don't want to run them together, especially considering the hardware requirements will differ.
+> 
+> Riak core, pipes, etc. are not really useful if you only use Riak as a data store. It's cool that your DB has a great distributed processing framework but pretty useless when you just want to retrieve some data and format it in a web page.
+> 
+> Riak has clustering, yes. PostgreSQL has clustering too.
+> 
+> Riak has data-center aware clustering also if you get Riak Enterprise. But it costs a lot (per node!). You can do the same with PostgreSQL at a fraction of the price.
+> 
+> Riak is built on Erlang, sure. But why should I care? I only want it to handle my data. I don't want to look at the code. PostgreSQL is a much proven piece of software.
+> 
+> On 08/02/2013 05:20 PM, Lee Sylvester wrote:
+>> It's a bit like comparing sports cars to superbikes.  Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc.  Plus, it's built on Erlang :-)  PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc.  Each has their place.  For typical websites, PostgreSQL is the better choice.  For distributed applications, Riak is often the better choice. ***
+>> 
+>> Lee
+>> 
+>> *** Mostly my opinion, only.
+>> 
+>> 
+>> 
+>> On 2 Aug 2013, at 16:08, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> 
+>>> Please tell us what you think makes Riak superior.
+>>> 
+>>> On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+>>>> I love the farwest technical choices. But Riak seems to only be the
+>>>> "prototype' database, and PostgreSQL the real target.
+>>>> 
+>>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+>>>> want Riak, who really wants PostgresSQL ??
+>>>> 
+>>>> Florent
+>>>> 
+>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000193.html b/_build/static/archives/extend/2013-August/000193.html new file mode 100644 index 00000000..c07d2343 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000193.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:45:07 CEST 2013 +

+
+ +
On 08/02/2013 05:33 PM, Florent Gallaire wrote:
+> Where is the history of the choices/debates made on IRC ?
+
+No such thing. No need for it either, the choices tend to change a few 
+times until things stabilize.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000194.html b/_build/static/archives/extend/2013-August/000194.html new file mode 100644 index 00000000..02e314f3 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000194.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:46:53 CEST 2013 +

+
+ +
> The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better.  I'd much rather the dynamo model than a master-to-many slaves model.
+
+Yes you're right, all clustering are far to be equal. Dynamo is really
+great, and master-to-master is just an archaic way to do things you
+don't really know to do.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000195.html b/_build/static/archives/extend/2013-August/000195.html new file mode 100644 index 00000000..d7878ba2 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000195.html @@ -0,0 +1,138 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:47:39 CEST 2013 +

+
+ +
I know, hence the "don't take it wrong".
+
+You have a few different projects enabling multi-master replication for 
+PostgreSQL. It's not an issue.
+
+On 08/02/2013 05:43 PM, Lee Sylvester wrote:
+> Hey, don't direct that at me :-S  I was agreeing with you :-D
+>
+> The only point I would differ with (and I may be wrong, as it was about 12 months ago that I researched this) is that I do feel, for clustering, that Riak does it better.  I'd much rather the dynamo model than a master-to-many slaves model.
+>
+> Lee
+>
+>
+>
+> On 2 Aug 2013, at 16:35, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> Let me clarify a few misconceptions here. (Mostly to show the choice isn't random, don't take it wrong.)
+>>
+>> Riak and Riak CS are two different things. You most likely don't want to run them together, especially considering the hardware requirements will differ.
+>>
+>> Riak core, pipes, etc. are not really useful if you only use Riak as a data store. It's cool that your DB has a great distributed processing framework but pretty useless when you just want to retrieve some data and format it in a web page.
+>>
+>> Riak has clustering, yes. PostgreSQL has clustering too.
+>>
+>> Riak has data-center aware clustering also if you get Riak Enterprise. But it costs a lot (per node!). You can do the same with PostgreSQL at a fraction of the price.
+>>
+>> Riak is built on Erlang, sure. But why should I care? I only want it to handle my data. I don't want to look at the code. PostgreSQL is a much proven piece of software.
+>>
+>> On 08/02/2013 05:20 PM, Lee Sylvester wrote:
+>>> It's a bit like comparing sports cars to superbikes.  Riak has some very powerful features; Pipes, true clustering, fault tolerance, Riak CS etc.  Plus, it's built on Erlang :-)  PostgreSQL has SQL queries, real tables (rather than simple corruptible namespacing), complex query capabilities, real data types etc.  Each has their place.  For typical websites, PostgreSQL is the better choice.  For distributed applications, Riak is often the better choice. ***
+>>>
+>>> Lee
+>>>
+>>> *** Mostly my opinion, only.
+>>>
+>>>
+>>>
+>>> On 2 Aug 2013, at 16:08, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>>> Please tell us what you think makes Riak superior.
+>>>>
+>>>> On 08/02/2013 05:06 PM, Florent Gallaire wrote:
+>>>>> I love the farwest technical choices. But Riak seems to only be the
+>>>>> "prototype' database, and PostgreSQL the real target.
+>>>>>
+>>>>> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+>>>>> want Riak, who really wants PostgresSQL ??
+>>>>>
+>>>>> Florent
+>>>>>
+>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000196.html b/_build/static/archives/extend/2013-August/000196.html new file mode 100644 index 00000000..7ffec33b --- /dev/null +++ b/_build/static/archives/extend/2013-August/000196.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:49:00 CEST 2013 +

+
+ +
> No such thing. No need for it either, the choices tend to change a few times
+> until things stabilize.
+
+This is a really wrong way. Free software needs public transparency.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000197.html b/_build/static/archives/extend/2013-August/000197.html new file mode 100644 index 00000000..d1fb8f7c --- /dev/null +++ b/_build/static/archives/extend/2013-August/000197.html @@ -0,0 +1,74 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 2 17:50:32 CEST 2013 +

+
+ +
On 08/02/2013 05:49 PM, Florent Gallaire wrote:
+>> No such thing. No need for it either, the choices tend to change a few times
+>> until things stabilize.
+>
+> This is a really wrong way. Free software needs public transparency.
+
+The regular contributors don't seem to complain.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000198.html b/_build/static/archives/extend/2013-August/000198.html new file mode 100644 index 00000000..983a31f8 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000198.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Fri Aug 2 17:52:17 CEST 2013 +

+
+ +
Public transparency like a public IRC channel anyone can join and log?
+
+On Fri, Aug 2, 2013, at 08:49 AM, Florent Gallaire wrote:
+> > No such thing. No need for it either, the choices tend to change a few times
+> > until things stabilize.
+> 
+> This is a really wrong way. Free software needs public transparency.
+> 
+> Florent
+> 
+> -- 
+> FLOSS Engineer & Lawyer
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000199.html b/_build/static/archives/extend/2013-August/000199.html new file mode 100644 index 00000000..5ca7ad4f --- /dev/null +++ b/_build/static/archives/extend/2013-August/000199.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Fri Aug 2 17:54:34 CEST 2013 +

+
+ +
On Fri, Aug 2, 2013 at 5:52 PM, Tristan Sloughter
+<tristan.sloughter at gmail.com> wrote:
+> Public transparency like a public IRC channel anyone can join and log?
+
+Haha, what a joke. It's a pity you don't understand that.
+
+Florent
+
+-- 
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000200.html b/_build/static/archives/extend/2013-August/000200.html new file mode 100644 index 00000000..2588a151 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000200.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Riak in Farwest + + + + + + + + + + +

[99s-extend] Riak in Farwest

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Fri Aug 2 17:54:38 CEST 2013 +

+
+ +
Me for one. Rarely have a use case that fits Riak but daily have use
+cases that fit a RDBMS, and Postgres is the best of those in my opinion.
+
+On Fri, Aug 2, 2013, at 08:06 AM, Florent Gallaire wrote:
+> I love the farwest technical choices. But Riak seems to only be the
+> "prototype' database, and PostgreSQL the real target.
+> 
+> FMO, this is a huge fail. Riak is by far superior to PostgreSQL. I
+> want Riak, who really wants PostgresSQL ??
+> 
+> Florent
+> 
+> -- 
+> FLOSS Engineer & Lawyer
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000201.html b/_build/static/archives/extend/2013-August/000201.html new file mode 100644 index 00000000..74d6f410 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000201.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Jeremy Ong + jeremy at quarkgames.com +
+ Fri Aug 2 21:33:59 CEST 2013 +

+
+ +
Florent, I suggest you actually contribute something before telling
+the project maintainer how to run things and flaming people who *have*
+contributed.
+
+On Fri, Aug 2, 2013 at 8:54 AM, Florent Gallaire <fgallaire at gmail.com> wrote:
+> On Fri, Aug 2, 2013 at 5:52 PM, Tristan Sloughter
+> <tristan.sloughter at gmail.com> wrote:
+>> Public transparency like a public IRC channel anyone can join and log?
+>
+> Haha, what a joke. It's a pity you don't understand that.
+>
+> Florent
+>
+> --
+> FLOSS Engineer & Lawyer
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000202.html b/_build/static/archives/extend/2013-August/000202.html new file mode 100644 index 00000000..4796fdb9 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000202.html @@ -0,0 +1,92 @@ + + + + [99s-extend] Fwd: Mailing lists + + + + + + + + + + +

[99s-extend] Fwd: Mailing lists

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Fri Aug 2 21:57:22 CEST 2013 +

+
+ +
Forgot to reply to all
+
+---------- Forwarded message ----------
+From: Eduardo Gurgel <edgurgel at gmail.com>
+Date: Fri, Aug 2, 2013 at 4:57 PM
+Subject: Re: [99s-extend] Mailing lists
+To: Jeremy Ong <jeremy at quarkgames.com>
+
+
+
+
+On Fri, Aug 2, 2013 at 4:33 PM, Jeremy Ong <jeremy at quarkgames.com> wrote:
+
+> Florent, I suggest you actually contribute something before telling
+> the project maintainer how to run things and flaming people who *have*
+> contributed.
+>
+
+Agreed.
+
+Too much pointing finger on this thread...
+
+-- 
+Eduardo
+
+
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130802/4f7baee0/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000203.html b/_build/static/archives/extend/2013-August/000203.html new file mode 100644 index 00000000..2fd2c210 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000203.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Florent Gallaire + fgallaire at gmail.com +
+ Sat Aug 3 00:16:30 CEST 2013 +

+
+ +
> Florent, I suggest you actually contribute something before telling
+> the project maintainer how to run things and flaming people who *have*
+> contributed.
+
+Jeremy, I tried to test farwest very early :
+https://github.com/extend/farwest/pull/4
+
+My "bad idee" of a server-sent events handler is now part of bullet :
+https://github.com/extend/bullet/issues/16
+
+Jeremy, maybe I haven't contribute something on this project because :
+- I spend a lot of time working as a lawyer
+- I spend a lot of time working on other free software
+- I'm not yet a great Erlang programmer
+
+AND
+
+- There's no visibility on what is really doing, and who is doing it,
+and why, and how it's decided. So I can't lose more time on that
+because I can't know what is happened and what will happen.
+
+I flame nobody. I give the 2 cents of help I can give. This is a
+contribution. You can think it's useless, but I don't think so.
+
+In free software, if you want a great success, you should be more open
+that just have a free software licence.
+You should do the life easier for the people interested in this
+project and who want to help. You can think it's not a problem, but I
+think it is. Is that a flame ?
+
+Florent
+
+FLOSS Engineer & Lawyer
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000204.html b/_build/static/archives/extend/2013-August/000204.html new file mode 100644 index 00000000..a14ebf64 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000204.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Aug 3 09:13:50 CEST 2013 +

+
+ +
On 08/03/2013 12:16 AM, Florent Gallaire wrote:
+> - There's no visibility on what is really doing, and who is doing it,
+> and why, and how it's decided. So I can't lose more time on that
+> because I can't know what is happened and what will happen.
+
+Or, you know, you could just open a ticket or ask like anyone else, 
+preferrably the former. Chances are whatever you're thinking of doing 
+has no chance of being merged at all, or could be interesting but only 
+if certain implementation details are respected, or needs to involve 
+other people.
+
+Even if we did put more info on who does what, this still wouldn't 
+remove the necessity for you to ask if you want to avoid losing your time.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000205.html b/_build/static/archives/extend/2013-August/000205.html new file mode 100644 index 00000000..08815b3f --- /dev/null +++ b/_build/static/archives/extend/2013-August/000205.html @@ -0,0 +1,75 @@ + + + + [99s-extend] Mailing lists + + + + + + + + + + +

[99s-extend] Mailing lists

+ Bach Le + thebullno1 at gmail.com +
+ Mon Aug 5 07:38:04 CEST 2013 +

+
+ +
>You can think it's not a problem, but Ithink it is. Is that a flame ?
+This is a flame:
+> Haha, what a joke. It's a pity you don't understand that.
+
+I for one, prefer Postgres. Not everything can be mapped to kv and that's
+the only thing Riak is good for. It's not fit for a general purpose
+database.
+To me, NoSQL is about specialization. Each db excels at one type of
+operation (and then there's mongo, but that's for another time), while
+RDBMSs offer general purpose solutions. I begin my projects with an RDBMS
+(usually Postgres) and when a particular piece of data is the bottleneck, I
+move it to the appropriate NoSQL db.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130805/9fd5783b/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000206.html b/_build/static/archives/extend/2013-August/000206.html new file mode 100644 index 00000000..018540f7 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000206.html @@ -0,0 +1,82 @@ + + + + [99s-extend] [ANN] Farwest 0.3.0 + + + + + + + + + + +

[99s-extend] [ANN] Farwest 0.3.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 14 19:50:18 CEST 2013 +

+
+ +
It's finally here!
+
+  *  https://github.com/extend/farwest/
+
+It's still a mess in the two other repositories so I recommend waiting 
+before digging in too much. This is just a direct port of the prototype 
+to a more workable build suite and repository structure.
+
+  *  https://github.com/extend/farwest_core/
+  *  https://github.com/extend/farwest_ui/
+
+A lot of work will be done on farwest_core next, while at the same time 
+the frontend dude takes care of making the UI good.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000207.html b/_build/static/archives/extend/2013-August/000207.html new file mode 100644 index 00000000..8d079aa6 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000207.html @@ -0,0 +1,112 @@ + + + + [99s-extend] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Aug 15 16:19:42 CEST 2013 +

+
+ +
Hello friendly people,
+
+I would like to make an official announcement of erlang.mk now that all 
+the features I wanted are in.
+
+erlang.mk is a rebar replacement. It was initially created for allowing 
+a faster development process than rebar and for better compatibility 
+with Linux build tools. It should work on Linux and OSX with GNU Make 
+installed.
+
+Projects using erlang.mk are still compatible with rebar. Dependencies 
+fetched by rebar are stored in the same deps/ directory, and projects 
+using erlang.mk can still be used as rebar dependencies, with or without 
+a rebar.config file.
+
+erlang.mk also features a simple package index. Try `make pkg-list` to 
+list all packages currently available. All the packages listed are 
+compatible with erlang.mk with no tweaking required.
+
+Makefiles written with erlang.mk are *VERY* simple, here are two examples:
+
+  *  https://github.com/extend/farwest/blob/master/Makefile
+  *  https://github.com/extend/cowboy/blob/master/Makefile
+
+I wrote about erlang.mk and relx recently on the Nine Nines blog. 
+erlang.mk is the perfect companion to relx.
+
+  *  http://ninenines.eu/articles/erlang.mk-and-relx
+
+Here are examples of projects that are using and compatible with erlang.mk:
+
+  *  https://github.com/jlouis/etorrent
+  *  https://github.com/extend/cowboy
+  *  https://github.com/extend/farwest
+
+You can find erlang.mk at the following URL:
+
+  *  https://github.com/extend/erlang.mk
+
+Contributions to the package index are of course welcome! The only 
+requirement is that the package is to be compatible with erlang.mk 
+itself. Just send a PR to the erlang.mk project updating the 
+packages.v1.txt!
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000208.html b/_build/static/archives/extend/2013-August/000208.html new file mode 100644 index 00000000..a35bd15c --- /dev/null +++ b/_build/static/archives/extend/2013-August/000208.html @@ -0,0 +1,80 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Motiejus Jakštys + desired.mta at gmail.com +
+ Thu Aug 15 17:07:42 CEST 2013 +

+
+ +
On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> Hello friendly people,
+>
+> I would like to make an official announcement of erlang.mk now that all the
+> features I wanted are in.
+
+Please include an ability to cleanly override any target so make does
+not emit warnings about overwritten target. There are a few ways to do
+it, but I find this the easiest: prefix every target in erlang.mk with
+a variable:
+
+$(.erlang-mk-all)all:
+  <your stuff>
+
+That way, if $(.erlang-mk-all) is defined (from my application
+Makefile before including erlang.mk), your 'all' target will be the
+one that does not cause me warnings.
+
+Motiejus Jakštys
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000209.html b/_build/static/archives/extend/2013-August/000209.html new file mode 100644 index 00000000..fd92b4a5 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000209.html @@ -0,0 +1,88 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Aug 15 18:32:04 CEST 2013 +

+
+ +
On 08/15/2013 05:07 PM, Motiejus Jakštys wrote:
+> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> Hello friendly people,
+>>
+>> I would like to make an official announcement of erlang.mk now that all the
+>> features I wanted are in.
+>
+> Please include an ability to cleanly override any target so make does
+> not emit warnings about overwritten target. There are a few ways to do
+> it, but I find this the easiest: prefix every target in erlang.mk with
+> a variable:
+>
+> $(.erlang-mk-all)all:
+>    <your stuff>
+>
+> That way, if $(.erlang-mk-all) is defined (from my application
+> Makefile before including erlang.mk), your 'all' target will be the
+> one that does not cause me warnings.
+
+Yes I was thinking about this, but so far nobody needed it. If you do, 
+though, patches welcome!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000210.html b/_build/static/archives/extend/2013-August/000210.html new file mode 100644 index 00000000..adbce1a3 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000210.html @@ -0,0 +1,159 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 16 16:34:56 CEST 2013 +

+
+ +
On 08/16/2013 10:39 AM, Benoit Chesneau wrote:
+> The big problem with erlang.mk <http://erlang.mk> is requiring to have
+> gmake and more importantly wget installed imo.
+
+wget is only used for fetching the package index file. I'm sure if it 
+doesn't work somewhere it'll be patched eventually.
+
+> Which makes it quite annoying to distribute on systems that have none of
+> them. It would be interrestin to have the support for curl for example.
+> Also what are the makefile extensions that you really need to require gmake?
+
+No idea. Patches are welcome for compatibility with different OS/build 
+tools (as long as it's not "rewrite the whole file" of course, then 
+you're better off just using gmake).
+
+> - benoit
+>
+>
+> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Hello friendly people,
+>
+>     I would like to make an official announcement of erlang.mk
+>     <http://erlang.mk> now that all the features I wanted are in.
+>
+>     erlang.mk <http://erlang.mk> is a rebar replacement. It was
+>     initially created for allowing a faster development process than
+>     rebar and for better compatibility with Linux build tools. It should
+>     work on Linux and OSX with GNU Make installed.
+>
+>     Projects using erlang.mk <http://erlang.mk> are still compatible
+>     with rebar. Dependencies fetched by rebar are stored in the same
+>     deps/ directory, and projects using erlang.mk <http://erlang.mk> can
+>     still be used as rebar dependencies, with or without a rebar.config
+>     file.
+>
+>     erlang.mk <http://erlang.mk> also features a simple package index.
+>     Try `make pkg-list` to list all packages currently available. All
+>     the packages listed are compatible with erlang.mk <http://erlang.mk>
+>     with no tweaking required.
+>
+>     Makefiles written with erlang.mk <http://erlang.mk> are *VERY*
+>     simple, here are two examples:
+>
+>       * https://github.com/extend/__farwest/blob/master/Makefile
+>     <https://github.com/extend/farwest/blob/master/Makefile>
+>       * https://github.com/extend/__cowboy/blob/master/Makefile
+>     <https://github.com/extend/cowboy/blob/master/Makefile>
+>
+>     I wrote about erlang.mk <http://erlang.mk> and relx recently on the
+>     Nine Nines blog. erlang.mk <http://erlang.mk> is the perfect
+>     companion to relx.
+>
+>       * http://ninenines.eu/articles/__erlang.mk-and-relx
+>     <http://ninenines.eu/articles/erlang.mk-and-relx>
+>
+>     Here are examples of projects that are using and compatible with
+>     erlang.mk <http://erlang.mk>:
+>
+>       * https://github.com/jlouis/__etorrent
+>     <https://github.com/jlouis/etorrent>
+>       * https://github.com/extend/__cowboy
+>     <https://github.com/extend/cowboy>
+>       * https://github.com/extend/__farwest
+>     <https://github.com/extend/farwest>
+>
+>     You can find erlang.mk <http://erlang.mk> at the following URL:
+>
+>       * https://github.com/extend/__erlang.mk
+>     <https://github.com/extend/erlang.mk>
+>
+>     Contributions to the package index are of course welcome! The only
+>     requirement is that the package is to be compatible with erlang.mk
+>     <http://erlang.mk> itself. Just send a PR to the erlang.mk
+>     <http://erlang.mk> project updating the packages.v1.txt!
+>
+>     Enjoy!
+>
+>     --
+>     Loïc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>     _________________________________________________
+>     erlang-questions mailing list
+>     erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>     http://erlang.org/mailman/__listinfo/erlang-questions
+>     <http://erlang.org/mailman/listinfo/erlang-questions>
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000211.html b/_build/static/archives/extend/2013-August/000211.html new file mode 100644 index 00000000..28333c39 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000211.html @@ -0,0 +1,99 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Jesper Louis Andersen + jesper.louis.andersen at erlang-solutions.com +
+ Fri Aug 16 10:01:01 CEST 2013 +

+
+ +
On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> I would like to make an official announcement of erlang.mk now that all
+> the features I wanted are in.
+>
+
+I have been using erlang.mk for a while now, and recently I converted
+etorrent to use it as a test of the viability in larger projects. Typical
+gotchas:
+
+* Projects has no Makefile. erlang.mk needs one. So add one!
+* No `modules` section in the .app file. erlang.mk needs one to replace it.
+Not adding this makes relx behave badly.
+* If you use relx, it is more strict in what it accepts.
+* Relx can't yet overlay sys.config :/
+
+Apart from that, erlang.mk is a bliss to work with. In one project I am
+working with:
+
+Core i5 2.4Ghz approx 2010 Macbook Pro, encrypted disk (this hurts
+performance like mad):
+
+Cold build:
+
+Rebar: 40 secs
+elrang.mk: 42 secs
+
+Build where each file is compiled in advance:
+
+Rebar: 20 secs
+erlang.mk: 0.4 secs
+
+For my development cycle, this is important enough to spend time rewriting
+projects to use erlang.mk. Also note that rebar.config and erlang.mk can
+co-exist, so you don't need to abandon rebar for erlang.mk, which is
+important.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/1c70f542/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000212.html b/_build/static/archives/extend/2013-August/000212.html new file mode 100644 index 00000000..45ac7353 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000212.html @@ -0,0 +1,130 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Benoit Chesneau + bchesneau at gmail.com +
+ Fri Aug 16 10:39:27 CEST 2013 +

+
+ +
The big problem with erlang.mk is requiring to have gmake and more
+importantly wget installed imo.
+
+Which makes it quite annoying to distribute on systems that have none of
+them. It would be interrestin to have the support for curl for example.
+Also what are the makefile extensions that you really need to require gmake?
+
+- benoit
+
+
+On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Hello friendly people,
+>
+> I would like to make an official announcement of erlang.mk now that all
+> the features I wanted are in.
+>
+> erlang.mk is a rebar replacement. It was initially created for allowing a
+> faster development process than rebar and for better compatibility with
+> Linux build tools. It should work on Linux and OSX with GNU Make installed.
+>
+> Projects using erlang.mk are still compatible with rebar. Dependencies
+> fetched by rebar are stored in the same deps/ directory, and projects using
+> erlang.mk can still be used as rebar dependencies, with or without a
+> rebar.config file.
+>
+> erlang.mk also features a simple package index. Try `make pkg-list` to
+> list all packages currently available. All the packages listed are
+> compatible with erlang.mk with no tweaking required.
+>
+> Makefiles written with erlang.mk are *VERY* simple, here are two examples:
+>
+>  *  https://github.com/extend/**farwest/blob/master/Makefile<https://github.com/extend/farwest/blob/master/Makefile>
+>  *  https://github.com/extend/**cowboy/blob/master/Makefile<https://github.com/extend/cowboy/blob/master/Makefile>
+>
+> I wrote about erlang.mk and relx recently on the Nine Nines blog.
+> erlang.mk is the perfect companion to relx.
+>
+>  *  http://ninenines.eu/articles/**erlang.mk-and-relx<http://ninenines.eu/articles/erlang.mk-and-relx>
+>
+> Here are examples of projects that are using and compatible with erlang.mk
+> :
+>
+>  *  https://github.com/jlouis/**etorrent<https://github.com/jlouis/etorrent>
+>  *  https://github.com/extend/**cowboy <https://github.com/extend/cowboy>
+>  *  https://github.com/extend/**farwest<https://github.com/extend/farwest>
+>
+> You can find erlang.mk at the following URL:
+>
+>  *  https://github.com/extend/**erlang.mk<https://github.com/extend/erlang.mk>
+>
+> Contributions to the package index are of course welcome! The only
+> requirement is that the package is to be compatible with erlang.mkitself. Just send a PR to the
+> erlang.mk project updating the packages.v1.txt!
+>
+> Enjoy!
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/ff4591a1/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000213.html b/_build/static/archives/extend/2013-August/000213.html new file mode 100644 index 00000000..4e077be1 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000213.html @@ -0,0 +1,150 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Vladimir Dronnikov + dronnikov at gmail.com +
+ Fri Aug 16 13:25:20 CEST 2013 +

+
+ +
I believe
+curl -L $(PKG_FILE_URL) >$(PKG_FILE)
+is kinda drop-in replacement for
+wget -O $(PKG_FILE) $(PKG_FILE_URL)
+used in erlang.mk.
+
+Should be tested
+
+
+On Fri, Aug 16, 2013 at 12:39 PM, Benoit Chesneau <bchesneau at gmail.com>wrote:
+
+> The big problem with erlang.mk is requiring to have gmake and more
+> importantly wget installed imo.
+>
+> Which makes it quite annoying to distribute on systems that have none of
+> them. It would be interrestin to have the support for curl for example.
+> Also what are the makefile extensions that you really need to require gmake?
+>
+> - benoit
+>
+>
+> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> Hello friendly people,
+>>
+>> I would like to make an official announcement of erlang.mk now that all
+>> the features I wanted are in.
+>>
+>> erlang.mk is a rebar replacement. It was initially created for allowing
+>> a faster development process than rebar and for better compatibility with
+>> Linux build tools. It should work on Linux and OSX with GNU Make installed.
+>>
+>> Projects using erlang.mk are still compatible with rebar. Dependencies
+>> fetched by rebar are stored in the same deps/ directory, and projects using
+>> erlang.mk can still be used as rebar dependencies, with or without a
+>> rebar.config file.
+>>
+>> erlang.mk also features a simple package index. Try `make pkg-list` to
+>> list all packages currently available. All the packages listed are
+>> compatible with erlang.mk with no tweaking required.
+>>
+>> Makefiles written with erlang.mk are *VERY* simple, here are two
+>> examples:
+>>
+>>  *  https://github.com/extend/**farwest/blob/master/Makefile<https://github.com/extend/farwest/blob/master/Makefile>
+>>  *  https://github.com/extend/**cowboy/blob/master/Makefile<https://github.com/extend/cowboy/blob/master/Makefile>
+>>
+>> I wrote about erlang.mk and relx recently on the Nine Nines blog.
+>> erlang.mk is the perfect companion to relx.
+>>
+>>  *  http://ninenines.eu/articles/**erlang.mk-and-relx<http://ninenines.eu/articles/erlang.mk-and-relx>
+>>
+>> Here are examples of projects that are using and compatible with
+>> erlang.mk:
+>>
+>>  *  https://github.com/jlouis/**etorrent<https://github.com/jlouis/etorrent>
+>>  *  https://github.com/extend/**cowboy <https://github.com/extend/cowboy>
+>>  *  https://github.com/extend/**farwest<https://github.com/extend/farwest>
+>>
+>> You can find erlang.mk at the following URL:
+>>
+>>  *  https://github.com/extend/**erlang.mk<https://github.com/extend/erlang.mk>
+>>
+>> Contributions to the package index are of course welcome! The only
+>> requirement is that the package is to be compatible with erlang.mkitself. Just send a PR to the
+>> erlang.mk project updating the packages.v1.txt!
+>>
+>> Enjoy!
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> ______________________________**_________________
+>> erlang-questions mailing list
+>> erlang-questions at erlang.org
+>> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>>
+>
+>
+> _______________________________________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/listinfo/erlang-questions
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/8f4a69b4/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000214.html b/_build/static/archives/extend/2013-August/000214.html new file mode 100644 index 00000000..70567a86 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000214.html @@ -0,0 +1,145 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Steve Strong + steve at srstrong.com +
+ Fri Aug 16 14:27:48 CEST 2013 +

+
+ +
Looks good - I like simple!  Quick question, does it support multiple applications, for example a project laid out as:  
+
+/proj
+/deps
+/stuff
+
+/apps
+/app1
+/app2
+
+Most of our stuff is in that form, with shared dependencies between the various apps.  Rebar is quite happy with that format, but I can't see how to persuade erlang.mk to handle that.
+
+Cheers,
+
+Steve  
+
+--  
+Steve Strong
+Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
+
+
+On Thursday, 15 August 2013 at 16:19, Loïc Hoguin wrote:
+
+> Hello friendly people,
+>  
+> I would like to make an official announcement of erlang.mk now that all  
+> the features I wanted are in.
+>  
+> erlang.mk is a rebar replacement. It was initially created for allowing  
+> a faster development process than rebar and for better compatibility  
+> with Linux build tools. It should work on Linux and OSX with GNU Make  
+> installed.
+>  
+> Projects using erlang.mk are still compatible with rebar. Dependencies  
+> fetched by rebar are stored in the same deps/ directory, and projects  
+> using erlang.mk can still be used as rebar dependencies, with or without  
+> a rebar.config file.
+>  
+> erlang.mk also features a simple package index. Try `make pkg-list` to  
+> list all packages currently available. All the packages listed are  
+> compatible with erlang.mk with no tweaking required.
+>  
+> Makefiles written with erlang.mk are *VERY* simple, here are two examples:
+>  
+> * https://github.com/extend/farwest/blob/master/Makefile
+> * https://github.com/extend/cowboy/blob/master/Makefile
+>  
+> I wrote about erlang.mk and relx recently on the Nine Nines blog.  
+> erlang.mk is the perfect companion to relx.
+>  
+> * http://ninenines.eu/articles/erlang.mk-and-relx
+>  
+> Here are examples of projects that are using and compatible with erlang.mk:
+>  
+> * https://github.com/jlouis/etorrent
+> * https://github.com/extend/cowboy
+> * https://github.com/extend/farwest
+>  
+> You can find erlang.mk at the following URL:
+>  
+> * https://github.com/extend/erlang.mk
+>  
+> Contributions to the package index are of course welcome! The only  
+> requirement is that the package is to be compatible with erlang.mk  
+> itself. Just send a PR to the erlang.mk project updating the  
+> packages.v1.txt!
+>  
+> Enjoy!
+>  
+> --  
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org (mailto:erlang-questions at erlang.org)
+> http://erlang.org/mailman/listinfo/erlang-questions
+>  
+>  
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/a886396a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000215.html b/_build/static/archives/extend/2013-August/000215.html new file mode 100644 index 00000000..132a264c --- /dev/null +++ b/_build/static/archives/extend/2013-August/000215.html @@ -0,0 +1,182 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Grzegorz Junka + list1 at gjunka.com +
+ Fri Aug 16 16:42:28 CEST 2013 +

+
+ +
Why not use Erlang for downloading? Surely if erlang.mk is a tool for 
+Erlang then it will be very likely installed. For example this target 
+downloads Rebar:
+
+# Erlang Rebar downloading, see:
+# 
+https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y
+rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar
+./rebar:
+$(ERL) -noshell -s inets -s ssl \
+-eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, 
+"./rebar"}])' \
+-s init stop
+chmod +x ./rebar
+REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk 
+'{ print $$NF }')
+
+
+It could be used to download anything, not just REBAR.
+
+- Greg
+
+
+On 16/08/2013 15:34, Loïc Hoguin wrote:
+> On 08/16/2013 10:39 AM, Benoit Chesneau wrote:
+>> The big problem with erlang.mk <http://erlang.mk> is requiring to have
+>> gmake and more importantly wget installed imo.
+>
+> wget is only used for fetching the package index file. I'm sure if it 
+> doesn't work somewhere it'll be patched eventually.
+>
+>> Which makes it quite annoying to distribute on systems that have none of
+>> them. It would be interrestin to have the support for curl for example.
+>> Also what are the makefile extensions that you really need to require 
+>> gmake?
+>
+> No idea. Patches are welcome for compatibility with different OS/build 
+> tools (as long as it's not "rewrite the whole file" of course, then 
+> you're better off just using gmake).
+>
+>> - benoit
+>>
+>>
+>> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     Hello friendly people,
+>>
+>>     I would like to make an official announcement of erlang.mk
+>>     <http://erlang.mk> now that all the features I wanted are in.
+>>
+>>     erlang.mk <http://erlang.mk> is a rebar replacement. It was
+>>     initially created for allowing a faster development process than
+>>     rebar and for better compatibility with Linux build tools. It should
+>>     work on Linux and OSX with GNU Make installed.
+>>
+>>     Projects using erlang.mk <http://erlang.mk> are still compatible
+>>     with rebar. Dependencies fetched by rebar are stored in the same
+>>     deps/ directory, and projects using erlang.mk <http://erlang.mk> can
+>>     still be used as rebar dependencies, with or without a rebar.config
+>>     file.
+>>
+>>     erlang.mk <http://erlang.mk> also features a simple package index.
+>>     Try `make pkg-list` to list all packages currently available. All
+>>     the packages listed are compatible with erlang.mk <http://erlang.mk>
+>>     with no tweaking required.
+>>
+>>     Makefiles written with erlang.mk <http://erlang.mk> are *VERY*
+>>     simple, here are two examples:
+>>
+>>       * https://github.com/extend/__farwest/blob/master/Makefile
+>> <https://github.com/extend/farwest/blob/master/Makefile>
+>>       * https://github.com/extend/__cowboy/blob/master/Makefile
+>> <https://github.com/extend/cowboy/blob/master/Makefile>
+>>
+>>     I wrote about erlang.mk <http://erlang.mk> and relx recently on the
+>>     Nine Nines blog. erlang.mk <http://erlang.mk> is the perfect
+>>     companion to relx.
+>>
+>>       * http://ninenines.eu/articles/__erlang.mk-and-relx
+>>     <http://ninenines.eu/articles/erlang.mk-and-relx>
+>>
+>>     Here are examples of projects that are using and compatible with
+>>     erlang.mk <http://erlang.mk>:
+>>
+>>       * https://github.com/jlouis/__etorrent
+>>     <https://github.com/jlouis/etorrent>
+>>       * https://github.com/extend/__cowboy
+>>     <https://github.com/extend/cowboy>
+>>       * https://github.com/extend/__farwest
+>>     <https://github.com/extend/farwest>
+>>
+>>     You can find erlang.mk <http://erlang.mk> at the following URL:
+>>
+>>       * https://github.com/extend/__erlang.mk
+>>     <https://github.com/extend/erlang.mk>
+>>
+>>     Contributions to the package index are of course welcome! The only
+>>     requirement is that the package is to be compatible with erlang.mk
+>>     <http://erlang.mk> itself. Just send a PR to the erlang.mk
+>>     <http://erlang.mk> project updating the packages.v1.txt!
+>>
+>>     Enjoy!
+>>
+>>     --
+>>     Loïc Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>     _________________________________________________
+>>     erlang-questions mailing list
+>>     erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>     http://erlang.org/mailman/__listinfo/erlang-questions
+>>     <http://erlang.org/mailman/listinfo/erlang-questions>
+>>
+>>
+>
+>
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/4e596577/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000216.html b/_build/static/archives/extend/2013-August/000216.html new file mode 100644 index 00000000..ef9d2563 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000216.html @@ -0,0 +1,161 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 16 16:42:39 CEST 2013 +

+
+ +
Well I'm sure if you create a base Makefile (without erlang.mk) that 
+exports DEPS_DIR and then call $(MAKE) on all folders in /apps (which 
+would themselves contain Makefiles that use erlang.mk), it would work 
+just fine. You can still keep only one erlang.mk in your repos and use 
+include ../../erlang.mk instead for example.
+
+But know that this folder structure is a rebar thing and not standard 
+(just like /deps you'll say, but that one is insanely useful regardless 
+of the project structure otherwise).
+
+On 08/16/2013 02:27 PM, Steve Strong wrote:
+> Looks good - I like simple!  Quick question, does it support multiple
+> applications, for example a project laid out as:
+>
+> /proj
+> /deps
+> /stuff
+>
+> /apps
+> /app1
+> /app2
+>
+> Most of our stuff is in that form, with shared dependencies between the
+> various apps.  Rebar is quite happy with that format, but I can't see
+> how to persuade erlang.mk to handle that.
+>
+> Cheers,
+>
+> Steve
+>
+> --
+> Steve Strong
+> Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
+>
+> On Thursday, 15 August 2013 at 16:19, Loïc Hoguin wrote:
+>
+>> Hello friendly people,
+>>
+>> I would like to make an official announcement of erlang.mk now that all
+>> the features I wanted are in.
+>>
+>> erlang.mk is a rebar replacement. It was initially created for allowing
+>> a faster development process than rebar and for better compatibility
+>> with Linux build tools. It should work on Linux and OSX with GNU Make
+>> installed.
+>>
+>> Projects using erlang.mk are still compatible with rebar. Dependencies
+>> fetched by rebar are stored in the same deps/ directory, and projects
+>> using erlang.mk can still be used as rebar dependencies, with or without
+>> a rebar.config file.
+>>
+>> erlang.mk also features a simple package index. Try `make pkg-list` to
+>> list all packages currently available. All the packages listed are
+>> compatible with erlang.mk with no tweaking required.
+>>
+>> Makefiles written with erlang.mk are *VERY* simple, here are two examples:
+>>
+>> * https://github.com/extend/farwest/blob/master/Makefile
+>> * https://github.com/extend/cowboy/blob/master/Makefile
+>>
+>> I wrote about erlang.mk and relx recently on the Nine Nines blog.
+>> erlang.mk is the perfect companion to relx.
+>>
+>> * http://ninenines.eu/articles/erlang.mk-and-relx
+>>
+>> Here are examples of projects that are using and compatible with
+>> erlang.mk:
+>>
+>> * https://github.com/jlouis/etorrent
+>> * https://github.com/extend/cowboy
+>> * https://github.com/extend/farwest
+>>
+>> You can find erlang.mk at the following URL:
+>>
+>> * https://github.com/extend/erlang.mk
+>>
+>> Contributions to the package index are of course welcome! The only
+>> requirement is that the package is to be compatible with erlang.mk
+>> itself. Just send a PR to the erlang.mk project updating the
+>> packages.v1.txt!
+>>
+>> Enjoy!
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> erlang-questions mailing list
+>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>> http://erlang.org/mailman/listinfo/erlang-questions
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000217.html b/_build/static/archives/extend/2013-August/000217.html new file mode 100644 index 00000000..3ab448ae --- /dev/null +++ b/_build/static/archives/extend/2013-August/000217.html @@ -0,0 +1,202 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 16 16:44:58 CEST 2013 +

+
+ +
Starting Erlang takes too long. That's a big reason why erlang.mk was 
+created. :)
+
+I recall NetBSD being able to download things with a shell script only 
+(as it comes with nothing installed), this would be a more interesting 
+solution especially since we can bundle it in the erlang.mk file too.
+
+On 08/16/2013 04:42 PM, Grzegorz Junka wrote:
+> Why not use Erlang for downloading? Surely if erlang.mk is a tool for
+> Erlang then it will be very likely installed. For example this target
+> downloads Rebar:
+>
+> # Erlang Rebar downloading, see:
+> #
+> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y
+> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar
+> ./rebar:
+> $(ERL) -noshell -s inets -s ssl \
+> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream,
+> "./rebar"}])' \
+> -s init stop
+> chmod +x ./rebar
+> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk
+> '{ print $$NF }')
+>
+>
+> It could be used to download anything, not just REBAR.
+>
+> - Greg
+>
+>
+> On 16/08/2013 15:34, Loïc Hoguin wrote:
+>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote:
+>>> The big problem with erlang.mk <http://erlang.mk> is requiring to have
+>>> gmake and more importantly wget installed imo.
+>>
+>> wget is only used for fetching the package index file. I'm sure if it
+>> doesn't work somewhere it'll be patched eventually.
+>>
+>>> Which makes it quite annoying to distribute on systems that have none of
+>>> them. It would be interrestin to have the support for curl for example.
+>>> Also what are the makefile extensions that you really need to require
+>>> gmake?
+>>
+>> No idea. Patches are welcome for compatibility with different OS/build
+>> tools (as long as it's not "rewrite the whole file" of course, then
+>> you're better off just using gmake).
+>>
+>>> - benoit
+>>>
+>>>
+>>> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu
+>>> <mailto:essen at ninenines.eu>> wrote:
+>>>
+>>>     Hello friendly people,
+>>>
+>>>     I would like to make an official announcement of erlang.mk
+>>> <http://erlang.mk> now that all the features I wanted are in.
+>>>
+>>>     erlang.mk <http://erlang.mk> is a rebar replacement. It was
+>>>     initially created for allowing a faster development process than
+>>>     rebar and for better compatibility with Linux build tools. It should
+>>>     work on Linux and OSX with GNU Make installed.
+>>>
+>>>     Projects using erlang.mk <http://erlang.mk> are still compatible
+>>>     with rebar. Dependencies fetched by rebar are stored in the same
+>>>     deps/ directory, and projects using erlang.mk <http://erlang.mk> can
+>>>     still be used as rebar dependencies, with or without a rebar.config
+>>>     file.
+>>>
+>>>     erlang.mk <http://erlang.mk> also features a simple package index.
+>>>     Try `make pkg-list` to list all packages currently available. All
+>>>     the packages listed are compatible with erlang.mk <http://erlang.mk>
+>>>     with no tweaking required.
+>>>
+>>>     Makefiles written with erlang.mk <http://erlang.mk> are *VERY*
+>>>     simple, here are two examples:
+>>>
+>>>       * https://github.com/extend/__farwest/blob/master/Makefile
+>>> <https://github.com/extend/farwest/blob/master/Makefile>
+>>>       * https://github.com/extend/__cowboy/blob/master/Makefile
+>>> <https://github.com/extend/cowboy/blob/master/Makefile>
+>>>
+>>>     I wrote about erlang.mk <http://erlang.mk> and relx recently on the
+>>>     Nine Nines blog. erlang.mk <http://erlang.mk> is the perfect
+>>>     companion to relx.
+>>>
+>>>       * http://ninenines.eu/articles/__erlang.mk-and-relx
+>>> <http://ninenines.eu/articles/erlang.mk-and-relx>
+>>>
+>>>     Here are examples of projects that are using and compatible with
+>>>     erlang.mk <http://erlang.mk>:
+>>>
+>>>       * https://github.com/jlouis/__etorrent
+>>> <https://github.com/jlouis/etorrent>
+>>>       * https://github.com/extend/__cowboy
+>>> <https://github.com/extend/cowboy>
+>>>       * https://github.com/extend/__farwest
+>>> <https://github.com/extend/farwest>
+>>>
+>>>     You can find erlang.mk <http://erlang.mk> at the following URL:
+>>>
+>>>       * https://github.com/extend/__erlang.mk
+>>> <https://github.com/extend/erlang.mk>
+>>>
+>>>     Contributions to the package index are of course welcome! The only
+>>>     requirement is that the package is to be compatible with erlang.mk
+>>> <http://erlang.mk> itself. Just send a PR to the erlang.mk
+>>> <http://erlang.mk> project updating the packages.v1.txt!
+>>>
+>>>     Enjoy!
+>>>
+>>>     --
+>>>     Loïc Hoguin
+>>>     Erlang Cowboy
+>>>     Nine Nines
+>>> http://ninenines.eu
+>>>     _________________________________________________
+>>>     erlang-questions mailing list
+>>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>> http://erlang.org/mailman/__listinfo/erlang-questions
+>>> <http://erlang.org/mailman/listinfo/erlang-questions>
+>>>
+>>>
+>>
+>>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000218.html b/_build/static/archives/extend/2013-August/000218.html new file mode 100644 index 00000000..23de61be --- /dev/null +++ b/_build/static/archives/extend/2013-August/000218.html @@ -0,0 +1,179 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Steve Strong + steve at srstrong.com +
+ Fri Aug 16 16:44:07 CEST 2013 +

+
+ +
Was guessing that was the answer - I'll give it a go...  
+
+--  
+Steve Strong
+Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
+
+
+On Friday, 16 August 2013 at 16:42, Loïc Hoguin wrote:
+
+> Well I'm sure if you create a base Makefile (without erlang.mk) that  
+> exports DEPS_DIR and then call $(MAKE) on all folders in /apps (which  
+> would themselves contain Makefiles that use erlang.mk), it would work  
+> just fine. You can still keep only one erlang.mk in your repos and use  
+> include ../../erlang.mk instead for example.
+>  
+> But know that this folder structure is a rebar thing and not standard  
+> (just like /deps you'll say, but that one is insanely useful regardless  
+> of the project structure otherwise).
+>  
+> On 08/16/2013 02:27 PM, Steve Strong wrote:
+> > Looks good - I like simple! Quick question, does it support multiple
+> > applications, for example a project laid out as:
+> >  
+> > /proj
+> > /deps
+> > /stuff
+> >  
+> > /apps
+> > /app1
+> > /app2
+> >  
+> > Most of our stuff is in that form, with shared dependencies between the
+> > various apps. Rebar is quite happy with that format, but I can't see
+> > how to persuade erlang.mk to handle that.
+> >  
+> > Cheers,
+> >  
+> > Steve
+> >  
+> > --
+> > Steve Strong
+> > Sent with Sparrow <http://www.sparrowmailapp.com/?sig>
+> >  
+> > On Thursday, 15 August 2013 at 16:19, Loïc Hoguin wrote:
+> >  
+> > > Hello friendly people,
+> > >  
+> > > I would like to make an official announcement of erlang.mk now that all
+> > > the features I wanted are in.
+> > >  
+> > > erlang.mk is a rebar replacement. It was initially created for allowing
+> > > a faster development process than rebar and for better compatibility
+> > > with Linux build tools. It should work on Linux and OSX with GNU Make
+> > > installed.
+> > >  
+> > > Projects using erlang.mk are still compatible with rebar. Dependencies
+> > > fetched by rebar are stored in the same deps/ directory, and projects
+> > > using erlang.mk can still be used as rebar dependencies, with or without
+> > > a rebar.config file.
+> > >  
+> > > erlang.mk also features a simple package index. Try `make pkg-list` to
+> > > list all packages currently available. All the packages listed are
+> > > compatible with erlang.mk with no tweaking required.
+> > >  
+> > > Makefiles written with erlang.mk are *VERY* simple, here are two examples:
+> > >  
+> > > * https://github.com/extend/farwest/blob/master/Makefile
+> > > * https://github.com/extend/cowboy/blob/master/Makefile
+> > >  
+> > > I wrote about erlang.mk and relx recently on the Nine Nines blog.
+> > > erlang.mk is the perfect companion to relx.
+> > >  
+> > > * http://ninenines.eu/articles/erlang.mk-and-relx
+> > >  
+> > > Here are examples of projects that are using and compatible with
+> > > erlang.mk:
+> > >  
+> > > * https://github.com/jlouis/etorrent
+> > > * https://github.com/extend/cowboy
+> > > * https://github.com/extend/farwest
+> > >  
+> > > You can find erlang.mk at the following URL:
+> > >  
+> > > * https://github.com/extend/erlang.mk
+> > >  
+> > > Contributions to the package index are of course welcome! The only
+> > > requirement is that the package is to be compatible with erlang.mk
+> > > itself. Just send a PR to the erlang.mk project updating the
+> > > packages.v1.txt!
+> > >  
+> > > Enjoy!
+> > >  
+> > > --
+> > > Loïc Hoguin
+> > > Erlang Cowboy
+> > > Nine Nines
+> > > http://ninenines.eu
+> > > _______________________________________________
+> > > erlang-questions mailing list
+> > > erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+> > > http://erlang.org/mailman/listinfo/erlang-questions
+> > >  
+> >  
+> >  
+>  
+>  
+>  
+> --  
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>  
+>  
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130816/1cd82d09/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000219.html b/_build/static/archives/extend/2013-August/000219.html new file mode 100644 index 00000000..fb300880 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000219.html @@ -0,0 +1,213 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Grzegorz Junka + list1 at gjunka.com +
+ Fri Aug 16 17:02:00 CEST 2013 +

+
+ +
But it "is only used for fetching the package index file"... :) If the 
+target is up to date there is no starting of Erlang. But on the other 
+hand it could be used conditionally, e.g. use wget on systems on which 
+it is installed and Erlang otherwise. It's just down to creating a 
+properly structured target, isn't?
+
+On 16/08/2013 15:44, Loïc Hoguin wrote:
+> Starting Erlang takes too long. That's a big reason why erlang.mk was 
+> created. :)
+>
+> I recall NetBSD being able to download things with a shell script only 
+> (as it comes with nothing installed), this would be a more interesting 
+> solution especially since we can bundle it in the erlang.mk file too.
+>
+> On 08/16/2013 04:42 PM, Grzegorz Junka wrote:
+>> Why not use Erlang for downloading? Surely if erlang.mk is a tool for
+>> Erlang then it will be very likely installed. For example this target
+>> downloads Rebar:
+>>
+>> # Erlang Rebar downloading, see:
+>> #
+>> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y 
+>>
+>> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar
+>> ./rebar:
+>> $(ERL) -noshell -s inets -s ssl \
+>> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream,
+>> "./rebar"}])' \
+>> -s init stop
+>> chmod +x ./rebar
+>> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk
+>> '{ print $$NF }')
+>>
+>>
+>> It could be used to download anything, not just REBAR.
+>>
+>> - Greg
+>>
+>>
+>> On 16/08/2013 15:34, Loïc Hoguin wrote:
+>>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote:
+>>>> The big problem with erlang.mk <http://erlang.mk> is requiring to have
+>>>> gmake and more importantly wget installed imo.
+>>>
+>>> wget is only used for fetching the package index file. I'm sure if it
+>>> doesn't work somewhere it'll be patched eventually.
+>>>
+>>>> Which makes it quite annoying to distribute on systems that have 
+>>>> none of
+>>>> them. It would be interrestin to have the support for curl for 
+>>>> example.
+>>>> Also what are the makefile extensions that you really need to require
+>>>> gmake?
+>>>
+>>> No idea. Patches are welcome for compatibility with different OS/build
+>>> tools (as long as it's not "rewrite the whole file" of course, then
+>>> you're better off just using gmake).
+>>>
+>>>> - benoit
+>>>>
+>>>>
+>>>> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu
+>>>> <mailto:essen at ninenines.eu>> wrote:
+>>>>
+>>>>     Hello friendly people,
+>>>>
+>>>>     I would like to make an official announcement of erlang.mk
+>>>> <http://erlang.mk> now that all the features I wanted are in.
+>>>>
+>>>>     erlang.mk <http://erlang.mk> is a rebar replacement. It was
+>>>>     initially created for allowing a faster development process than
+>>>>     rebar and for better compatibility with Linux build tools. It 
+>>>> should
+>>>>     work on Linux and OSX with GNU Make installed.
+>>>>
+>>>>     Projects using erlang.mk <http://erlang.mk> are still compatible
+>>>>     with rebar. Dependencies fetched by rebar are stored in the same
+>>>>     deps/ directory, and projects using erlang.mk 
+>>>> <http://erlang.mk> can
+>>>>     still be used as rebar dependencies, with or without a 
+>>>> rebar.config
+>>>>     file.
+>>>>
+>>>>     erlang.mk <http://erlang.mk> also features a simple package index.
+>>>>     Try `make pkg-list` to list all packages currently available. All
+>>>>     the packages listed are compatible with erlang.mk 
+>>>> <http://erlang.mk>
+>>>>     with no tweaking required.
+>>>>
+>>>>     Makefiles written with erlang.mk <http://erlang.mk> are *VERY*
+>>>>     simple, here are two examples:
+>>>>
+>>>>       * https://github.com/extend/__farwest/blob/master/Makefile
+>>>> <https://github.com/extend/farwest/blob/master/Makefile>
+>>>>       * https://github.com/extend/__cowboy/blob/master/Makefile
+>>>> <https://github.com/extend/cowboy/blob/master/Makefile>
+>>>>
+>>>>     I wrote about erlang.mk <http://erlang.mk> and relx recently on 
+>>>> the
+>>>>     Nine Nines blog. erlang.mk <http://erlang.mk> is the perfect
+>>>>     companion to relx.
+>>>>
+>>>>       * http://ninenines.eu/articles/__erlang.mk-and-relx
+>>>> <http://ninenines.eu/articles/erlang.mk-and-relx>
+>>>>
+>>>>     Here are examples of projects that are using and compatible with
+>>>>     erlang.mk <http://erlang.mk>:
+>>>>
+>>>>       * https://github.com/jlouis/__etorrent
+>>>> <https://github.com/jlouis/etorrent>
+>>>>       * https://github.com/extend/__cowboy
+>>>> <https://github.com/extend/cowboy>
+>>>>       * https://github.com/extend/__farwest
+>>>> <https://github.com/extend/farwest>
+>>>>
+>>>>     You can find erlang.mk <http://erlang.mk> at the following URL:
+>>>>
+>>>>       * https://github.com/extend/__erlang.mk
+>>>> <https://github.com/extend/erlang.mk>
+>>>>
+>>>>     Contributions to the package index are of course welcome! The only
+>>>>     requirement is that the package is to be compatible with erlang.mk
+>>>> <http://erlang.mk> itself. Just send a PR to the erlang.mk
+>>>> <http://erlang.mk> project updating the packages.v1.txt!
+>>>>
+>>>>     Enjoy!
+>>>>
+>>>>     --
+>>>>     Loïc Hoguin
+>>>>     Erlang Cowboy
+>>>>     Nine Nines
+>>>> http://ninenines.eu
+>>>>     _________________________________________________
+>>>>     erlang-questions mailing list
+>>>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>>> http://erlang.org/mailman/__listinfo/erlang-questions
+>>>> <http://erlang.org/mailman/listinfo/erlang-questions>
+>>>>
+>>>>
+>>>
+>>>
+>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>
+>
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000220.html b/_build/static/archives/extend/2013-August/000220.html new file mode 100644 index 00000000..b5e46ca0 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000220.html @@ -0,0 +1,228 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 16 17:10:19 CEST 2013 +

+
+ +
I know, and if it makes it work where it currently doesn't I'd merge it. 
+But ultimately we want to avoid starting Erlang unless strictly necessary.
+
+On 08/16/2013 05:02 PM, Grzegorz Junka wrote:
+> But it "is only used for fetching the package index file"... :) If the
+> target is up to date there is no starting of Erlang. But on the other
+> hand it could be used conditionally, e.g. use wget on systems on which
+> it is installed and Erlang otherwise. It's just down to creating a
+> properly structured target, isn't?
+>
+> On 16/08/2013 15:44, Loïc Hoguin wrote:
+>> Starting Erlang takes too long. That's a big reason why erlang.mk was
+>> created. :)
+>>
+>> I recall NetBSD being able to download things with a shell script only
+>> (as it comes with nothing installed), this would be a more interesting
+>> solution especially since we can bundle it in the erlang.mk file too.
+>>
+>> On 08/16/2013 04:42 PM, Grzegorz Junka wrote:
+>>> Why not use Erlang for downloading? Surely if erlang.mk is a tool for
+>>> Erlang then it will be very likely installed. For example this target
+>>> downloads Rebar:
+>>>
+>>> # Erlang Rebar downloading, see:
+>>> #
+>>> https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y
+>>>
+>>> rb_rebar_url=http://cloud.github.com/downloads/basho/rebar/rebar
+>>> ./rebar:
+>>> $(ERL) -noshell -s inets -s ssl \
+>>> -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream,
+>>> "./rebar"}])' \
+>>> -s init stop
+>>> chmod +x ./rebar
+>>> REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk
+>>> '{ print $$NF }')
+>>>
+>>>
+>>> It could be used to download anything, not just REBAR.
+>>>
+>>> - Greg
+>>>
+>>>
+>>> On 16/08/2013 15:34, Loïc Hoguin wrote:
+>>>> On 08/16/2013 10:39 AM, Benoit Chesneau wrote:
+>>>>> The big problem with erlang.mk <http://erlang.mk> is requiring to have
+>>>>> gmake and more importantly wget installed imo.
+>>>>
+>>>> wget is only used for fetching the package index file. I'm sure if it
+>>>> doesn't work somewhere it'll be patched eventually.
+>>>>
+>>>>> Which makes it quite annoying to distribute on systems that have
+>>>>> none of
+>>>>> them. It would be interrestin to have the support for curl for
+>>>>> example.
+>>>>> Also what are the makefile extensions that you really need to require
+>>>>> gmake?
+>>>>
+>>>> No idea. Patches are welcome for compatibility with different OS/build
+>>>> tools (as long as it's not "rewrite the whole file" of course, then
+>>>> you're better off just using gmake).
+>>>>
+>>>>> - benoit
+>>>>>
+>>>>>
+>>>>> On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <essen at ninenines.eu
+>>>>> <mailto:essen at ninenines.eu>> wrote:
+>>>>>
+>>>>>     Hello friendly people,
+>>>>>
+>>>>>     I would like to make an official announcement of erlang.mk
+>>>>> <http://erlang.mk> now that all the features I wanted are in.
+>>>>>
+>>>>>     erlang.mk <http://erlang.mk> is a rebar replacement. It was
+>>>>>     initially created for allowing a faster development process than
+>>>>>     rebar and for better compatibility with Linux build tools. It
+>>>>> should
+>>>>>     work on Linux and OSX with GNU Make installed.
+>>>>>
+>>>>>     Projects using erlang.mk <http://erlang.mk> are still compatible
+>>>>>     with rebar. Dependencies fetched by rebar are stored in the same
+>>>>>     deps/ directory, and projects using erlang.mk
+>>>>> <http://erlang.mk> can
+>>>>>     still be used as rebar dependencies, with or without a
+>>>>> rebar.config
+>>>>>     file.
+>>>>>
+>>>>>     erlang.mk <http://erlang.mk> also features a simple package index.
+>>>>>     Try `make pkg-list` to list all packages currently available. All
+>>>>>     the packages listed are compatible with erlang.mk
+>>>>> <http://erlang.mk>
+>>>>>     with no tweaking required.
+>>>>>
+>>>>>     Makefiles written with erlang.mk <http://erlang.mk> are *VERY*
+>>>>>     simple, here are two examples:
+>>>>>
+>>>>>       * https://github.com/extend/__farwest/blob/master/Makefile
+>>>>> <https://github.com/extend/farwest/blob/master/Makefile>
+>>>>>       * https://github.com/extend/__cowboy/blob/master/Makefile
+>>>>> <https://github.com/extend/cowboy/blob/master/Makefile>
+>>>>>
+>>>>>     I wrote about erlang.mk <http://erlang.mk> and relx recently on
+>>>>> the
+>>>>>     Nine Nines blog. erlang.mk <http://erlang.mk> is the perfect
+>>>>>     companion to relx.
+>>>>>
+>>>>>       * http://ninenines.eu/articles/__erlang.mk-and-relx
+>>>>> <http://ninenines.eu/articles/erlang.mk-and-relx>
+>>>>>
+>>>>>     Here are examples of projects that are using and compatible with
+>>>>>     erlang.mk <http://erlang.mk>:
+>>>>>
+>>>>>       * https://github.com/jlouis/__etorrent
+>>>>> <https://github.com/jlouis/etorrent>
+>>>>>       * https://github.com/extend/__cowboy
+>>>>> <https://github.com/extend/cowboy>
+>>>>>       * https://github.com/extend/__farwest
+>>>>> <https://github.com/extend/farwest>
+>>>>>
+>>>>>     You can find erlang.mk <http://erlang.mk> at the following URL:
+>>>>>
+>>>>>       * https://github.com/extend/__erlang.mk
+>>>>> <https://github.com/extend/erlang.mk>
+>>>>>
+>>>>>     Contributions to the package index are of course welcome! The only
+>>>>>     requirement is that the package is to be compatible with erlang.mk
+>>>>> <http://erlang.mk> itself. Just send a PR to the erlang.mk
+>>>>> <http://erlang.mk> project updating the packages.v1.txt!
+>>>>>
+>>>>>     Enjoy!
+>>>>>
+>>>>>     --
+>>>>>     Loïc Hoguin
+>>>>>     Erlang Cowboy
+>>>>>     Nine Nines
+>>>>> http://ninenines.eu
+>>>>>     _________________________________________________
+>>>>>     erlang-questions mailing list
+>>>>> erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>>>> http://erlang.org/mailman/__listinfo/erlang-questions
+>>>>> <http://erlang.org/mailman/listinfo/erlang-questions>
+>>>>>
+>>>>>
+>>>>
+>>>>
+>>>
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>
+>>
+>>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000221.html b/_build/static/archives/extend/2013-August/000221.html new file mode 100644 index 00000000..b11430ad --- /dev/null +++ b/_build/static/archives/extend/2013-August/000221.html @@ -0,0 +1,63 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Bin Wang + wbin00 at gmail.com +
+ Fri Aug 16 17:40:22 CEST 2013 +

+
+ +
Will it support protobuf(https://github.com/basho/erlang_protobuffs),
+I cannot compile *.proto file from src/ with erlang.mk.
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000222.html b/_build/static/archives/extend/2013-August/000222.html new file mode 100644 index 00000000..e0d6785c --- /dev/null +++ b/_build/static/archives/extend/2013-August/000222.html @@ -0,0 +1,77 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Aug 16 17:55:30 CEST 2013 +

+
+ +
On 08/16/2013 05:40 PM, Bin Wang wrote:
+> Will it support protobuf(https://github.com/basho/erlang_protobuffs),
+> I cannot compile *.proto file from src/ with erlang.mk.
+
+That's a good question. I probably would merge such a patch right now, 
+but if it ends up being too many different compilers we'll probably need 
+a better solution (something like having you include both erlang.mk and 
+protobuffs.mk to enable it?).
+
+I don't use protobuffs myself so don't count on me though.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000223.html b/_build/static/archives/extend/2013-August/000223.html new file mode 100644 index 00000000..f44537e7 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000223.html @@ -0,0 +1,90 @@ + + + + [99s-extend] [erlang-questions] [ANN] erlang.mk build tool + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] erlang.mk build tool

+ Jeremy Ong + jeremy at quarkgames.com +
+ Fri Aug 16 18:29:36 CEST 2013 +

+
+ +
I'd prefer it if there were more generalized hooks for files of
+different names rather than hardcoding usage of a particular library.
+In the case of protobuffers, some people use piqi, others use basho's
+library, and still others use their own library.
+
+On Fri, Aug 16, 2013 at 8:55 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> On 08/16/2013 05:40 PM, Bin Wang wrote:
+>>
+>> Will it support protobuf(https://github.com/basho/erlang_protobuffs),
+>> I cannot compile *.proto file from src/ with erlang.mk.
+>
+>
+> That's a good question. I probably would merge such a patch right now, but
+> if it ends up being too many different compilers we'll probably need a
+> better solution (something like having you include both erlang.mk and
+> protobuffs.mk to enable it?).
+>
+> I don't use protobuffs myself so don't count on me though.
+>
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000224.html b/_build/static/archives/extend/2013-August/000224.html new file mode 100644 index 00000000..80b346e3 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000224.html @@ -0,0 +1,72 @@ + + + + [99s-extend] How to broadcaset with ranch? + + + + + + + + + + +

[99s-extend] How to broadcaset with ranch?

+ Bin Wang + wbin00 at gmail.com +
+ Sat Aug 17 10:00:04 CEST 2013 +

+
+ +
Hi,
+
+I'm new to ranch. In my application, I need to send some message to
+all connections. So I'd like to know can I get all connections from
+ranch, so I could use Transport:send to send them, or I must manage
+all the created connections by myself? Or is there any other better
+way?
+
+Thanks.
+
+Bin Wang
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000225.html b/_build/static/archives/extend/2013-August/000225.html new file mode 100644 index 00000000..bd4c5de5 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000225.html @@ -0,0 +1,85 @@ + + + + [99s-extend] How to broadcaset with ranch? + + + + + + + + + + +

[99s-extend] How to broadcaset with ranch?

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Aug 17 10:10:41 CEST 2013 +

+
+ +
On 08/17/2013 10:00 AM, Bin Wang wrote:
+> Hi,
+>
+> I'm new to ranch. In my application, I need to send some message to
+> all connections. So I'd like to know can I get all connections from
+> ranch, so I could use Transport:send to send them, or I must manage
+> all the created connections by myself? Or is there any other better
+> way?
+
+The best way to do that is on your end, using gproc properties. When the 
+connection is accepted, register the process with the property and use 
+the property to send messages to all processes. You don't need to 
+unregister when the connection ends, gproc does that automatically.
+
+The hackish way to do that would be to call supervisor:which_children on 
+the ranch_conns_sup supervisor of your listener, but that will slow down 
+the accepting of new connections, so don't do this if you need high 
+accept rates.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/000226.html b/_build/static/archives/extend/2013-August/000226.html new file mode 100644 index 00000000..4fcc1620 --- /dev/null +++ b/_build/static/archives/extend/2013-August/000226.html @@ -0,0 +1,102 @@ + + + + [99s-extend] [erlang-questions] How to broadcaset with ranch? + + + + + + + + + + +

[99s-extend] [erlang-questions] How to broadcaset with ranch?

+ Sean Cribbs + seancribbs at gmail.com +
+ Wed Aug 21 05:18:19 CEST 2013 +

+
+ +
This is exactly the sort of thing gen_event is for. I would make each
+server process register a handler at startup using
+gen_event:add_sup_handler() and then have the handle_event callback simply
+relay the event to the server processes. Yes, gproc can do this, but why
+incur its extra features and overhead?
+
+
+On Sat, Aug 17, 2013 at 3:10 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 08/17/2013 10:00 AM, Bin Wang wrote:
+>
+>> Hi,
+>>
+>> I'm new to ranch. In my application, I need to send some message to
+>> all connections. So I'd like to know can I get all connections from
+>> ranch, so I could use Transport:send to send them, or I must manage
+>> all the created connections by myself? Or is there any other better
+>> way?
+>>
+>
+> The best way to do that is on your end, using gproc properties. When the
+> connection is accepted, register the process with the property and use the
+> property to send messages to all processes. You don't need to unregister
+> when the connection ends, gproc does that automatically.
+>
+> The hackish way to do that would be to call supervisor:which_children on
+> the ranch_conns_sup supervisor of your listener, but that will slow down
+> the accepting of new connections, so don't do this if you need high accept
+> rates.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130820/b203ebe2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-August/author.html b/_build/static/archives/extend/2013-August/author.html new file mode 100644 index 00000000..815c9cfa --- /dev/null +++ b/_build/static/archives/extend/2013-August/author.html @@ -0,0 +1,302 @@ + + + + The Extend August 2013 Archive by author + + + + + +

August 2013 Archives by author

+ +

Starting: Fri Aug 2 17:01:26 CEST 2013
+ Ending: Wed Aug 21 05:18:19 CEST 2013
+ Messages: 51

+

+

+ Last message date: + Wed Aug 21 05:18:19 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-August/date.html b/_build/static/archives/extend/2013-August/date.html new file mode 100644 index 00000000..5848062a --- /dev/null +++ b/_build/static/archives/extend/2013-August/date.html @@ -0,0 +1,302 @@ + + + + The Extend August 2013 Archive by date + + + + + +

August 2013 Archives by date

+ +

Starting: Fri Aug 2 17:01:26 CEST 2013
+ Ending: Wed Aug 21 05:18:19 CEST 2013
+ Messages: 51

+

+

+ Last message date: + Wed Aug 21 05:18:19 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-August/index.html b/_build/static/archives/extend/2013-August/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-August/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-August/subject.html b/_build/static/archives/extend/2013-August/subject.html new file mode 100644 index 00000000..eda149fd --- /dev/null +++ b/_build/static/archives/extend/2013-August/subject.html @@ -0,0 +1,302 @@ + + + + The Extend August 2013 Archive by subject + + + + + +

August 2013 Archives by subject

+ +

Starting: Fri Aug 2 17:01:26 CEST 2013
+ Ending: Wed Aug 21 05:18:19 CEST 2013
+ Messages: 51

+

+

+ Last message date: + Wed Aug 21 05:18:19 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-August/thread.html b/_build/static/archives/extend/2013-August/thread.html new file mode 100644 index 00000000..15974c72 --- /dev/null +++ b/_build/static/archives/extend/2013-August/thread.html @@ -0,0 +1,385 @@ + + + + The Extend August 2013 Archive by thread + + + + + +

August 2013 Archives by thread

+ +

Starting: Fri Aug 2 17:01:26 CEST 2013
+ Ending: Wed Aug 21 05:18:19 CEST 2013
+ Messages: 51

+

+

+ Last message date: + Wed Aug 21 05:18:19 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-December.txt b/_build/static/archives/extend/2013-December.txt new file mode 100644 index 00000000..8912dc6c --- /dev/null +++ b/_build/static/archives/extend/2013-December.txt @@ -0,0 +1,260 @@ +From dagurg at gmail.com Thu Dec 12 11:57:42 2013 +From: dagurg at gmail.com (Dagur Gunnarsson) +Date: Thu, 12 Dec 2013 10:57:42 +0000 +Subject: [99s-extend] (no subject) +Message-ID: + +Hi, + +I am using cowboy for our financial webservice platform. We use token +based authentication, but I want to give certain ip adresses full access +without authentication. I tried : + +{{IP, Port}, Req2} = cowboy_req:peer(Req). + +but IP is always {127,0,0,1} - even on production (where request +are comming from different networks) + +So my question is basically, Is there any way for me to see +frow which IP adresses the request is comming ? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Dec 12 12:06:10 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 12 Dec 2013 12:06:10 +0100 +Subject: [99s-extend] (no subject) +In-Reply-To: +References: +Message-ID: <52A998A2.7050303@ninenines.eu> + +Hi, + +It sounds like you have a proxy of some kind on the same machine. The +proxy would likely set a header with the real IP in it, or at least have +an option for it. + +On 12/12/2013 11:57 AM, Dagur Gunnarsson wrote: +> Hi, +> I am using cowboy for our financial webservice platform. We use token +> based authentication, but I want to give certain ip adresses full access +> without authentication. I tried : +> {{|IP||, ||Port||}, ||Req2||} = ||cowboy_req:peer||(||Req||).| +> || +> |but IP is always {127,0,0,1} - even on production (where request| +> |are comming from different networks)| +> || +> |So my question is basically, Is there any way for me to see | +> |frow which ||IP adresses the request is comming ?| +> || +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From dch at jsonified.com Thu Dec 12 14:00:07 2013 +From: dch at jsonified.com (Dave Cottlehuber) +Date: Thu, 12 Dec 2013 14:00:07 +0100 +Subject: [99s-extend] (no subject) +In-Reply-To: <52A998A2.7050303@ninenines.eu> +References: + <52A998A2.7050303@ninenines.eu> +Message-ID: + +On 12. Dezember 2013 at 12:06:20, Lo?c Hoguin (essen at ninenines.eu) wrote: +> +> Hi, +> +> It sounds like you have a proxy of some kind on the same machine. +> The +> proxy would likely set a header with the real IP in it, or at least +> have +> an option for it. + +Hey Dagur, + +Look through all headers, normally a proxy will set something like X-Forwarded-For or similar. + +A+ +Dave + + + + +From cjsvance at gmail.com Sun Dec 15 06:48:20 2013 +From: cjsvance at gmail.com (Christopher Vance) +Date: Sun, 15 Dec 2013 16:48:20 +1100 +Subject: [99s-extend] erlang.mk:109 sed \s is not portable +Message-ID: + +I have recently started using erlang.mk on MacOS X and OpenBSD, and have +discovered that the sed escape \s on line 109 for inserting the module list +in *.app does not work as intended on these OSs, because they do not use +GNU sed. (\s just means the letter 's', not whitespace as in perl.) I +expect all other BSD-based OSs to have the same issue. + +Please consider using [[:space:]] instead. This works on both MacOS X and +OpenBSD, as well as on Linux. + +-- +Christopher Vance +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Sun Dec 15 10:12:07 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sun, 15 Dec 2013 10:12:07 +0100 +Subject: [99s-extend] erlang.mk:109 sed \s is not portable +In-Reply-To: +References: +Message-ID: <52AD7267.8070905@ninenines.eu> + +This has been fixed for a few weeks now. Please check the bug tracker +(or commit log) next time, as this is where bugs get reported/fixed. + +Thanks. + +On 12/15/2013 06:48 AM, Christopher Vance wrote: +> I have recently started using erlang.mk on MacOS X and OpenBSD, and have +> discovered that the sed escape \s on line 109 for inserting the module list +> in *.app does not work as intended on these OSs, because they do not use +> GNU sed. (\s just means the letter 's', not whitespace as in perl.) I +> expect all other BSD-based OSs to have the same issue. +> +> Please consider using [[:space:]] instead. This works on both MacOS X and +> OpenBSD, as well as on Linux. +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Fri Dec 27 00:49:28 2013 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Thu, 26 Dec 2013 18:49:28 -0500 (EST) +Subject: [99s-extend] Make error +Message-ID: <1388101768.1769116@apps.rackspace.com> + +Hello, + +*** GOAL: + +Modify rest_pastebin in Cowboy examples. + +*** PROCEDULE 1: + +- Pulled Cowboy, including examples into local workstation +- Copied rest_pastebin to a separate directory +- Execute make + Make compiles just fine + +*** PROCEDUE 2 -- resulting in error + +- delete the entire rest_pastebin application and recopy from the Cowboy pull +- change all module names and references from rest_pastebin to tagr. Thus rest_pastebin_sup.erl becomes tagr_sup.erl +- Execute make + Make returns: + +... +make[1]: Leaving directory `/home/lloyd/Erl/CB/tagr/deps/cowboy' + ERLC toppage_handler.erl tagr_sup.erl tagr_app.erl + ERLC toppage_handler.erl tagr_sup.erl tagr_app.erl + APP tagr .app.src +cat: src/tagr: No such file or directory +cat: .app.src: No such file or directory +sed: can't read .app: No such file or directory +make: *** [app] Error 2 + +Note that the filename tagr.app.src has somehow been modified to tagr .app.src + +But here's the directory listing: + +-rw-rw-r-- 1 lloyd lloyd 436 Dec 26 18:21 tagr_app.erl +-rw-rw-r-- 1 lloyd lloyd 299 Dec 26 18:22 tagr.app.src +-rw-rw-r-- 1 lloyd lloyd 382 Dec 26 18:22 tagr_sup.erl +-rw-rw-r-- 1 lloyd lloyd 3568 Dec 26 18:23 toppage_handler.erl + +I can load tagr.app.src in Vim. Using find I've searched for tagr and .app.src with negative results. + +Further mystery. I substituted Rebar for relx. Tagr now compiles just fine. + +*** Discussion + +I stumbled on this problem after making fairly extensive modifications to rest_pastebin. Through much of the process it compiled just fine until it didn't. And from then on I could not get it to compile. I tried everything I could think of: careful source code review (at least 10 passes), searching for tagr .app.src, trying different names (e.g. tagger), rebooting my computer, etc., etc. + +Eventually I reduced the problem to the absolute minimum: Change the string rest_pastebin to tagr everywhere relevant. + +It's possible I'm missing something somewhere. But where should I look? Otherwise, is it possible that there is a subtle bug in relx? + + +Many thanks, + +Lloyd + + + + + + + + + + + + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From essen at ninenines.eu Fri Dec 27 00:55:05 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 27 Dec 2013 00:55:05 +0100 +Subject: [99s-extend] Make error +Message-ID: + +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-December/000314.html b/_build/static/archives/extend/2013-December/000314.html new file mode 100644 index 00000000..505f05fa --- /dev/null +++ b/_build/static/archives/extend/2013-December/000314.html @@ -0,0 +1,74 @@ + + + + [99s-extend] (no subject) + + + + + + + + + + +

[99s-extend] (no subject)

+ Dagur Gunnarsson + dagurg at gmail.com +
+ Thu Dec 12 11:57:42 CET 2013 +

+
+ +
Hi,
+
+I am using cowboy for our financial webservice platform.  We use token
+based authentication, but I want to give certain ip adresses full access
+without authentication.  I tried :
+
+{{IP, Port}, Req2} = cowboy_req:peer(Req).
+
+but IP is always {127,0,0,1} - even on production (where request
+are comming from different networks)
+
+So my question is basically, Is there any way for me to see
+frow which IP adresses the request is comming ?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131212/2697fbaa/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000315.html b/_build/static/archives/extend/2013-December/000315.html new file mode 100644 index 00000000..ef84c1eb --- /dev/null +++ b/_build/static/archives/extend/2013-December/000315.html @@ -0,0 +1,91 @@ + + + + [99s-extend] (no subject) + + + + + + + + + + +

[99s-extend] (no subject)

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Dec 12 12:06:10 CET 2013 +

+
+ +
Hi,
+
+It sounds like you have a proxy of some kind on the same machine. The 
+proxy would likely set a header with the real IP in it, or at least have 
+an option for it.
+
+On 12/12/2013 11:57 AM, Dagur Gunnarsson wrote:
+> Hi,
+> I am using cowboy for our financial webservice platform.  We use token
+> based authentication, but I want to give certain ip adresses full access
+> without authentication.  I tried :
+> {{|IP||, ||Port||}, ||Req2||} = ||cowboy_req:peer||(||Req||).|
+> ||
+> |but IP is always {127,0,0,1} - even on production (where request|
+> |are comming from different networks)|
+> ||
+> |So my question is basically, Is there any way for me to see |
+> |frow which ||IP adresses the request is comming ?|
+> ||
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000316.html b/_build/static/archives/extend/2013-December/000316.html new file mode 100644 index 00000000..4dea71b6 --- /dev/null +++ b/_build/static/archives/extend/2013-December/000316.html @@ -0,0 +1,79 @@ + + + + [99s-extend] (no subject) + + + + + + + + + + +

[99s-extend] (no subject)

+ Dave Cottlehuber + dch at jsonified.com +
+ Thu Dec 12 14:00:07 CET 2013 +

+
+ +
On 12. Dezember 2013 at 12:06:20, Loïc Hoguin (essen at ninenines.eu) wrote:
+>  
+> Hi,
+>  
+> It sounds like you have a proxy of some kind on the same machine.  
+> The
+> proxy would likely set a header with the real IP in it, or at least  
+> have
+> an option for it.
+
+Hey Dagur,
+
+Look through all headers, normally a proxy will set something like X-Forwarded-For or similar.
+
+A+
+Dave
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000317.html b/_build/static/archives/extend/2013-December/000317.html new file mode 100644 index 00000000..c451c197 --- /dev/null +++ b/_build/static/archives/extend/2013-December/000317.html @@ -0,0 +1,74 @@ + + + + [99s-extend] erlang.mk:109 sed \s is not portable + + + + + + + + + + +

[99s-extend] erlang.mk:109 sed \s is not portable

+ Christopher Vance + cjsvance at gmail.com +
+ Sun Dec 15 06:48:20 CET 2013 +

+
+ +
I have recently started using erlang.mk on MacOS X and OpenBSD, and have
+discovered that the sed escape \s on line 109 for inserting the module list
+in *.app does not work as intended on these OSs, because they do not use
+GNU sed. (\s just means the letter 's', not whitespace as in perl.) I
+expect all other BSD-based OSs to have the same issue.
+
+Please consider using [[:space:]] instead. This works on both MacOS X and
+OpenBSD, as well as on Linux.
+
+-- 
+Christopher Vance
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131215/7c20ac97/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000318.html b/_build/static/archives/extend/2013-December/000318.html new file mode 100644 index 00000000..96c6148f --- /dev/null +++ b/_build/static/archives/extend/2013-December/000318.html @@ -0,0 +1,87 @@ + + + + [99s-extend] erlang.mk:109 sed \s is not portable + + + + + + + + + + +

[99s-extend] erlang.mk:109 sed \s is not portable

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Dec 15 10:12:07 CET 2013 +

+
+ +
This has been fixed for a few weeks now. Please check the bug tracker 
+(or commit log) next time, as this is where bugs get reported/fixed.
+
+Thanks.
+
+On 12/15/2013 06:48 AM, Christopher Vance wrote:
+> I have recently started using erlang.mk on MacOS X and OpenBSD, and have
+> discovered that the sed escape \s on line 109 for inserting the module list
+> in *.app does not work as intended on these OSs, because they do not use
+> GNU sed. (\s just means the letter 's', not whitespace as in perl.) I
+> expect all other BSD-based OSs to have the same issue.
+>
+> Please consider using [[:space:]] instead. This works on both MacOS X and
+> OpenBSD, as well as on Linux.
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000319.html b/_build/static/archives/extend/2013-December/000319.html new file mode 100644 index 00000000..e6724d3f --- /dev/null +++ b/_build/static/archives/extend/2013-December/000319.html @@ -0,0 +1,155 @@ + + + + [99s-extend] Make error + + + + + + + + + + +

[99s-extend] Make error

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Fri Dec 27 00:49:28 CET 2013 +

+
+ +
Hello,
+
+*** GOAL: 
+
+Modify rest_pastebin in Cowboy examples.
+
+*** PROCEDULE 1: 
+
+- Pulled Cowboy, including examples into local workstation
+- Copied rest_pastebin to a separate directory
+- Execute make
+      Make compiles just fine
+
+*** PROCEDUE 2 -- resulting in error
+
+- delete the entire rest_pastebin application and recopy from the Cowboy pull
+- change all module names and references from rest_pastebin to tagr. Thus rest_pastebin_sup.erl becomes tagr_sup.erl
+- Execute make
+      Make returns:
+
+...
+make[1]: Leaving directory `/home/lloyd/Erl/CB/tagr/deps/cowboy'
+ ERLC   toppage_handler.erl tagr_sup.erl tagr_app.erl
+ ERLC   toppage_handler.erl tagr_sup.erl tagr_app.erl
+ APP    tagr .app.src
+cat: src/tagr: No such file or directory
+cat: .app.src: No such file or directory
+sed: can't read .app: No such file or directory
+make: *** [app] Error 2
+
+Note that the filename tagr.app.src has somehow been modified to tagr .app.src
+
+But here's the directory listing: 
+
+-rw-rw-r-- 1 lloyd lloyd  436 Dec 26 18:21 tagr_app.erl
+-rw-rw-r-- 1 lloyd lloyd  299 Dec 26 18:22 tagr.app.src
+-rw-rw-r-- 1 lloyd lloyd  382 Dec 26 18:22 tagr_sup.erl
+-rw-rw-r-- 1 lloyd lloyd 3568 Dec 26 18:23 toppage_handler.erl
+
+I can load tagr.app.src in Vim. Using find I've searched for tagr and .app.src with negative results.
+
+Further mystery. I substituted Rebar for relx. Tagr now compiles just fine.
+
+*** Discussion
+
+I stumbled on this problem after making fairly extensive modifications to rest_pastebin. Through much of the process it compiled just fine until it didn't. And from then on I could not get it to compile. I tried everything I could think of: careful source code review (at least 10 passes), searching for tagr .app.src, trying different names (e.g. tagger), rebooting my computer, etc., etc.
+
+Eventually I reduced the problem to the absolute minimum: Change the string rest_pastebin to tagr everywhere relevant. 
+
+It's possible I'm missing something somewhere. But where should I look? Otherwise, is it possible that there is a subtle bug in relx?
+
+
+Many thanks,
+
+Lloyd
+
+
+
+
+
+ 
+
+
+ 
+
+
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/000320.html b/_build/static/archives/extend/2013-December/000320.html new file mode 100644 index 00000000..8ff549a5 --- /dev/null +++ b/_build/static/archives/extend/2013-December/000320.html @@ -0,0 +1,60 @@ + + + + [99s-extend] Make error + + + + + + + + + + +

[99s-extend] Make error

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Dec 27 00:55:05 CET 2013 +

+
+ +
An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131227/35c9f6e5/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-December/author.html b/_build/static/archives/extend/2013-December/author.html new file mode 100644 index 00000000..b6d3c4fd --- /dev/null +++ b/_build/static/archives/extend/2013-December/author.html @@ -0,0 +1,82 @@ + + + + The Extend December 2013 Archive by author + + + + + +

December 2013 Archives by author

+ +

Starting: Thu Dec 12 11:57:42 CET 2013
+ Ending: Fri Dec 27 00:55:05 CET 2013
+ Messages: 7

+

+

+ Last message date: + Fri Dec 27 00:55:05 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-December/date.html b/_build/static/archives/extend/2013-December/date.html new file mode 100644 index 00000000..b21b63c1 --- /dev/null +++ b/_build/static/archives/extend/2013-December/date.html @@ -0,0 +1,82 @@ + + + + The Extend December 2013 Archive by date + + + + + +

December 2013 Archives by date

+ +

Starting: Thu Dec 12 11:57:42 CET 2013
+ Ending: Fri Dec 27 00:55:05 CET 2013
+ Messages: 7

+

+

+ Last message date: + Fri Dec 27 00:55:05 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-December/index.html b/_build/static/archives/extend/2013-December/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-December/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-December/subject.html b/_build/static/archives/extend/2013-December/subject.html new file mode 100644 index 00000000..023ec09d --- /dev/null +++ b/_build/static/archives/extend/2013-December/subject.html @@ -0,0 +1,82 @@ + + + + The Extend December 2013 Archive by subject + + + + + +

December 2013 Archives by subject

+ +

Starting: Thu Dec 12 11:57:42 CET 2013
+ Ending: Fri Dec 27 00:55:05 CET 2013
+ Messages: 7

+

+

+ Last message date: + Fri Dec 27 00:55:05 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-December/thread.html b/_build/static/archives/extend/2013-December/thread.html new file mode 100644 index 00000000..ff4517cd --- /dev/null +++ b/_build/static/archives/extend/2013-December/thread.html @@ -0,0 +1,97 @@ + + + + The Extend December 2013 Archive by thread + + + + + +

December 2013 Archives by thread

+ +

Starting: Thu Dec 12 11:57:42 CET 2013
+ Ending: Fri Dec 27 00:55:05 CET 2013
+ Messages: 7

+

+

+ Last message date: + Fri Dec 27 00:55:05 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-February.txt b/_build/static/archives/extend/2013-February.txt new file mode 100644 index 00000000..7a325ec7 --- /dev/null +++ b/_build/static/archives/extend/2013-February.txt @@ -0,0 +1,948 @@ +From jeremy at quarkgames.com Mon Feb 4 21:10:21 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Mon, 4 Feb 2013 12:10:21 -0800 +Subject: [99s-extend] Cowboy Makefile +In-Reply-To: <5101B89A.50604@gjunka.com> +References: <5101B89A.50604@gjunka.com> +Message-ID: + +It is rebar compatible + +https://github.com/extend/cowboy/blob/master/rebar.config + +I use it with rebar all the time. + + +On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka wrote: + +> Hi, +> I understand the move away from Rebar but I'd like to see the project to +> be still Rebar-compatible. Would that be a problem? Mainly I am thinking +> about dependencies. The Cowboy Makefile assumes that Ranch is in its deps +> folder. If Cowboy is a part of a bigger application, and most often it will +> be in such a role rather than a standalone application, then all +> dependencies should be kept in one place. In that case it would be the main +> project's deps folder, not Cowboy's deps folder. Can the compilation +> process be split into compiling Cowboy dependencies separately from Cowboy +> itself? +> +> something like: +> +> all: compile-deps compile-cowboy +> +> Then if Cowboy is a dependency itself it may be just compiled without the +> dependency (as it will be compiled when the main project is compiled). +> +> ______________________________**_________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/**listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From list1 at gjunka.com Mon Feb 4 22:50:14 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Mon, 04 Feb 2013 21:50:14 +0000 +Subject: [99s-extend] Cowboy Makefile +In-Reply-To: +References: <5101B89A.50604@gjunka.com> + +Message-ID: <51102D16.8030000@gjunka.com> + +deps/ranch: +@mkdir -p $(DEPS_DIR) +git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch +cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN) + + +Am I to understand that the only way of having the dependencies in +another folder than cowboy/deps is to use Rebar (e.g. if compiling using +the makefile it will always assume that dependencies are in local deps +folder)? + +Would be good to have a target to compile cowboy without dependencies. + + +On 04/02/2013 20:10, Jeremy Ong wrote: +> It is rebar compatible +> +> https://github.com/extend/cowboy/blob/master/rebar.config +> +> I use it with rebar all the time. +> +> +> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka > wrote: +> +> Hi, +> I understand the move away from Rebar but I'd like to see the +> project to be still Rebar-compatible. Would that be a problem? +> Mainly I am thinking about dependencies. The Cowboy Makefile +> assumes that Ranch is in its deps folder. If Cowboy is a part of a +> bigger application, and most often it will be in such a role +> rather than a standalone application, then all dependencies should +> be kept in one place. In that case it would be the main project's +> deps folder, not Cowboy's deps folder. Can the compilation process +> be split into compiling Cowboy dependencies separately from Cowboy +> itself? +> +> something like: +> +> all: compile-deps compile-cowboy +> +> Then if Cowboy is a dependency itself it may be just compiled +> without the dependency (as it will be compiled when the main +> project is compiled). +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 4 22:58:39 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 04 Feb 2013 22:58:39 +0100 +Subject: [99s-extend] Cowboy Makefile +In-Reply-To: <51102D16.8030000@gjunka.com> +References: <5101B89A.50604@gjunka.com> + + <51102D16.8030000@gjunka.com> +Message-ID: <51102F0F.6060607@ninenines.eu> + +Cowboy is still compatible with rebar like before, there's no change you +need to do. + +If however you would like to compile using the Makefile regardless, +there's a small thing that needs to be fixed before it's good. + +On 02/04/2013 10:50 PM, Grzegorz Junka wrote: +> deps/ranch: +> @mkdir -p $(DEPS_DIR) +> git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch +> cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN) +> +> +> Am I to understand that the only way of having the dependencies in +> another folder than cowboy/deps is to use Rebar (e.g. if compiling using +> the makefile it will always assume that dependencies are in local deps +> folder)? +> +> Would be good to have a target to compile cowboy without dependencies. +> +> +> On 04/02/2013 20:10, Jeremy Ong wrote: +>> It is rebar compatible +>> +>> https://github.com/extend/cowboy/blob/master/rebar.config +>> +>> I use it with rebar all the time. +>> +>> +>> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka > > wrote: +>> +>> Hi, +>> I understand the move away from Rebar but I'd like to see the +>> project to be still Rebar-compatible. Would that be a problem? +>> Mainly I am thinking about dependencies. The Cowboy Makefile +>> assumes that Ranch is in its deps folder. If Cowboy is a part of a +>> bigger application, and most often it will be in such a role +>> rather than a standalone application, then all dependencies should +>> be kept in one place. In that case it would be the main project's +>> deps folder, not Cowboy's deps folder. Can the compilation process +>> be split into compiling Cowboy dependencies separately from Cowboy +>> itself? +>> +>> something like: +>> +>> all: compile-deps compile-cowboy +>> +>> Then if Cowboy is a dependency itself it may be just compiled +>> without the dependency (as it will be compiled when the main +>> project is compiled). +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From elinsn at gmail.com Thu Feb 7 11:04:05 2013 +From: elinsn at gmail.com (Sergey Yelin) +Date: Thu, 7 Feb 2013 14:04:05 +0400 +Subject: [99s-extend] Big body via REST +Message-ID: + +Hi list, + +how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database? + +Thanks in advance. + +--- +Best regards, +Sergey Yelin. + +From essen at ninenines.eu Thu Feb 7 15:41:03 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 07 Feb 2013 15:41:03 +0100 +Subject: [99s-extend] Big body via REST +In-Reply-To: +References: +Message-ID: <5113BCFF.5010506@ninenines.eu> + +On 02/07/2013 11:04 AM, Sergey Yelin wrote: +> Hi list, +> +> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database? + +Hey, + +If you know the size, reply with {stream, Size, StreamFun}, otherwise +{stream, StreamFun}, with StreamFun the function that will send all the +data to the socket. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From elinsn at gmail.com Thu Feb 7 15:46:31 2013 +From: elinsn at gmail.com (Sergey Yelin) +Date: Thu, 7 Feb 2013 18:46:31 +0400 +Subject: [99s-extend] Big body via REST +In-Reply-To: <5113BCFF.5010506@ninenines.eu> +References: + <5113BCFF.5010506@ninenines.eu> +Message-ID: <76D0E7F7-1819-44D0-A692-8A7C0E965D2C@gmail.com> + +Ok, thanks. + +On Feb 7, 2013, at 6:41 PM, Lo?c Hoguin wrote: + +> On 02/07/2013 11:04 AM, Sergey Yelin wrote: +>> Hi list, +>> +>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database? +> +> Hey, +> +> If you know the size, reply with {stream, Size, StreamFun}, otherwise {stream, StreamFun}, with StreamFun the function that will send all the data to the socket. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + +--- +Best regards, +Sergey Yelin. + + + + + +From john at jkemp.net Fri Feb 8 14:08:24 2013 +From: john at jkemp.net (John Kemp) +Date: Fri, 08 Feb 2013 08:08:24 -0500 +Subject: [99s-extend] How to send multiple messages in response to one + message from Cowboy +Message-ID: <5114F8C8.9020807@jkemp.net> + +Hi, + +I see that with websocket_info/3 I can prompt Cowboy to send a message +to a connected client by sending a "system message". + +How can I send multiple reply messages to a client which has sent a request? + +Is the way to do that by calling websocket_info/3 directly (multiple +times) from within my websocket_handle call? + +Cheers, + +JohnK + + +From john at jkemp.net Fri Feb 8 19:34:36 2013 +From: john at jkemp.net (John Kemp) +Date: Fri, 08 Feb 2013 13:34:36 -0500 +Subject: [99s-extend] How to send multiple messages in response to one + message from Cowboy +In-Reply-To: <5114F8C8.9020807@jkemp.net> +References: <5114F8C8.9020807@jkemp.net> +Message-ID: <5115453C.1040808@jkemp.net> + +Answering my own question - multiple messages can be sent in reply by +including a list of 'reply' tuples in the websocket_handle response. I +found this by looking at cowboy_websocket_handler.erl in the source tree. + +-callback websocket_handle({text | binary | ping | pong, binary()}, Req, +State) + -> {ok, Req, State} + | {ok, Req, State, hibernate} + + | {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, +State} + | {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, +State, hibernate} + + | {shutdown, Req, State} + when Req::cowboy_req:req(), State::state(). + +JohnK + +On 02/08/2013 08:08 AM, John Kemp wrote: +> Hi, +> +> I see that with websocket_info/3 I can prompt Cowboy to send a message +> to a connected client by sending a "system message". +> +> How can I send multiple reply messages to a client which has sent a +> request? +> +> Is the way to do that by calling websocket_info/3 directly (multiple +> times) from within my websocket_handle call? +> +> Cheers, +> +> JohnK +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From bip at kivra.com Sun Feb 10 20:12:27 2013 +From: bip at kivra.com (Bip Thelin) +Date: Sun, 10 Feb 2013 20:12:27 +0100 +Subject: [99s-extend] Cowboy questions +Message-ID: <64B371DF-D6AA-4105-954E-C22EBA61EDFC@kivra.com> + +Hi, + + I'm playing around with a middleware and request/responsehooks. A couple of questions that have surfaced: +* Say I map a module to "/my/path[...]" and then curl "/my/path/even/more/stuff". Is there a way to retrieve the "rest" of the matched path, i.e. like cowboy_req:path_info/1 but just the rest, not the total path. The result I want is: [<<"even">>, <<"more">>, <<"stuff">>]. +* I've been trying to use a responsehook to ensure that a default content-type is set if none is specified. Been trying with cowboy_req:reply, coboy_req:set_resp_headers, etc. It doesn't seem to work that well. What's the preferred way? + +Regards, +-Bip Thelin + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Feb 12 18:36:12 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 12 Feb 2013 18:36:12 +0100 +Subject: [99s-extend] [ANN] Cowboy 0.8.0 +Message-ID: <511A7D8C.5050107@ninenines.eu> + +Hello there! + +Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, +REST and Websocket server. + + https://github.com/extend/cowboy/ + +The number of contributors who helped make this release considerably +increased. Cowboy is available thanks to the code contributions from 50 +users, double from the last release where 25 contributed. + +The number of users has also greatly increased. Cowboy is being used in +ad bidding, set-top boxes, live TV events, content streaming services, +and many more exciting areas. + +This new version has many highlights. You can take a look at the +changelog for detailed information about the many changes. + + https://github.com/extend/cowboy/blob/master/CHANGELOG.md + +Cowboy scalability has been greatly improved in this version. This has +been observed many times in production, including in the AdGear Tracker +project (http://ferd.ca/rtb-where-erlang-blooms.html) where updated +nodes were able to handle 2 times more requests compared to older nodes. +This improvement cannot be observed in "hello world" types of +benchmarks. An article will soon be published to explain the reasons for +this. + +Cowboy now features a brand new user guide. It is still a work in +progress, so please open a ticket on Github if something is missing or +incorrect. + + http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction + +Remaining work before 1.0 include REST improvements and SPDY support. +The rest of the API should now be very close to stable. + +I am looking for a good writer who would like to co-author a Cowboy +book. The book will be accessible to people who don't know Erlang but +will also contain everything there is to know about Cowboy, making it +suitable for both beginners and experts. Contact me if you are interested. + +I now take donations in addition to commercial support options, to allow +individual users to help the project stay alive and kicking. + + http://ninenines.eu/support + +Hope you enjoy it. As always, please send me as much feedback as +possible to help me improve things even more, preferrably through Github +tickets if it's related to code or documentation. + +Thanks for reading. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From jeremy at quarkgames.com Tue Feb 12 18:37:18 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Tue, 12 Feb 2013 09:37:18 -0800 +Subject: [99s-extend] [ANN] Cowboy 0.8.0 +In-Reply-To: <511A7D8C.5050107@ninenines.eu> +References: <511A7D8C.5050107@ninenines.eu> +Message-ID: + +Congrats! + + +On Tue, Feb 12, 2013 at 9:36 AM, Lo?c Hoguin wrote: + +> Hello there! +> +> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, +> REST and Websocket server. +> +> https://github.com/extend/**cowboy/ +> +> The number of contributors who helped make this release considerably +> increased. Cowboy is available thanks to the code contributions from 50 +> users, double from the last release where 25 contributed. +> +> The number of users has also greatly increased. Cowboy is being used in ad +> bidding, set-top boxes, live TV events, content streaming services, and +> many more exciting areas. +> +> This new version has many highlights. You can take a look at the changelog +> for detailed information about the many changes. +> +> https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md +> +> Cowboy scalability has been greatly improved in this version. This has +> been observed many times in production, including in the AdGear Tracker +> project (http://ferd.ca/rtb-where-**erlang-blooms.html) +> where updated nodes were able to handle 2 times more requests compared to +> older nodes. This improvement cannot be observed in "hello world" types of +> benchmarks. An article will soon be published to explain the reasons for +> this. +> +> Cowboy now features a brand new user guide. It is still a work in +> progress, so please open a ticket on Github if something is missing or +> incorrect. +> +> http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction +> +> Remaining work before 1.0 include REST improvements and SPDY support. The +> rest of the API should now be very close to stable. +> +> I am looking for a good writer who would like to co-author a Cowboy book. +> The book will be accessible to people who don't know Erlang but will also +> contain everything there is to know about Cowboy, making it suitable for +> both beginners and experts. Contact me if you are interested. +> +> I now take donations in addition to commercial support options, to allow +> individual users to help the project stay alive and kicking. +> +> http://ninenines.eu/support +> +> Hope you enjoy it. As always, please send me as much feedback as possible +> to help me improve things even more, preferrably through Github tickets if +> it's related to code or documentation. +> +> Thanks for reading. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/**listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From max.lapshin at gmail.com Tue Feb 12 18:44:28 2013 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Tue, 12 Feb 2013 20:44:28 +0300 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 +In-Reply-To: +References: <511A7D8C.5050107@ninenines.eu> + +Message-ID: + +Great, Loic. + +As I've told already, it would be great to listen to your experience about +issues that you meet on high loads: smooth scaling, predictionable +behaviour of server, etc. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From Christopher.Phillips at turner.com Wed Feb 13 14:52:10 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Wed, 13 Feb 2013 13:52:10 +0000 +Subject: [99s-extend] Cowboy REST Logic +Message-ID: + + + In 6.1, and still in 8.0, there is some logic that surprised me, and I wanted to see if it was intentional, or if I'm missing something. + + If I set up a POST such that it's a create, I get back a 303, rather than a 201, on successful create. This came as a bit of a surprise; I know from Webmachine, if it's a new resource being created, a POST will return a 201 (N11 to P11 in Webmachine's v3 diagram). + + Is this intentional? The logic seems to be post_is_create/2 -> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> respond(_, _, 303). It may be that this is a better response, rather than a 201 with the location header, but it came as a surprise given web machine's behavior. + + For background, I'm attempting to migrate some web machine code to Cowboy, which is serving a RESTful API to a Javascript client. The client is making CORS calls. Receiving a 303 and a Location header seemed to mean that the call was redirected before the client side code ever saw it (not sure what the browser was doing; I was expecting another request, but I wasn't quite lucid enough to check for that last night when working on it); a 201 allows me to examine the location. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From gumm at sigma-star.com Wed Feb 13 14:46:07 2013 +From: gumm at sigma-star.com (Jesse Gumm) +Date: Wed, 13 Feb 2013 07:46:07 -0600 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 +In-Reply-To: <511A7D8C.5050107@ninenines.eu> +References: <511A7D8C.5050107@ninenines.eu> +Message-ID: + +Great news! + +Congrats! +On Feb 12, 2013 11:36 AM, "Lo?c Hoguin" wrote: + +> Hello there! +> +> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, +> REST and Websocket server. +> +> https://github.com/extend/**cowboy/ +> +> The number of contributors who helped make this release considerably +> increased. Cowboy is available thanks to the code contributions from 50 +> users, double from the last release where 25 contributed. +> +> The number of users has also greatly increased. Cowboy is being used in ad +> bidding, set-top boxes, live TV events, content streaming services, and +> many more exciting areas. +> +> This new version has many highlights. You can take a look at the changelog +> for detailed information about the many changes. +> +> https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md +> +> Cowboy scalability has been greatly improved in this version. This has +> been observed many times in production, including in the AdGear Tracker +> project (http://ferd.ca/rtb-where-**erlang-blooms.html) +> where updated nodes were able to handle 2 times more requests compared to +> older nodes. This improvement cannot be observed in "hello world" types of +> benchmarks. An article will soon be published to explain the reasons for +> this. +> +> Cowboy now features a brand new user guide. It is still a work in +> progress, so please open a ticket on Github if something is missing or +> incorrect. +> +> http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction +> +> Remaining work before 1.0 include REST improvements and SPDY support. The +> rest of the API should now be very close to stable. +> +> I am looking for a good writer who would like to co-author a Cowboy book. +> The book will be accessible to people who don't know Erlang but will also +> contain everything there is to know about Cowboy, making it suitable for +> both beginners and experts. Contact me if you are interested. +> +> I now take donations in addition to commercial support options, to allow +> individual users to help the project stay alive and kicking. +> +> http://ninenines.eu/support +> +> Hope you enjoy it. As always, please send me as much feedback as possible +> to help me improve things even more, preferrably through Github tickets if +> it's related to code or documentation. +> +> Thanks for reading. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/**listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Feb 13 16:34:54 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 13 Feb 2013 16:34:54 +0100 +Subject: [99s-extend] Cowboy REST Logic +In-Reply-To: +References: +Message-ID: <511BB29E.3090705@ninenines.eu> + +On 02/13/2013 02:52 PM, Phillips, Christopher wrote: +> +> In 6.1, and still in 8.0, there is some logic that surprised me, and +> I wanted to see if it was intentional, or if I'm missing something. +> +> If I set up a POST such that it's a create, I get back a 303, rather +> than a 201, on successful create. This came as a bit of a surprise; I +> know from Webmachine, if it's a new resource being created, a POST will +> return a 201 (N11 to P11 in Webmachine's v3 diagram). +> +> Is this intentional? The logic seems to be post_is_create/2 -> +> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> +> respond(_, _, 303). It may be that this is a better response, rather +> than a 201 with the location header, but it came as a surprise given web +> machine's behavior. + +This difference is probably not intentional. Please open a ticket. :) + +> For background, I'm attempting to migrate some web machine code to +> Cowboy, which is serving a RESTful API to a Javascript client. The +> client is making CORS calls. Receiving a 303 and a Location header +> seemed to mean that the call was redirected before the client side code +> ever saw it (not sure what the browser was doing; I was expecting +> another request, but I wasn't quite lucid enough to check for that last +> night when working on it); a 201 allows me to examine the location. + +Would be interested to know more about your CORS implementation, that's +something I would like to have in the guide. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Christopher.Phillips at turner.com Wed Feb 13 17:01:27 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Wed, 13 Feb 2013 16:01:27 +0000 +Subject: [99s-extend] Cowboy REST Logic +In-Reply-To: <511BB29E.3090705@ninenines.eu> +Message-ID: + + Will do. I actually like the 303 due to a bug in Firefox with examining +headers, but 201 seems like the canonical approach. + + CORS is actually pretty easy to open up fully, and the more restrictive +you want to be the harder it gets. We're not using credentials, and we +haven't tightened the domain to just those we expect, either, but it +basically amounts to adding the following to options/2 for the pre-flight - + + * Access-Control-Allow-Origin (with the origins we want to allow; * for +anything), + * Access-Control-Allow-Headers (which we're setting to the same as the +client requests for convenience's sake) + *Access-Control-Expose-Headers (for any headers beyond content-type that +the client wants access to; we have Location for the 201 mentioned above. + + +And the following to any request being passed back, as seems reasonable - + + * Access-Control-Allow-Origin as in options + * Access-Control-Expose-Headers as in options + + + I'm appending them in resource_exists/2 because I know that will be hit +by everything. If your logic is more complex (you want to allow PUTs from +site1, but deletes from site2, etc), you'll need to break that apart a bit +and conditionally check origin. We're relying on a firewall to protect +against direct calls from external servers, and we'll be tightening the +allowed domains and looking into validating the session with a token to +prevent CSRFs (as CORS means any existing CSRF vuln becomes a bit more +severe). + + +I suspect there's some redundancy there; we have a future story for +tightening things up, but in terms of just opening it up and getting +things working, that?s all that I had to do. + + +On 2/13/13 10:34 AM, "Lo?c Hoguin" wrote: + +>On 02/13/2013 02:52 PM, Phillips, Christopher wrote: +>> +>> In 6.1, and still in 8.0, there is some logic that surprised me, and +>> I wanted to see if it was intentional, or if I'm missing something. +>> +>> If I set up a POST such that it's a create, I get back a 303, rather +>> than a 201, on successful create. This came as a bit of a surprise; I +>> know from Webmachine, if it's a new resource being created, a POST will +>> return a 201 (N11 to P11 in Webmachine's v3 diagram). +>> +>> Is this intentional? The logic seems to be post_is_create/2 -> +>> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> +>> respond(_, _, 303). It may be that this is a better response, rather +>> than a 201 with the location header, but it came as a surprise given web +>> machine's behavior. +> +>This difference is probably not intentional. Please open a ticket. :) +> +>> For background, I'm attempting to migrate some web machine code to +>> Cowboy, which is serving a RESTful API to a Javascript client. The +>> client is making CORS calls. Receiving a 303 and a Location header +>> seemed to mean that the call was redirected before the client side code +>> ever saw it (not sure what the browser was doing; I was expecting +>> another request, but I wasn't quite lucid enough to check for that last +>> night when working on it); a 201 allows me to examine the location. +> +>Would be interested to know more about your CORS implementation, that's +>something I would like to have in the guide. +> +>-- +>Lo?c Hoguin +>Erlang Cowboy +>Nine Nines +>http://ninenines.eu +> + + + + +From essen at ninenines.eu Thu Feb 14 17:29:23 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 14 Feb 2013 17:29:23 +0100 +Subject: [99s-extend] [ANN] Bullet 0.4.0 +Message-ID: <511D10E3.3090000@ninenines.eu> + +Quick announcement: Bullet 0.4.0 has been released. This version is +compatible with newly released Cowboy 0.8.0. + + https://github.com/extend/bullet + +Bullet is a simple and efficient Websocket alternative especially useful +when you need an always connected socket to the server. It uses +Websocket internally when it's available. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From list1 at gjunka.com Mon Feb 18 17:01:30 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Mon, 18 Feb 2013 16:01:30 +0000 +Subject: [99s-extend] sub_description is not a valid app configuration option +Message-ID: <5122505A.7010801@gjunka.com> + +Hi, +I am trying to compile a release with some applications for which ranch +and cowboy are dependencies. This is what I am getting on the console: + +reltool: Unexpected item sub_description in app file +"/usr/home/somepath/deps/ranch/ebin/ranch.app". +reltool: Unexpected item sub_description in app file +"/usr/home/somepath/deps/cowboy/ebin/cowboy.app". + +When looking it up on Erlang documentation it seems that sub_description +is not a valid configuration options in the .app file. Is there any +chance to put it rather as a comment? + + + +From essen at ninenines.eu Wed Feb 20 19:58:31 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 20 Feb 2013 19:58:31 +0100 +Subject: [99s-extend] [ANN] Bullet 0.4.1 +Message-ID: <51251CD7.2010107@ninenines.eu> + +Version update to fix a bug that broke POST with non-Websocket transports. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Christopher.Phillips at turner.com Thu Feb 21 20:29:36 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Thu, 21 Feb 2013 19:29:36 +0000 +Subject: [99s-extend] Arbitrary 500 from REST handler? +Message-ID: + + + I have a case where I am creating a resource through a POST. There are a number of places where the create can fail in a known manner, and we need to alert the user to the specifics of why. Is there a way to throw an arbitrary 500, with message, from within the REST handler? I can obviously just erlang:error(whatever), but the message content is ignored, and there is no way to pass back an updated response when doing that. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Feb 21 20:38:35 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 21 Feb 2013 20:38:35 +0100 +Subject: [99s-extend] Arbitrary 500 from REST handler? +In-Reply-To: +References: +Message-ID: <512677BB.6030004@ninenines.eu> + +On 02/21/2013 08:29 PM, Phillips, Christopher wrote: +> +> I have a case where I am creating a resource through a POST. There +> are a number of places where the create can fail in a known manner, and +> we need to alert the user to the specifics of why. Is there a way to +> throw an arbitrary 500, with message, from within the REST handler? I +> can obviously just erlang:error(whatever), but the message content is +> ignored, and there is no way to pass back an updated response when doing +> that. + +Use cowboy_req:reply and then return {halt, Req2, State} to stop execution. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Feb 22 15:41:58 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 22 Feb 2013 15:41:58 +0100 +Subject: [99s-extend] Cowboy 0.8.1 +Message-ID: <512783B6.4060403@ninenines.eu> + +Just tagged Cowboy 0.8.1. + + https://github.com/extend/cowboy/ + +Please see the CHANGELOG.md file. + +I am hoping to tag a new minor version every couple weeks now that the +bigger API changes have been done. + +Next version should have the remaining REST API changes, bringing it +much closer to being stable, with only additions planned subsequently. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Sat Feb 23 16:52:47 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sat, 23 Feb 2013 16:52:47 +0100 +Subject: [99s-extend] Directory traversal vulnerability on Windows platform +Message-ID: <5128E5CF.5010106@ninenines.eu> + +A directory traversal vulnerability affecting all Windows platforms has +been discovered. Please follow these instructions to find out if you are +affected. Please take immediate action if you are. + +### Am I affected? + +You are if you match all of the following requirements: + + * You run Cowboy in production on the Windows platform + * You make use of `cowboy_static` (or `cowboy_http_static` in older +versions) + +### How serious is it? + +This vulnerability allows an attacker to request any file from your +system (only limited by the access rights of the user running the Erlang +VM). The attacker cannot list files through this vulnerability. This +however does not reduce the seriousness of this vulnerability as an +attacker can always use brute force or any other method to try to find +files on your system. + +### How can I fix it? + +No patch is currently available. + +You should temporarily switch to using IIS or any other web server for +serving the static files, or use a CDN instead. + +### How can I make sure this will not happen again? + +A fully cross-platform fix will be pushed to Cowboy in the coming days. + +This issue exists essentially because Windows isn't a supported platform +and we do not have the resources or knowledge to make the Windows +experience safe and smooth. + +If you are a Windows user, you can ensure that kind of issue does not +happen again by becoming a regular contributor and making sure the team +is aware of any potential issue that may arise on Windows. + +### Why disclose? + +Essentially for three reasons: + + * Considering the known user base, a very low number of people might +be hit by this issue + * A temporary fix is readily available + * Community help is needed to ensure a proper fix gets merged + +The following ticket can be used for tracking this issue: + + https://github.com/extend/cowboy/issues/447 + +Please ping this ticket if you are affected. Ignore if you are not. Thanks. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2013-February/000043.html b/_build/static/archives/extend/2013-February/000043.html new file mode 100644 index 00000000..36cbddbd --- /dev/null +++ b/_build/static/archives/extend/2013-February/000043.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Jeremy Ong + jeremy at quarkgames.com +
+ Mon Feb 4 21:10:21 CET 2013 +

+
+ +
It is rebar compatible
+
+https://github.com/extend/cowboy/blob/master/rebar.config
+
+I use it with rebar all the time.
+
+
+On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com> wrote:
+
+> Hi,
+> I understand the move away from Rebar but I'd like to see the project to
+> be still Rebar-compatible. Would that be a problem? Mainly I am thinking
+> about dependencies. The Cowboy Makefile assumes that Ranch is in its deps
+> folder. If Cowboy is a part of a bigger application, and most often it will
+> be in such a role rather than a standalone application, then all
+> dependencies should be kept in one place. In that case it would be the main
+> project's deps folder, not Cowboy's deps folder. Can the compilation
+> process be split into compiling Cowboy dependencies separately from Cowboy
+> itself?
+>
+> something like:
+>
+> all: compile-deps compile-cowboy
+>
+> Then if Cowboy is a dependency itself it may be just compiled without the
+> dependency (as it will be compiled when the main project is compiled).
+>
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130204/3c258140/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000044.html b/_build/static/archives/extend/2013-February/000044.html new file mode 100644 index 00000000..303f2249 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000044.html @@ -0,0 +1,115 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Grzegorz Junka + list1 at gjunka.com +
+ Mon Feb 4 22:50:14 CET 2013 +

+
+ +
deps/ranch:
+@mkdir -p $(DEPS_DIR)
+git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch
+cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN)
+
+
+Am I to understand that the only way of having the dependencies in 
+another folder than cowboy/deps is to use Rebar (e.g. if compiling using 
+the makefile it will always assume that dependencies are in local deps 
+folder)?
+
+Would be good to have a target to compile cowboy without dependencies.
+
+
+On 04/02/2013 20:10, Jeremy Ong wrote:
+> It is rebar compatible
+>
+> https://github.com/extend/cowboy/blob/master/rebar.config
+>
+> I use it with rebar all the time.
+>
+>
+> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com 
+> <mailto:list1 at gjunka.com>> wrote:
+>
+>     Hi,
+>     I understand the move away from Rebar but I'd like to see the
+>     project to be still Rebar-compatible. Would that be a problem?
+>     Mainly I am thinking about dependencies. The Cowboy Makefile
+>     assumes that Ranch is in its deps folder. If Cowboy is a part of a
+>     bigger application, and most often it will be in such a role
+>     rather than a standalone application, then all dependencies should
+>     be kept in one place. In that case it would be the main project's
+>     deps folder, not Cowboy's deps folder. Can the compilation process
+>     be split into compiling Cowboy dependencies separately from Cowboy
+>     itself?
+>
+>     something like:
+>
+>     all: compile-deps compile-cowboy
+>
+>     Then if Cowboy is a dependency itself it may be just compiled
+>     without the dependency (as it will be compiled when the main
+>     project is compiled).
+>
+>     _______________________________________________
+>     Extend mailing list
+>     Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>     http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130204/c34e6aa6/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000045.html b/_build/static/archives/extend/2013-February/000045.html new file mode 100644 index 00000000..4e04e930 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000045.html @@ -0,0 +1,134 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 4 22:58:39 CET 2013 +

+
+ +
Cowboy is still compatible with rebar like before, there's no change you 
+need to do.
+
+If however you would like to compile using the Makefile regardless, 
+there's a small thing that needs to be fixed before it's good.
+
+On 02/04/2013 10:50 PM, Grzegorz Junka wrote:
+> deps/ranch:
+> @mkdir -p $(DEPS_DIR)
+> git clone -n -- https://github.com/extend/ranch.git $(DEPS_DIR)/ranch
+> cd $(DEPS_DIR)/ranch ; git checkout -q $(RANCH_VSN)
+>
+>
+> Am I to understand that the only way of having the dependencies in
+> another folder than cowboy/deps is to use Rebar (e.g. if compiling using
+> the makefile it will always assume that dependencies are in local deps
+> folder)?
+>
+> Would be good to have a target to compile cowboy without dependencies.
+>
+>
+> On 04/02/2013 20:10, Jeremy Ong wrote:
+>> It is rebar compatible
+>>
+>> https://github.com/extend/cowboy/blob/master/rebar.config
+>>
+>> I use it with rebar all the time.
+>>
+>>
+>> On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <list1 at gjunka.com
+>> <mailto:list1 at gjunka.com>> wrote:
+>>
+>>     Hi,
+>>     I understand the move away from Rebar but I'd like to see the
+>>     project to be still Rebar-compatible. Would that be a problem?
+>>     Mainly I am thinking about dependencies. The Cowboy Makefile
+>>     assumes that Ranch is in its deps folder. If Cowboy is a part of a
+>>     bigger application, and most often it will be in such a role
+>>     rather than a standalone application, then all dependencies should
+>>     be kept in one place. In that case it would be the main project's
+>>     deps folder, not Cowboy's deps folder. Can the compilation process
+>>     be split into compiling Cowboy dependencies separately from Cowboy
+>>     itself?
+>>
+>>     something like:
+>>
+>>     all: compile-deps compile-cowboy
+>>
+>>     Then if Cowboy is a dependency itself it may be just compiled
+>>     without the dependency (as it will be compiled when the main
+>>     project is compiled).
+>>
+>>     _______________________________________________
+>>     Extend mailing list
+>>     Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>     http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000046.html b/_build/static/archives/extend/2013-February/000046.html new file mode 100644 index 00000000..eae5ae9f --- /dev/null +++ b/_build/static/archives/extend/2013-February/000046.html @@ -0,0 +1,69 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Sergey Yelin + elinsn at gmail.com +
+ Thu Feb 7 11:04:05 CET 2013 +

+
+ +
Hi list,
+
+how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+
+Thanks in advance.
+
+---
+Best regards,
+Sergey Yelin.
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000047.html b/_build/static/archives/extend/2013-February/000047.html new file mode 100644 index 00000000..4cc75a92 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000047.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 7 15:41:03 CET 2013 +

+
+ +
On 02/07/2013 11:04 AM, Sergey Yelin wrote:
+> Hi list,
+>
+> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+
+Hey,
+
+If you know the size, reply with {stream, Size, StreamFun}, otherwise 
+{stream, StreamFun}, with StreamFun the function that will send all the 
+data to the socket.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000048.html b/_build/static/archives/extend/2013-February/000048.html new file mode 100644 index 00000000..62ddba81 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000048.html @@ -0,0 +1,86 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Sergey Yelin + elinsn at gmail.com +
+ Thu Feb 7 15:46:31 CET 2013 +

+
+ +
Ok, thanks.
+
+On Feb 7, 2013, at 6:41 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 02/07/2013 11:04 AM, Sergey Yelin wrote:
+>> Hi list,
+>> 
+>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+> 
+> Hey,
+> 
+> If you know the size, reply with {stream, Size, StreamFun}, otherwise {stream, StreamFun}, with StreamFun the function that will send all the data to the socket.
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+---
+Best regards,
+Sergey Yelin.
+
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000049.html b/_build/static/archives/extend/2013-February/000049.html new file mode 100644 index 00000000..9a5040ee --- /dev/null +++ b/_build/static/archives/extend/2013-February/000049.html @@ -0,0 +1,74 @@ + + + + [99s-extend] How to send multiple messages in response to one message from Cowboy + + + + + + + + + + +

[99s-extend] How to send multiple messages in response to one message from Cowboy

+ John Kemp + john at jkemp.net +
+ Fri Feb 8 14:08:24 CET 2013 +

+
+ +
Hi,
+
+I see that with websocket_info/3 I can prompt Cowboy to send a message 
+to a connected client by sending a "system message".
+
+How can I send multiple reply messages to a client which has sent a request?
+
+Is the way to do that by calling websocket_info/3 directly (multiple 
+times) from within my websocket_handle call?
+
+Cheers,
+
+JohnK
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000050.html b/_build/static/archives/extend/2013-February/000050.html new file mode 100644 index 00000000..23828af8 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000050.html @@ -0,0 +1,100 @@ + + + + [99s-extend] How to send multiple messages in response to one message from Cowboy + + + + + + + + + + +

[99s-extend] How to send multiple messages in response to one message from Cowboy

+ John Kemp + john at jkemp.net +
+ Fri Feb 8 19:34:36 CET 2013 +

+
+ +
Answering my own question - multiple messages can be sent in reply by 
+including a list of 'reply' tuples in the websocket_handle response. I 
+found this by looking at cowboy_websocket_handler.erl in the source tree.
+
+-callback websocket_handle({text | binary | ping | pong, binary()}, Req, 
+State)
+	-> {ok, Req, State}
+	| {ok, Req, State, hibernate}
+
+	| {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, 
+State}
+	| {reply, cowboy_websocket:frame() | [cowboy_websocket:frame()], Req, 
+State, hibernate}
+
+	| {shutdown, Req, State}
+	when Req::cowboy_req:req(), State::state().
+
+JohnK
+
+On 02/08/2013 08:08 AM, John Kemp wrote:
+> Hi,
+>
+> I see that with websocket_info/3 I can prompt Cowboy to send a message
+> to a connected client by sending a "system message".
+>
+> How can I send multiple reply messages to a client which has sent a
+> request?
+>
+> Is the way to do that by calling websocket_info/3 directly (multiple
+> times) from within my websocket_handle call?
+>
+> Cheers,
+>
+> JohnK
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000051.html b/_build/static/archives/extend/2013-February/000051.html new file mode 100644 index 00000000..01827233 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000051.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Cowboy questions + + + + + + + + + + +

[99s-extend] Cowboy questions

+ Bip Thelin + bip at kivra.com +
+ Sun Feb 10 20:12:27 CET 2013 +

+
+ +
Hi,
+
+ I'm playing around with a middleware and request/responsehooks. A couple of questions that have surfaced:
+* Say I map a module to "/my/path[...]" and then curl "/my/path/even/more/stuff". Is there a way to retrieve the "rest" of the matched path, i.e. like cowboy_req:path_info/1 but just the rest, not the total path. The result I want is: [<<"even">>, <<"more">>, <<"stuff">>].
+* I've been trying to use a responsehook to ensure that a default content-type is set if none is specified. Been trying with cowboy_req:reply, coboy_req:set_resp_headers, etc. It doesn't seem to work that well. What's the preferred way?
+
+Regards,
+-Bip Thelin
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130210/1b9560c2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000052.html b/_build/static/archives/extend/2013-February/000052.html new file mode 100644 index 00000000..c2171e9a --- /dev/null +++ b/_build/static/archives/extend/2013-February/000052.html @@ -0,0 +1,119 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Feb 12 18:36:12 CET 2013 +

+
+ +
Hello there!
+
+Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, 
+REST and Websocket server.
+
+   https://github.com/extend/cowboy/
+
+The number of contributors who helped make this release considerably 
+increased. Cowboy is available thanks to the code contributions from 50 
+users, double from the last release where 25 contributed.
+
+The number of users has also greatly increased. Cowboy is being used in 
+ad bidding, set-top boxes, live TV events, content streaming services, 
+and many more exciting areas.
+
+This new version has many highlights. You can take a look at the 
+changelog for detailed information about the many changes.
+
+   https://github.com/extend/cowboy/blob/master/CHANGELOG.md
+
+Cowboy scalability has been greatly improved in this version. This has 
+been observed many times in production, including in the AdGear Tracker 
+project (http://ferd.ca/rtb-where-erlang-blooms.html) where updated 
+nodes were able to handle 2 times more requests compared to older nodes. 
+This improvement cannot be observed in "hello world" types of 
+benchmarks. An article will soon be published to explain the reasons for 
+this.
+
+Cowboy now features a brand new user guide. It is still a work in 
+progress, so please open a ticket on Github if something is missing or 
+incorrect.
+
+   http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction
+
+Remaining work before 1.0 include REST improvements and SPDY support. 
+The rest of the API should now be very close to stable.
+
+I am looking for a good writer who would like to co-author a Cowboy 
+book. The book will be accessible to people who don't know Erlang but 
+will also contain everything there is to know about Cowboy, making it 
+suitable for both beginners and experts. Contact me if you are interested.
+
+I now take donations in addition to commercial support options, to allow 
+individual users to help the project stay alive and kicking.
+
+   http://ninenines.eu/support
+
+Hope you enjoy it. As always, please send me as much feedback as 
+possible to help me improve things even more, preferrably through Github 
+tickets if it's related to code or documentation.
+
+Thanks for reading.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000053.html b/_build/static/archives/extend/2013-February/000053.html new file mode 100644 index 00000000..d8c5ac05 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000053.html @@ -0,0 +1,131 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.0

+ Jeremy Ong + jeremy at quarkgames.com +
+ Tue Feb 12 18:37:18 CET 2013 +

+
+ +
Congrats!
+
+
+On Tue, Feb 12, 2013 at 9:36 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Hello there!
+>
+> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP,
+> REST and Websocket server.
+>
+>   https://github.com/extend/**cowboy/ <https://github.com/extend/cowboy/>
+>
+> The number of contributors who helped make this release considerably
+> increased. Cowboy is available thanks to the code contributions from 50
+> users, double from the last release where 25 contributed.
+>
+> The number of users has also greatly increased. Cowboy is being used in ad
+> bidding, set-top boxes, live TV events, content streaming services, and
+> many more exciting areas.
+>
+> This new version has many highlights. You can take a look at the changelog
+> for detailed information about the many changes.
+>
+>   https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md<https://github.com/extend/cowboy/blob/master/CHANGELOG.md>
+>
+> Cowboy scalability has been greatly improved in this version. This has
+> been observed many times in production, including in the AdGear Tracker
+> project (http://ferd.ca/rtb-where-**erlang-blooms.html<http://ferd.ca/rtb-where-erlang-blooms.html>)
+> where updated nodes were able to handle 2 times more requests compared to
+> older nodes. This improvement cannot be observed in "hello world" types of
+> benchmarks. An article will soon be published to explain the reasons for
+> this.
+>
+> Cowboy now features a brand new user guide. It is still a work in
+> progress, so please open a ticket on Github if something is missing or
+> incorrect.
+>
+>   http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction<http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction>
+>
+> Remaining work before 1.0 include REST improvements and SPDY support. The
+> rest of the API should now be very close to stable.
+>
+> I am looking for a good writer who would like to co-author a Cowboy book.
+> The book will be accessible to people who don't know Erlang but will also
+> contain everything there is to know about Cowboy, making it suitable for
+> both beginners and experts. Contact me if you are interested.
+>
+> I now take donations in addition to commercial support options, to allow
+> individual users to help the project stay alive and kicking.
+>
+>   http://ninenines.eu/support
+>
+> Hope you enjoy it. As always, please send me as much feedback as possible
+> to help me improve things even more, preferrably through Github tickets if
+> it's related to code or documentation.
+>
+> Thanks for reading.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130212/09008370/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000054.html b/_build/static/archives/extend/2013-February/000054.html new file mode 100644 index 00000000..29525584 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000054.html @@ -0,0 +1,68 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0

+ Max Lapshin + max.lapshin at gmail.com +
+ Tue Feb 12 18:44:28 CET 2013 +

+
+ +
Great, Loic.
+
+As I've told already, it would be great to listen to your experience about
+issues that you meet on high loads: smooth scaling, predictionable
+behaviour of server, etc.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130212/dc0291b4/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000055.html b/_build/static/archives/extend/2013-February/000055.html new file mode 100644 index 00000000..9d3e7817 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000055.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Wed Feb 13 14:52:10 CET 2013 +

+
+ +
+  In 6.1, and still in 8.0, there is some logic that surprised me, and I wanted to see if it was intentional, or if I'm missing something.
+
+  If I set up a POST such that it's a create, I get back a 303, rather than a 201, on successful create. This came as a bit of a surprise; I know from Webmachine, if it's a new resource being created, a POST will return a 201 (N11 to P11 in Webmachine's v3 diagram).
+
+  Is this intentional? The logic seems to be post_is_create/2 -> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> respond(_, _, 303). It may be that this is a better response, rather than a 201 with the location header, but it came as a surprise given web machine's behavior.
+
+  For background, I'm attempting to migrate some web machine code to Cowboy, which is serving a RESTful API to a Javascript client. The client is making CORS calls. Receiving a 303 and a Location header seemed to mean that the call was redirected before the client side code ever saw it (not sure what the browser was doing; I was expecting another request, but I wasn't quite lucid enough to check for that last night when working on it); a 201 allows me to examine the location.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130213/a992c0b6/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000056.html b/_build/static/archives/extend/2013-February/000056.html new file mode 100644 index 00000000..1a6087c9 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000056.html @@ -0,0 +1,131 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 0.8.0

+ Jesse Gumm + gumm at sigma-star.com +
+ Wed Feb 13 14:46:07 CET 2013 +

+
+ +
Great news!
+
+Congrats!
+On Feb 12, 2013 11:36 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+> Hello there!
+>
+> Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP,
+> REST and Websocket server.
+>
+>   https://github.com/extend/**cowboy/ <https://github.com/extend/cowboy/>
+>
+> The number of contributors who helped make this release considerably
+> increased. Cowboy is available thanks to the code contributions from 50
+> users, double from the last release where 25 contributed.
+>
+> The number of users has also greatly increased. Cowboy is being used in ad
+> bidding, set-top boxes, live TV events, content streaming services, and
+> many more exciting areas.
+>
+> This new version has many highlights. You can take a look at the changelog
+> for detailed information about the many changes.
+>
+>   https://github.com/extend/**cowboy/blob/master/CHANGELOG.**md<https://github.com/extend/cowboy/blob/master/CHANGELOG.md>
+>
+> Cowboy scalability has been greatly improved in this version. This has
+> been observed many times in production, including in the AdGear Tracker
+> project (http://ferd.ca/rtb-where-**erlang-blooms.html<http://ferd.ca/rtb-where-erlang-blooms.html>)
+> where updated nodes were able to handle 2 times more requests compared to
+> older nodes. This improvement cannot be observed in "hello world" types of
+> benchmarks. An article will soon be published to explain the reasons for
+> this.
+>
+> Cowboy now features a brand new user guide. It is still a work in
+> progress, so please open a ticket on Github if something is missing or
+> incorrect.
+>
+>   http://ninenines.eu/docs/en/**cowboy/HEAD/guide/introduction<http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction>
+>
+> Remaining work before 1.0 include REST improvements and SPDY support. The
+> rest of the API should now be very close to stable.
+>
+> I am looking for a good writer who would like to co-author a Cowboy book.
+> The book will be accessible to people who don't know Erlang but will also
+> contain everything there is to know about Cowboy, making it suitable for
+> both beginners and experts. Contact me if you are interested.
+>
+> I now take donations in addition to commercial support options, to allow
+> individual users to help the project stay alive and kicking.
+>
+>   http://ninenines.eu/support
+>
+> Hope you enjoy it. As always, please send me as much feedback as possible
+> to help me improve things even more, preferrably through Github tickets if
+> it's related to code or documentation.
+>
+> Thanks for reading.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130213/41b12a6d/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000057.html b/_build/static/archives/extend/2013-February/000057.html new file mode 100644 index 00000000..9a7004d5 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000057.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Feb 13 16:34:54 CET 2013 +

+
+ +
On 02/13/2013 02:52 PM, Phillips, Christopher wrote:
+>
+>    In 6.1, and still in 8.0, there is some logic that surprised me, and
+> I wanted to see if it was intentional, or if I'm missing something.
+>
+>    If I set up a POST such that it's a create, I get back a 303, rather
+> than a 201, on successful create. This came as a bit of a surprise; I
+> know from Webmachine, if it's a new resource being created, a POST will
+> return a 201 (N11 to P11 in Webmachine's v3 diagram).
+>
+>    Is this intentional? The logic seems to be post_is_create/2 ->
+> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 ->
+> respond(_, _, 303). It may be that this is a better response, rather
+> than a 201 with the location header, but it came as a surprise given web
+> machine's behavior.
+
+This difference is probably not intentional. Please open a ticket. :)
+
+>    For background, I'm attempting to migrate some web machine code to
+> Cowboy, which is serving a RESTful API to a Javascript client. The
+> client is making CORS calls. Receiving a 303 and a Location header
+> seemed to mean that the call was redirected before the client side code
+> ever saw it (not sure what the browser was doing; I was expecting
+> another request, but I wasn't quite lucid enough to check for that last
+> night when working on it); a 201 allows me to examine the location.
+
+Would be interested to know more about your CORS implementation, that's 
+something I would like to have in the guide.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000058.html b/_build/static/archives/extend/2013-February/000058.html new file mode 100644 index 00000000..2f44c8c7 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000058.html @@ -0,0 +1,137 @@ + + + + [99s-extend] Cowboy REST Logic + + + + + + + + + + +

[99s-extend] Cowboy REST Logic

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Wed Feb 13 17:01:27 CET 2013 +

+
+ +
  Will do. I actually like the 303 due to a bug in Firefox with examining
+headers, but 201 seems like the canonical approach.
+  
+  CORS is actually pretty easy to open up fully, and the more restrictive
+you want to be the harder it gets. We're not using credentials, and we
+haven't tightened the domain to just those we expect, either, but it
+basically amounts to adding the following to options/2 for the pre-flight -
+
+  * Access-Control-Allow-Origin (with the origins we want to allow; * for
+anything), 
+  * Access-Control-Allow-Headers (which we're setting to the same as the
+client requests for convenience's sake)
+  *Access-Control-Expose-Headers (for any headers beyond content-type that
+the client wants access to; we have Location for the 201 mentioned above.
+
+
+And the following to any request being passed back, as seems reasonable -
+
+  * Access-Control-Allow-Origin as in options
+  * Access-Control-Expose-Headers as in options
+
+
+ I'm appending them in resource_exists/2 because I know that will be hit
+by everything. If your logic is more complex (you want to allow PUTs from
+site1, but deletes from site2, etc), you'll need to break that apart a bit
+and conditionally check origin. We're relying on a firewall to protect
+against direct calls from external servers, and we'll be tightening the
+allowed domains and looking into validating the session with a token to
+prevent CSRFs (as CORS means any existing CSRF vuln becomes a bit more
+severe). 
+
+
+I suspect there's some redundancy there; we have a future story for
+tightening things up, but in terms of just opening it up and getting
+things working, that¹s all that I had to do.
+
+
+On 2/13/13 10:34 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+>On 02/13/2013 02:52 PM, Phillips, Christopher wrote:
+>>
+>>    In 6.1, and still in 8.0, there is some logic that surprised me, and
+>> I wanted to see if it was intentional, or if I'm missing something.
+>>
+>>    If I set up a POST such that it's a create, I get back a 303, rather
+>> than a 201, on successful create. This came as a bit of a surprise; I
+>> know from Webmachine, if it's a new resource being created, a POST will
+>> return a 201 (N11 to P11 in Webmachine's v3 diagram).
+>>
+>>    Is this intentional? The logic seems to be post_is_create/2 ->
+>> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 ->
+>> respond(_, _, 303). It may be that this is a better response, rather
+>> than a 201 with the location header, but it came as a surprise given web
+>> machine's behavior.
+>
+>This difference is probably not intentional. Please open a ticket. :)
+>
+>>    For background, I'm attempting to migrate some web machine code to
+>> Cowboy, which is serving a RESTful API to a Javascript client. The
+>> client is making CORS calls. Receiving a 303 and a Location header
+>> seemed to mean that the call was redirected before the client side code
+>> ever saw it (not sure what the browser was doing; I was expecting
+>> another request, but I wasn't quite lucid enough to check for that last
+>> night when working on it); a 201 allows me to examine the location.
+>
+>Would be interested to know more about your CORS implementation, that's
+>something I would like to have in the guide.
+>
+>-- 
+>Loïc Hoguin
+>Erlang Cowboy
+>Nine Nines
+>http://ninenines.eu
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000059.html b/_build/static/archives/extend/2013-February/000059.html new file mode 100644 index 00000000..edd489c4 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000059.html @@ -0,0 +1,77 @@ + + + + [99s-extend] [ANN] Bullet 0.4.0 + + + + + + + + + + +

[99s-extend] [ANN] Bullet 0.4.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 14 17:29:23 CET 2013 +

+
+ +
Quick announcement: Bullet 0.4.0 has been released. This version is 
+compatible with newly released Cowboy 0.8.0.
+
+   https://github.com/extend/bullet
+
+Bullet is a simple and efficient Websocket alternative especially useful 
+when you need an always connected socket to the server. It uses 
+Websocket internally when it's available.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000060.html b/_build/static/archives/extend/2013-February/000060.html new file mode 100644 index 00000000..0e16e401 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000060.html @@ -0,0 +1,74 @@ + + + + [99s-extend] sub_description is not a valid app configuration option + + + + + + + + + + +

[99s-extend] sub_description is not a valid app configuration option

+ Grzegorz Junka + list1 at gjunka.com +
+ Mon Feb 18 17:01:30 CET 2013 +

+
+ +
Hi,
+I am trying to compile a release with some applications for which ranch 
+and cowboy are dependencies. This is what I am getting on the console:
+
+reltool: Unexpected item sub_description in app file 
+"/usr/home/somepath/deps/ranch/ebin/ranch.app".
+reltool: Unexpected item sub_description in app file 
+"/usr/home/somepath/deps/cowboy/ebin/cowboy.app".
+
+When looking it up on Erlang documentation it seems that sub_description 
+is not a valid configuration options in the .app file. Is there any 
+chance to put it rather as a comment?
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000061.html b/_build/static/archives/extend/2013-February/000061.html new file mode 100644 index 00000000..c737d54e --- /dev/null +++ b/_build/static/archives/extend/2013-February/000061.html @@ -0,0 +1,70 @@ + + + + [99s-extend] [ANN] Bullet 0.4.1 + + + + + + + + + + +

[99s-extend] [ANN] Bullet 0.4.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Feb 20 19:58:31 CET 2013 +

+
+ +
Version update to fix a bug that broke POST with non-Websocket transports.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000062.html b/_build/static/archives/extend/2013-February/000062.html new file mode 100644 index 00000000..077c5e97 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000062.html @@ -0,0 +1,65 @@ + + + + [99s-extend] Arbitrary 500 from REST handler? + + + + + + + + + + +

[99s-extend] Arbitrary 500 from REST handler?

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Thu Feb 21 20:29:36 CET 2013 +

+
+ +
+  I have a case where I am creating a resource through a POST. There are a number of places where the create can fail in a known manner, and we need to alert the user to the specifics of why. Is there a way to throw an arbitrary 500, with message, from within the REST handler? I can obviously just erlang:error(whatever), but the message content is ignored, and there is no way to pass back an updated response when doing that.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130221/fc119c69/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000063.html b/_build/static/archives/extend/2013-February/000063.html new file mode 100644 index 00000000..bfebf6d7 --- /dev/null +++ b/_build/static/archives/extend/2013-February/000063.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Arbitrary 500 from REST handler? + + + + + + + + + + +

[99s-extend] Arbitrary 500 from REST handler?

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Feb 21 20:38:35 CET 2013 +

+
+ +
On 02/21/2013 08:29 PM, Phillips, Christopher wrote:
+>
+>    I have a case where I am creating a resource through a POST. There
+> are a number of places where the create can fail in a known manner, and
+> we need to alert the user to the specifics of why. Is there a way to
+> throw an arbitrary 500, with message, from within the REST handler? I
+> can obviously just erlang:error(whatever), but the message content is
+> ignored, and there is no way to pass back an updated response when doing
+> that.
+
+Use cowboy_req:reply and then return {halt, Req2, State} to stop execution.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000064.html b/_build/static/archives/extend/2013-February/000064.html new file mode 100644 index 00000000..89b3839d --- /dev/null +++ b/_build/static/archives/extend/2013-February/000064.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Cowboy 0.8.1 + + + + + + + + + + +

[99s-extend] Cowboy 0.8.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Feb 22 15:41:58 CET 2013 +

+
+ +
Just tagged Cowboy 0.8.1.
+
+   https://github.com/extend/cowboy/
+
+Please see the CHANGELOG.md file.
+
+I am hoping to tag a new minor version every couple weeks now that the 
+bigger API changes have been done.
+
+Next version should have the remaining REST API changes, bringing it 
+much closer to being stable, with only additions planned subsequently.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/000065.html b/_build/static/archives/extend/2013-February/000065.html new file mode 100644 index 00000000..8747e30f --- /dev/null +++ b/_build/static/archives/extend/2013-February/000065.html @@ -0,0 +1,119 @@ + + + + [99s-extend] Directory traversal vulnerability on Windows platform + + + + + + + + + + +

[99s-extend] Directory traversal vulnerability on Windows platform

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Feb 23 16:52:47 CET 2013 +

+
+ +
A directory traversal vulnerability affecting all Windows platforms has 
+been discovered. Please follow these instructions to find out if you are 
+affected. Please take immediate action if you are.
+
+### Am I affected?
+
+You are if you match all of the following requirements:
+
+  *  You run Cowboy in production on the Windows platform
+  *  You make use of `cowboy_static` (or `cowboy_http_static` in older 
+versions)
+
+### How serious is it?
+
+This vulnerability allows an attacker to request any file from your 
+system (only limited by the access rights of the user running the Erlang 
+VM). The attacker cannot list files through this vulnerability. This 
+however does not reduce the seriousness of this vulnerability as an 
+attacker can always use brute force or any other method to try to find 
+files on your system.
+
+### How can I fix it?
+
+No patch is currently available.
+
+You should temporarily switch to using IIS or any other web server for 
+serving the static files, or use a CDN instead.
+
+### How can I make sure this will not happen again?
+
+A fully cross-platform fix will be pushed to Cowboy in the coming days.
+
+This issue exists essentially because Windows isn't a supported platform 
+and we do not have the resources or knowledge to make the Windows 
+experience safe and smooth.
+
+If you are a Windows user, you can ensure that kind of issue does not 
+happen again by becoming a regular contributor and making sure the team 
+is aware of any potential issue that may arise on Windows.
+
+### Why disclose?
+
+Essentially for three reasons:
+
+  *  Considering the known user base, a very low number of people might 
+be hit by this issue
+  *  A temporary fix is readily available
+  *  Community help is needed to ensure a proper fix gets merged
+
+The following ticket can be used for tracking this issue:
+
+   https://github.com/extend/cowboy/issues/447
+
+Please ping this ticket if you are affected. Ignore if you are not. Thanks.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-February/author.html b/_build/static/archives/extend/2013-February/author.html new file mode 100644 index 00000000..a21788bd --- /dev/null +++ b/_build/static/archives/extend/2013-February/author.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by author + + + + + +

February 2013 Archives by author

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-February/date.html b/_build/static/archives/extend/2013-February/date.html new file mode 100644 index 00000000..07cd4de8 --- /dev/null +++ b/_build/static/archives/extend/2013-February/date.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by date + + + + + +

February 2013 Archives by date

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-February/index.html b/_build/static/archives/extend/2013-February/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-February/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-February/subject.html b/_build/static/archives/extend/2013-February/subject.html new file mode 100644 index 00000000..3402dfab --- /dev/null +++ b/_build/static/archives/extend/2013-February/subject.html @@ -0,0 +1,162 @@ + + + + The Extend February 2013 Archive by subject + + + + + +

February 2013 Archives by subject

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-February/thread.html b/_build/static/archives/extend/2013-February/thread.html new file mode 100644 index 00000000..4dc2b5dd --- /dev/null +++ b/_build/static/archives/extend/2013-February/thread.html @@ -0,0 +1,205 @@ + + + + The Extend February 2013 Archive by thread + + + + + +

February 2013 Archives by thread

+ +

Starting: Mon Feb 4 21:10:21 CET 2013
+ Ending: Sat Feb 23 16:52:47 CET 2013
+ Messages: 23

+

+

+ Last message date: + Sat Feb 23 16:52:47 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-January.txt b/_build/static/archives/extend/2013-January.txt new file mode 100644 index 00000000..1f4beb61 --- /dev/null +++ b/_build/static/archives/extend/2013-January.txt @@ -0,0 +1,1000 @@ +From max.lapshin at gmail.com Thu Jan 3 10:30:30 2013 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Thu, 3 Jan 2013 12:30:30 +0300 +Subject: [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition + Released +In-Reply-To: <50D8DA63.2060600@ninenines.eu> +References: <50D8DA63.2060600@ninenines.eu> +Message-ID: + +Loic, it would be great to hear a bit, what problems have you met with. + +What issues with stability can be in acceptor pool? + +Also I have question about updating protocol options: have you done +something with the problem that after updating protocol options existing +workers are running with old config? + +On Tuesday, December 25, 2012, Lo?c Hoguin wrote: + +> Ho ho ho! +> +> I have just tagged version 0.6.0 of the Ranch project! +> +> Ranch is a socket acceptor pool for TCP protocols. +> +> https://github.com/extend/**ranch +> +> Ranch is used by the next version of Cowboy, 0.8.0, set to be released +> early February, but also in Basho's Riak multi-data center replication +> amongst others. +> +> All tickets have been resolved. A significant contribution was made by +> Andrew Majorov to improve the fault tolerance capabilities of the +> application, making sure it always restarts properly when things go wrong. +> This has been made possible thanks to the amazing project from Daniel Luna, +> chaos_monkey (https://github.com/dluna/**chaos_monkey +> ). +> +> The guide has also been improved and completed. +> +> http://ninenines.eu/docs/en/**ranch/HEAD/guide/introduction +> +> If the guide isn't enough, drop by our new IRC channel dedicated to +> Cowboy, Ranch and all our other projects! #ninenines on Freenode. +> +> Following is the list of change since last time: +> +> * Improve fault tolerance thanks to chaos_monkey testing +> * Add 'nodelay' option to transports +> * Add 'verify' option to ranch_ssl transport +> * Add 'socket' option to pass an already open socket to the listener +> * Add Transport:sendfile/2 function (uses a fallback if unavailable) +> * Allow IP tuples in Transport:connect/3 +> * Add ranch:set_max_connections/2 to update the value live +> * Add ranch:get_max_connections/1 to retrieve it +> +> We are always looking for feedback, especially now that there is no ticket +> left open on this project. If you are using Ranch and have questions or +> needs that it doesn't cover, please send them to us. +> +> Commercial support will be available starting from January, ping me if you +> are interested. Details will be announced at a later time on the +> ninenines.eu mailing list. +> +> I want to thank all contributors for helping this project by opening +> tickets, sending patches and offering feedback. I am as always very +> grateful for any and all contributions. I wouldn't have made it this far +> without the tremendous help I receive everyday. +> +> Thanks to all and have a nice holiday! +> +> -- +> Lo?c Hoguin +> Erlang Santa +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/**listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jan 3 13:46:56 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 03 Jan 2013 13:46:56 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition + Released +In-Reply-To: +References: <50D8DA63.2060600@ninenines.eu> + +Message-ID: <50E57DC0.5090408@ninenines.eu> + +Haven't had any stability issue. What we did here is ensure that when +any process gets killed for any reason, especially reasons we can't +foresee, Ranch continues to work as expected. + +Ranch not updating protocol options for existing connections isn't a +problem, it won't be "fixed". Ranch can't guess how connection processes +are implemented. It's up to you to allow this if you need it. The +upgrade updates the options for all acceptors and all future +connections, that's it. + +On 01/03/2013 10:30 AM, Max Lapshin wrote: +> Loic, it would be great to hear a bit, what problems have you met with. +> +> What issues with stability can be in acceptor pool? +> +> Also I have question about updating protocol options: have you done +> something with the problem that after updating protocol options existing +> workers are running with old config? +> +> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: +> +> Ho ho ho! +> +> I have just tagged version 0.6.0 of the Ranch project! +> +> Ranch is a socket acceptor pool for TCP protocols. +> +> https://github.com/extend/__ranch +> +> Ranch is used by the next version of Cowboy, 0.8.0, set to be +> released early February, but also in Basho's Riak multi-data center +> replication amongst others. +> +> All tickets have been resolved. A significant contribution was made +> by Andrew Majorov to improve the fault tolerance capabilities of the +> application, making sure it always restarts properly when things go +> wrong. This has been made possible thanks to the amazing project +> from Daniel Luna, chaos_monkey +> (https://github.com/dluna/__chaos_monkey +> ). +> +> The guide has also been improved and completed. +> +> http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction +> +> +> If the guide isn't enough, drop by our new IRC channel dedicated to +> Cowboy, Ranch and all our other projects! #ninenines on Freenode. +> +> Following is the list of change since last time: +> +> * Improve fault tolerance thanks to chaos_monkey testing +> * Add 'nodelay' option to transports +> * Add 'verify' option to ranch_ssl transport +> * Add 'socket' option to pass an already open socket to the listener +> * Add Transport:sendfile/2 function (uses a fallback if unavailable) +> * Allow IP tuples in Transport:connect/3 +> * Add ranch:set_max_connections/2 to update the value live +> * Add ranch:get_max_connections/1 to retrieve it +> +> We are always looking for feedback, especially now that there is no +> ticket left open on this project. If you are using Ranch and have +> questions or needs that it doesn't cover, please send them to us. +> +> Commercial support will be available starting from January, ping me +> if you are interested. Details will be announced at a later time on +> the ninenines.eu mailing list. +> +> I want to thank all contributors for helping this project by opening +> tickets, sending patches and offering feedback. I am as always very +> grateful for any and all contributions. I wouldn't have made it this +> far without the tremendous help I receive everyday. +> +> Thanks to all and have a nice holiday! +> +> -- +> Lo?c Hoguin +> Erlang Santa +> Nine Nines +> http://ninenines.eu +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/__listinfo/erlang-questions +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From max.lapshin at gmail.com Thu Jan 3 14:32:16 2013 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Thu, 3 Jan 2013 16:32:16 +0300 +Subject: [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition + Released +In-Reply-To: <50E57DC0.5090408@ninenines.eu> +References: <50D8DA63.2060600@ninenines.eu> + + <50E57DC0.5090408@ninenines.eu> +Message-ID: + +I mean situation that after cowboy:update_options existing acceptors are +still working with old routes. +Currently it is useless API, so I have to stop cowboy and start it back. + + +On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin wrote: + +> Haven't had any stability issue. What we did here is ensure that when any +> process gets killed for any reason, especially reasons we can't foresee, +> Ranch continues to work as expected. +> +> Ranch not updating protocol options for existing connections isn't a +> problem, it won't be "fixed". Ranch can't guess how connection processes +> are implemented. It's up to you to allow this if you need it. The upgrade +> updates the options for all acceptors and all future connections, that's it. +> +> +> On 01/03/2013 10:30 AM, Max Lapshin wrote: +> +>> Loic, it would be great to hear a bit, what problems have you met with. +>> +>> What issues with stability can be in acceptor pool? +>> +>> Also I have question about updating protocol options: have you done +>> something with the problem that after updating protocol options existing +>> workers are running with old config? +>> +>> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: +>> +>> Ho ho ho! +>> +>> I have just tagged version 0.6.0 of the Ranch project! +>> +>> Ranch is a socket acceptor pool for TCP protocols. +>> +>> https://github.com/extend/__**ranch< +>> https://github.com/extend/**ranch > +>> +>> +>> Ranch is used by the next version of Cowboy, 0.8.0, set to be +>> released early February, but also in Basho's Riak multi-data center +>> replication amongst others. +>> +>> All tickets have been resolved. A significant contribution was made +>> by Andrew Majorov to improve the fault tolerance capabilities of the +>> application, making sure it always restarts properly when things go +>> wrong. This has been made possible thanks to the amazing project +>> from Daniel Luna, chaos_monkey +>> (https://github.com/dluna/__**chaos_monkey +>> +>> >). +>> +>> +>> The guide has also been improved and completed. +>> +>> http://ninenines.eu/docs/en/__**ranch/HEAD/guide/introduction +>> +>> +>> > +>> +>> If the guide isn't enough, drop by our new IRC channel dedicated to +>> Cowboy, Ranch and all our other projects! #ninenines on Freenode. +>> +>> Following is the list of change since last time: +>> +>> * Improve fault tolerance thanks to chaos_monkey testing +>> * Add 'nodelay' option to transports +>> * Add 'verify' option to ranch_ssl transport +>> * Add 'socket' option to pass an already open socket to the +>> listener +>> * Add Transport:sendfile/2 function (uses a fallback if +>> unavailable) +>> * Allow IP tuples in Transport:connect/3 +>> * Add ranch:set_max_connections/2 to update the value live +>> * Add ranch:get_max_connections/1 to retrieve it +>> +>> We are always looking for feedback, especially now that there is no +>> ticket left open on this project. If you are using Ranch and have +>> questions or needs that it doesn't cover, please send them to us. +>> +>> Commercial support will be available starting from January, ping me +>> if you are interested. Details will be announced at a later time on +>> the ninenines.eu mailing list. +>> +>> +>> I want to thank all contributors for helping this project by opening +>> tickets, sending patches and offering feedback. I am as always very +>> grateful for any and all contributions. I wouldn't have made it this +>> far without the tremendous help I receive everyday. +>> +>> Thanks to all and have a nice holiday! +>> +>> -- +>> Lo?c Hoguin +>> Erlang Santa +>> Nine Nines +>> http://ninenines.eu +>> ______________________________**___________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/__**listinfo/erlang-questions +>> +>> > +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jan 3 14:51:48 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 03 Jan 2013 14:51:48 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition + Released +In-Reply-To: +References: <50D8DA63.2060600@ninenines.eu> + + <50E57DC0.5090408@ninenines.eu> + +Message-ID: <50E58CF4.9080804@ninenines.eu> + +Existing acceptors were using the old options for the next connection +and then switched to the new options. But that has been fixed a long +time ago. Ranch doesn't have that issue. + +On 01/03/2013 02:32 PM, Max Lapshin wrote: +> I mean situation that after cowboy:update_options existing acceptors are +> still working with old routes. +> Currently it is useless API, so I have to stop cowboy and start it back. +> +> +> On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin > wrote: +> +> Haven't had any stability issue. What we did here is ensure that +> when any process gets killed for any reason, especially reasons we +> can't foresee, Ranch continues to work as expected. +> +> Ranch not updating protocol options for existing connections isn't a +> problem, it won't be "fixed". Ranch can't guess how connection +> processes are implemented. It's up to you to allow this if you need +> it. The upgrade updates the options for all acceptors and all future +> connections, that's it. +> +> +> On 01/03/2013 10:30 AM, Max Lapshin wrote: +> +> Loic, it would be great to hear a bit, what problems have you +> met with. +> +> What issues with stability can be in acceptor pool? +> +> Also I have question about updating protocol options: have you done +> something with the problem that after updating protocol options +> existing +> workers are running with old config? +> +> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: +> +> Ho ho ho! +> +> I have just tagged version 0.6.0 of the Ranch project! +> +> Ranch is a socket acceptor pool for TCP protocols. +> +> https://github.com/extend/____ranch +> +> > +> +> +> Ranch is used by the next version of Cowboy, 0.8.0, set to be +> released early February, but also in Basho's Riak +> multi-data center +> replication amongst others. +> +> All tickets have been resolved. A significant contribution +> was made +> by Andrew Majorov to improve the fault tolerance +> capabilities of the +> application, making sure it always restarts properly when +> things go +> wrong. This has been made possible thanks to the amazing +> project +> from Daniel Luna, chaos_monkey +> (https://github.com/dluna/____chaos_monkey +> +> >). +> +> +> The guide has also been improved and completed. +> +> http://ninenines.eu/docs/en/____ranch/HEAD/guide/introduction +> +> +> +> > +> +> If the guide isn't enough, drop by our new IRC channel +> dedicated to +> Cowboy, Ranch and all our other projects! #ninenines on +> Freenode. +> +> Following is the list of change since last time: +> +> * Improve fault tolerance thanks to chaos_monkey testing +> * Add 'nodelay' option to transports +> * Add 'verify' option to ranch_ssl transport +> * Add 'socket' option to pass an already open socket to +> the listener +> * Add Transport:sendfile/2 function (uses a fallback if +> unavailable) +> * Allow IP tuples in Transport:connect/3 +> * Add ranch:set_max_connections/2 to update the value live +> * Add ranch:get_max_connections/1 to retrieve it +> +> We are always looking for feedback, especially now that +> there is no +> ticket left open on this project. If you are using Ranch +> and have +> questions or needs that it doesn't cover, please send them +> to us. +> +> Commercial support will be available starting from January, +> ping me +> if you are interested. Details will be announced at a later +> time on +> the ninenines.eu +> mailing list. +> +> +> I want to thank all contributors for helping this project +> by opening +> tickets, sending patches and offering feedback. I am as +> always very +> grateful for any and all contributions. I wouldn't have +> made it this +> far without the tremendous help I receive everyday. +> +> Thanks to all and have a nice holiday! +> +> -- +> Lo?c Hoguin +> Erlang Santa +> Nine Nines +> http://ninenines.eu +> ___________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/____listinfo/erlang-questions +> +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From max.lapshin at gmail.com Thu Jan 3 15:00:56 2013 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Thu, 3 Jan 2013 17:00:56 +0300 +Subject: [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition + Released +In-Reply-To: <50E58CF4.9080804@ninenines.eu> +References: <50D8DA63.2060600@ninenines.eu> + + <50E57DC0.5090408@ninenines.eu> + + <50E58CF4.9080804@ninenines.eu> +Message-ID: + +ok + + +On Thu, Jan 3, 2013 at 5:51 PM, Lo?c Hoguin wrote: + +> Existing acceptors were using the old options for the next connection and +> then switched to the new options. But that has been fixed a long time ago. +> Ranch doesn't have that issue. +> +> +> On 01/03/2013 02:32 PM, Max Lapshin wrote: +> +>> I mean situation that after cowboy:update_options existing acceptors are +>> still working with old routes. +>> Currently it is useless API, so I have to stop cowboy and start it back. +>> +>> +>> On Thu, Jan 3, 2013 at 4:46 PM, Lo?c Hoguin > > wrote: +>> +>> Haven't had any stability issue. What we did here is ensure that +>> when any process gets killed for any reason, especially reasons we +>> can't foresee, Ranch continues to work as expected. +>> +>> Ranch not updating protocol options for existing connections isn't a +>> problem, it won't be "fixed". Ranch can't guess how connection +>> processes are implemented. It's up to you to allow this if you need +>> it. The upgrade updates the options for all acceptors and all future +>> connections, that's it. +>> +>> +>> On 01/03/2013 10:30 AM, Max Lapshin wrote: +>> +>> Loic, it would be great to hear a bit, what problems have you +>> met with. +>> +>> What issues with stability can be in acceptor pool? +>> +>> Also I have question about updating protocol options: have you +>> done +>> something with the problem that after updating protocol options +>> existing +>> workers are running with old config? +>> +>> On Tuesday, December 25, 2012, Lo?c Hoguin wrote: +>> +>> Ho ho ho! +>> +>> I have just tagged version 0.6.0 of the Ranch project! +>> +>> Ranch is a socket acceptor pool for TCP protocols. +>> +>> https://github.com/extend/____**ranch +>> +>> > +>> +>> +>> +>> >> +>> +>> +>> Ranch is used by the next version of Cowboy, 0.8.0, set to be +>> released early February, but also in Basho's Riak +>> multi-data center +>> replication amongst others. +>> +>> All tickets have been resolved. A significant contribution +>> was made +>> by Andrew Majorov to improve the fault tolerance +>> capabilities of the +>> application, making sure it always restarts properly when +>> things go +>> wrong. This has been made possible thanks to the amazing +>> project +>> from Daniel Luna, chaos_monkey +>> (https://github.com/dluna/____**chaos_monkey +>> +>> > +>> +>> +>> +>> >>). +>> +>> +>> The guide has also been improved and completed. +>> +>> http://ninenines.eu/docs/en/__**__ranch/HEAD/guide/**introduction +>> +>> **> +>> +>> +>> +>> +>> +>> >**> +>> +>> If the guide isn't enough, drop by our new IRC channel +>> dedicated to +>> Cowboy, Ranch and all our other projects! #ninenines on +>> Freenode. +>> +>> Following is the list of change since last time: +>> +>> * Improve fault tolerance thanks to chaos_monkey testing +>> * Add 'nodelay' option to transports +>> * Add 'verify' option to ranch_ssl transport +>> * Add 'socket' option to pass an already open socket to +>> the listener +>> * Add Transport:sendfile/2 function (uses a fallback if +>> unavailable) +>> * Allow IP tuples in Transport:connect/3 +>> * Add ranch:set_max_connections/2 to update the value live +>> * Add ranch:get_max_connections/1 to retrieve it +>> +>> We are always looking for feedback, especially now that +>> there is no +>> ticket left open on this project. If you are using Ranch +>> and have +>> questions or needs that it doesn't cover, please send them +>> to us. +>> +>> Commercial support will be available starting from January, +>> ping me +>> if you are interested. Details will be announced at a later +>> time on +>> the ninenines.eu +>> mailing list. +>> +>> +>> I want to thank all contributors for helping this project +>> by opening +>> tickets, sending patches and offering feedback. I am as +>> always very +>> grateful for any and all contributions. I wouldn't have +>> made it this +>> far without the tremendous help I receive everyday. +>> +>> Thanks to all and have a nice holiday! +>> +>> -- +>> Lo?c Hoguin +>> Erlang Santa +>> Nine Nines +>> http://ninenines.eu +>> ______________________________**_____________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> > +>> http://erlang.org/mailman/____**listinfo/erlang-questions +>> +>> > +>> +>> +>> +>> >> +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jan 3 22:52:46 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 03 Jan 2013 22:52:46 +0100 +Subject: [99s-extend] Call for testers: middleware support +Message-ID: <50E5FDAE.60904@ninenines.eu> + +Hello! + +Been a year. How' ya been? + +Added middleware support. Probably broke things. Please test and open +tickets if I did? + +https://github.com/extend/cowboy/commit/1b3f510b7e8d5413901ba72adfe361773f3e9097 + +Thanks. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From thomas at oinksoft.com Fri Jan 4 15:31:21 2013 +From: thomas at oinksoft.com (Thomas Allen) +Date: Fri, 04 Jan 2013 09:31:21 -0500 +Subject: [99s-extend] Call for testers: middleware support +In-Reply-To: <50E5FDAE.60904@ninenines.eu> +References: <50E5FDAE.60904@ninenines.eu> +Message-ID: <50E6E7B9.70402@oinksoft.com> + +Thank you L?ic, this looks much cleaner than what I've used in its place. + +Thomas + + +On 01/03/2013 04:52 PM, Lo?c Hoguin wrote: +> Hello! +> +> Been a year. How' ya been? +> +> Added middleware support. Probably broke things. Please test and open +> tickets if I did? +> +> https://github.com/extend/cowboy/commit/1b3f510b7e8d5413901ba72adfe361773f3e9097 +> +> +> Thanks. +> + + +From kozlov-ter at yandex.ru Tue Jan 8 22:36:56 2013 +From: kozlov-ter at yandex.ru (=?koi8-r?B?68/azM/XIPfR3sXTzMHX?=) +Date: Wed, 09 Jan 2013 01:36:56 +0400 +Subject: [99s-extend] Cowboy, how call my database select function +Message-ID: <1816031357681016@web3d.yandex.ru> + +Hello! +Prompt please, beginning to study the Erlang. +I have a library for working with ?Redis. +Plugged it into the project Cowboy with the help of Rebar. +After the launch of a Cowboy through the script in the console ERL, I see that the function (eredis_db:get_script) is works and I get the desired result: + +EDB R15B03 (erts-5.9.3.1) [source] [async-threads:0] [hipe] [kernel-poll:false] +Eshell V5.9.3.1 (abort with ^G) +1> eredis_db:get_script("example", "test"). + +Tell me how can I use this function in a Cowboy, in hendlers. +I hope I could explain clearly. +-- +Engineer CAM +Vyacheslav Kozlov +LLC "TER" +http://www.ter-energo.ru +tel.+7910909xxxx + + +From thomas at oinksoft.com Wed Jan 9 00:12:02 2013 +From: thomas at oinksoft.com (Thomas Allen) +Date: Tue, 08 Jan 2013 18:12:02 -0500 +Subject: [99s-extend] Cowboy, how call my database select function +In-Reply-To: <1816031357681016@web3d.yandex.ru> +References: <1816031357681016@web3d.yandex.ru> +Message-ID: <50ECA7C2.5030808@oinksoft.com> + +On 1/8/13 4:36 PM, ?????? ???????? wrote: +> I hope I could explain clearly. + +This was not quite clear to me, but I'll do my best. + +> Tell me how can I use this function in a Cowboy, in hendlers. + +Well, you'd use it like any other Erlang function. If it's in a handler, +you probably want to use init/3 or handle/2: + +handle(Req, State) -> + _EredisScript = eredis_db:get_script("example", "test"), + {ok, Resp} = cowboy_req:reply(200, Req), + {ok, Resp, State}. + +See other examples of implementing `cowboy_http_handler' behaviour in +the Cowboy documentation and in the examples included with the library. + +Thomas Allen + + +From essen at ninenines.eu Thu Jan 17 19:33:26 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 17 Jan 2013 19:33:26 +0100 +Subject: [99s-extend] [ANN] Ranch 0.6.1 +Message-ID: <50F843F6.5060809@ninenines.eu> + +Short, quick and semi-private announcement: Ranch 0.6.1 has been tagged. + +It includes a few guide updates, the addition of the raw option for +specifying platform-specific socket options, and performance +improvements when using the {max_connections, infinity} option. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From jeremy at quarkgames.com Thu Jan 17 20:42:38 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Thu, 17 Jan 2013 11:42:38 -0800 +Subject: [99s-extend] [ANN] Ranch 0.6.1 +In-Reply-To: <50F843F6.5060809@ninenines.eu> +References: <50F843F6.5060809@ninenines.eu> +Message-ID: + +Thanks Lo?c! + + +On Thu, Jan 17, 2013 at 10:33 AM, Lo?c Hoguin wrote: + +> Short, quick and semi-private announcement: Ranch 0.6.1 has been tagged. +> +> It includes a few guide updates, the addition of the raw option for +> specifying platform-specific socket options, and performance improvements +> when using the {max_connections, infinity} option. +> +> Enjoy! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/**listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jan 24 22:23:31 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 24 Jan 2013 22:23:31 +0100 +Subject: [99s-extend] Cowboy feedback needed +Message-ID: <5101A653.400@ninenines.eu> + +Hey, + +I'm looking into perhaps starting a project related to Cowboy and could +use some feedback from users, particularly in the realm of numbers. + +If you use Cowboy and have it in production where: + + * Latency is vital + * Throughput is vital + * Concurrent number of connections is huge + * Load is huge (or would be with another solution) + +Then I'd like to hear from you! + +Please send me average numbers, statistics, graphs or anything where I +can see how well it performs for you! In private if you prefer. Tell me +if I can quote you or your company about it. Please answer even if we +briefly discussed it in the past. + +(If you found that it didn't perform enough for your needs you should +probably open a ticket, or, if you can't, send me a private email.) + +Looking forward to the feedback. Thanks! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From list1 at gjunka.com Thu Jan 24 23:41:30 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Thu, 24 Jan 2013 22:41:30 +0000 +Subject: [99s-extend] Cowboy Makefile +Message-ID: <5101B89A.50604@gjunka.com> + +Hi, +I understand the move away from Rebar but I'd like to see the project to +be still Rebar-compatible. Would that be a problem? Mainly I am thinking +about dependencies. The Cowboy Makefile assumes that Ranch is in its +deps folder. If Cowboy is a part of a bigger application, and most often +it will be in such a role rather than a standalone application, then all +dependencies should be kept in one place. In that case it would be the +main project's deps folder, not Cowboy's deps folder. Can the +compilation process be split into compiling Cowboy dependencies +separately from Cowboy itself? + +something like: + +all: compile-deps compile-cowboy + +Then if Cowboy is a dependency itself it may be just compiled without +the dependency (as it will be compiled when the main project is compiled). + + + +From barcojie at gmail.com Fri Jan 25 06:53:17 2013 +From: barcojie at gmail.com (Barco You) +Date: Fri, 25 Jan 2013 13:53:17 +0800 +Subject: [99s-extend] [erlang-questions] Cowboy feedback needed +In-Reply-To: <5101A653.400@ninenines.eu> +References: <5101A653.400@ninenines.eu> +Message-ID: + +Hi Loic, + +I'd like to send feedback very much. But right now Cowboy is just used as +demo in my company --- BesTV (www.bestv.com.cn), which is the largest IPTV +and intenetTV operator in China. Although I think Cowby is good, the +production environment is still dominated by Java and mainstream HTTP +servers. Because I'm from Ericsson, I hope to promote Erlang here but it's +not so easy. I would send the data if Cowboy would be used in production +and fully tested. + +Thank you! +Barco + +On Fri, Jan 25, 2013 at 5:23 AM, Lo?c Hoguin wrote: + +> Hey, +> +> I'm looking into perhaps starting a project related to Cowboy and could +> use some feedback from users, particularly in the realm of numbers. +> +> If you use Cowboy and have it in production where: +> +> * Latency is vital +> * Throughput is vital +> * Concurrent number of connections is huge +> * Load is huge (or would be with another solution) +> +> Then I'd like to hear from you! +> +> Please send me average numbers, statistics, graphs or anything where I can +> see how well it performs for you! In private if you prefer. Tell me if I +> can quote you or your company about it. Please answer even if we briefly +> discussed it in the past. +> +> (If you found that it didn't perform enough for your needs you should +> probably open a ticket, or, if you can't, send me a private email.) +> +> Looking forward to the feedback. Thanks! +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/**listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mjtruog at gmail.com Fri Jan 25 07:26:27 2013 +From: mjtruog at gmail.com (Michael Truog) +Date: Thu, 24 Jan 2013 22:26:27 -0800 +Subject: [99s-extend] [erlang-questions] Cowboy feedback needed +In-Reply-To: <5101A653.400@ninenines.eu> +References: <5101A653.400@ninenines.eu> +Message-ID: <51022593.7090306@gmail.com> + +A comparison (summary) of cowboy 0.6.1 and misultin 0.9 final in the context of CloudI is here: +https://github.com/okeuday/CloudI/blob/master/src/tests/http_req/loadtest/results_v1_1_0/201210_summary.pdf +(the raw Tsung results are also within the same directory) + +The results are just showing the latency when putting cowboy and misultin under 10kreq/s load with both 20k and 40k connections, when the requests go through CloudI messaging into all the supported programming languages (Erlang, C/C++, pure-Java, Python/C, pure-Python, and pure-Ruby.... the "pure" part is where only the target language is used to create the CloudI API, which does the Erlang binary term format CloudI request encoding/decoding). So, the test is showing the performance of a simple HTTP GET query parameter parse/response using XML (the XML is based on historical misultin testing). + +For these tests, it showed cowboy always has less latency which is significant, if the programming language internal latency is not significant. The cpu usage of cowboy was slightly lower than misultin for high connection counts (40k instead of 20k). The memory usage of cowboy was significantly lower than misultin. The test results are for R15B01 and R15B02, just due to when I did the loadtesting. + +I will continue to do similar loadtests in the future to make sure and evaluate performance with more recent Erlang releases, as time allows, but the Tsung configurations are within the repository for people to test their own (hardware) environments. + +On 01/24/2013 01:23 PM, Lo?c Hoguin wrote: +> Hey, +> +> I'm looking into perhaps starting a project related to Cowboy and could use some feedback from users, particularly in the realm of numbers. +> +> If you use Cowboy and have it in production where: +> +> * Latency is vital +> * Throughput is vital +> * Concurrent number of connections is huge +> * Load is huge (or would be with another solution) +> +> Then I'd like to hear from you! +> +> Please send me average numbers, statistics, graphs or anything where I can see how well it performs for you! In private if you prefer. Tell me if I can quote you or your company about it. Please answer even if we briefly discussed it in the past. +> +> (If you found that it didn't perform enough for your needs you should probably open a ticket, or, if you can't, send me a private email.) +> +> Looking forward to the feedback. Thanks! +> + + + diff --git a/_build/static/archives/extend/2013-January/000028.html b/_build/static/archives/extend/2013-January/000028.html new file mode 100644 index 00000000..8205944b --- /dev/null +++ b/_build/static/archives/extend/2013-January/000028.html @@ -0,0 +1,133 @@ + + + + [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Max Lapshin + max.lapshin at gmail.com +
+ Thu Jan 3 10:30:30 CET 2013 +

+
+ +
Loic, it would be great to hear a bit, what problems have you met with.
+
+What issues with stability can be in acceptor pool?
+
+Also I have question about updating protocol options: have you done
+something with the problem that after updating protocol options existing
+workers are running with old config?
+
+On Tuesday, December 25, 2012, Loïc Hoguin wrote:
+
+> Ho ho ho!
+>
+> I have just tagged version 0.6.0 of the Ranch project!
+>
+> Ranch is a socket acceptor pool for TCP protocols.
+>
+>   https://github.com/extend/**ranch <https://github.com/extend/ranch>
+>
+> Ranch is used by the next version of Cowboy, 0.8.0, set to be released
+> early February, but also in Basho's Riak multi-data center replication
+> amongst others.
+>
+> All tickets have been resolved. A significant contribution was made by
+> Andrew Majorov to improve the fault tolerance capabilities of the
+> application, making sure it always restarts properly when things go wrong.
+> This has been made possible thanks to the amazing project from Daniel Luna,
+> chaos_monkey (https://github.com/dluna/**chaos_monkey<https://github.com/dluna/chaos_monkey>
+> ).
+>
+> The guide has also been improved and completed.
+>
+>   http://ninenines.eu/docs/en/**ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction>
+>
+> If the guide isn't enough, drop by our new IRC channel dedicated to
+> Cowboy, Ranch and all our other projects! #ninenines on Freenode.
+>
+> Following is the list of change since last time:
+>
+>  *  Improve fault tolerance thanks to chaos_monkey testing
+>  *  Add 'nodelay' option to transports
+>  *  Add 'verify' option to ranch_ssl transport
+>  *  Add 'socket' option to pass an already open socket to the listener
+>  *  Add Transport:sendfile/2 function (uses a fallback if unavailable)
+>  *  Allow IP tuples in Transport:connect/3
+>  *  Add ranch:set_max_connections/2 to update the value live
+>  *  Add ranch:get_max_connections/1 to retrieve it
+>
+> We are always looking for feedback, especially now that there is no ticket
+> left open on this project. If you are using Ranch and have questions or
+> needs that it doesn't cover, please send them to us.
+>
+> Commercial support will be available starting from January, ping me if you
+> are interested. Details will be announced at a later time on the
+> ninenines.eu mailing list.
+>
+> I want to thank all contributors for helping this project by opening
+> tickets, sending patches and offering feedback. I am as always very
+> grateful for any and all contributions. I wouldn't have made it this far
+> without the tremendous help I receive everyday.
+>
+> Thanks to all and have a nice holiday!
+>
+> --
+> Loïc Hoguin
+> Erlang Santa
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130103/bae06e70/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000029.html b/_build/static/archives/extend/2013-January/000029.html new file mode 100644 index 00000000..8f69dfb4 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000029.html @@ -0,0 +1,154 @@ + + + + [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 3 13:46:56 CET 2013 +

+
+ +
Haven't had any stability issue. What we did here is ensure that when 
+any process gets killed for any reason, especially reasons we can't 
+foresee, Ranch continues to work as expected.
+
+Ranch not updating protocol options for existing connections isn't a 
+problem, it won't be "fixed". Ranch can't guess how connection processes 
+are implemented. It's up to you to allow this if you need it. The 
+upgrade updates the options for all acceptors and all future 
+connections, that's it.
+
+On 01/03/2013 10:30 AM, Max Lapshin wrote:
+> Loic, it would be great to hear a bit, what problems have you met with.
+>
+> What issues with stability can be in acceptor pool?
+>
+> Also I have question about updating protocol options: have you done
+> something with the problem that after updating protocol options existing
+> workers are running with old config?
+>
+> On Tuesday, December 25, 2012, Loïc Hoguin wrote:
+>
+>     Ho ho ho!
+>
+>     I have just tagged version 0.6.0 of the Ranch project!
+>
+>     Ranch is a socket acceptor pool for TCP protocols.
+>
+>     https://github.com/extend/__ranch <https://github.com/extend/ranch>
+>
+>     Ranch is used by the next version of Cowboy, 0.8.0, set to be
+>     released early February, but also in Basho's Riak multi-data center
+>     replication amongst others.
+>
+>     All tickets have been resolved. A significant contribution was made
+>     by Andrew Majorov to improve the fault tolerance capabilities of the
+>     application, making sure it always restarts properly when things go
+>     wrong. This has been made possible thanks to the amazing project
+>     from Daniel Luna, chaos_monkey
+>     (https://github.com/dluna/__chaos_monkey
+>     <https://github.com/dluna/chaos_monkey>).
+>
+>     The guide has also been improved and completed.
+>
+>     http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction
+>     <http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction>
+>
+>     If the guide isn't enough, drop by our new IRC channel dedicated to
+>     Cowboy, Ranch and all our other projects! #ninenines on Freenode.
+>
+>     Following is the list of change since last time:
+>
+>       *  Improve fault tolerance thanks to chaos_monkey testing
+>       *  Add 'nodelay' option to transports
+>       *  Add 'verify' option to ranch_ssl transport
+>       *  Add 'socket' option to pass an already open socket to the listener
+>       *  Add Transport:sendfile/2 function (uses a fallback if unavailable)
+>       *  Allow IP tuples in Transport:connect/3
+>       *  Add ranch:set_max_connections/2 to update the value live
+>       *  Add ranch:get_max_connections/1 to retrieve it
+>
+>     We are always looking for feedback, especially now that there is no
+>     ticket left open on this project. If you are using Ranch and have
+>     questions or needs that it doesn't cover, please send them to us.
+>
+>     Commercial support will be available starting from January, ping me
+>     if you are interested. Details will be announced at a later time on
+>     the ninenines.eu <http://ninenines.eu> mailing list.
+>
+>     I want to thank all contributors for helping this project by opening
+>     tickets, sending patches and offering feedback. I am as always very
+>     grateful for any and all contributions. I wouldn't have made it this
+>     far without the tremendous help I receive everyday.
+>
+>     Thanks to all and have a nice holiday!
+>
+>     --
+>     Loïc Hoguin
+>     Erlang Santa
+>     Nine Nines
+>     http://ninenines.eu
+>     _________________________________________________
+>     erlang-questions mailing list
+>     erlang-questions at erlang.org
+>     http://erlang.org/mailman/__listinfo/erlang-questions
+>     <http://erlang.org/mailman/listinfo/erlang-questions>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000030.html b/_build/static/archives/extend/2013-January/000030.html new file mode 100644 index 00000000..c75a7032 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000030.html @@ -0,0 +1,175 @@ + + + + [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Max Lapshin + max.lapshin at gmail.com +
+ Thu Jan 3 14:32:16 CET 2013 +

+
+ +
I mean situation that after cowboy:update_options existing acceptors are
+still working with old routes.
+Currently it is useless API, so I have to stop cowboy and start it back.
+
+
+On Thu, Jan 3, 2013 at 4:46 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Haven't had any stability issue. What we did here is ensure that when any
+> process gets killed for any reason, especially reasons we can't foresee,
+> Ranch continues to work as expected.
+>
+> Ranch not updating protocol options for existing connections isn't a
+> problem, it won't be "fixed". Ranch can't guess how connection processes
+> are implemented. It's up to you to allow this if you need it. The upgrade
+> updates the options for all acceptors and all future connections, that's it.
+>
+>
+> On 01/03/2013 10:30 AM, Max Lapshin wrote:
+>
+>> Loic, it would be great to hear a bit, what problems have you met with.
+>>
+>> What issues with stability can be in acceptor pool?
+>>
+>> Also I have question about updating protocol options: have you done
+>> something with the problem that after updating protocol options existing
+>> workers are running with old config?
+>>
+>> On Tuesday, December 25, 2012, Loïc Hoguin wrote:
+>>
+>>     Ho ho ho!
+>>
+>>     I have just tagged version 0.6.0 of the Ranch project!
+>>
+>>     Ranch is a socket acceptor pool for TCP protocols.
+>>
+>>     https://github.com/extend/__**ranch<https://github.com/extend/__ranch><
+>> https://github.com/extend/**ranch <https://github.com/extend/ranch>>
+>>
+>>
+>>     Ranch is used by the next version of Cowboy, 0.8.0, set to be
+>>     released early February, but also in Basho's Riak multi-data center
+>>     replication amongst others.
+>>
+>>     All tickets have been resolved. A significant contribution was made
+>>     by Andrew Majorov to improve the fault tolerance capabilities of the
+>>     application, making sure it always restarts properly when things go
+>>     wrong. This has been made possible thanks to the amazing project
+>>     from Daniel Luna, chaos_monkey
+>>     (https://github.com/dluna/__**chaos_monkey<https://github.com/dluna/__chaos_monkey>
+>>     <https://github.com/dluna/**chaos_monkey<https://github.com/dluna/chaos_monkey>
+>> >).
+>>
+>>
+>>     The guide has also been improved and completed.
+>>
+>>     http://ninenines.eu/docs/en/__**ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction>
+>>
+>>     <http://ninenines.eu/docs/en/**ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction>
+>> >
+>>
+>>     If the guide isn't enough, drop by our new IRC channel dedicated to
+>>     Cowboy, Ranch and all our other projects! #ninenines on Freenode.
+>>
+>>     Following is the list of change since last time:
+>>
+>>       *  Improve fault tolerance thanks to chaos_monkey testing
+>>       *  Add 'nodelay' option to transports
+>>       *  Add 'verify' option to ranch_ssl transport
+>>       *  Add 'socket' option to pass an already open socket to the
+>> listener
+>>       *  Add Transport:sendfile/2 function (uses a fallback if
+>> unavailable)
+>>       *  Allow IP tuples in Transport:connect/3
+>>       *  Add ranch:set_max_connections/2 to update the value live
+>>       *  Add ranch:get_max_connections/1 to retrieve it
+>>
+>>     We are always looking for feedback, especially now that there is no
+>>     ticket left open on this project. If you are using Ranch and have
+>>     questions or needs that it doesn't cover, please send them to us.
+>>
+>>     Commercial support will be available starting from January, ping me
+>>     if you are interested. Details will be announced at a later time on
+>>     the ninenines.eu <http://ninenines.eu> mailing list.
+>>
+>>
+>>     I want to thank all contributors for helping this project by opening
+>>     tickets, sending patches and offering feedback. I am as always very
+>>     grateful for any and all contributions. I wouldn't have made it this
+>>     far without the tremendous help I receive everyday.
+>>
+>>     Thanks to all and have a nice holiday!
+>>
+>>     --
+>>     Loïc Hoguin
+>>     Erlang Santa
+>>     Nine Nines
+>>     http://ninenines.eu
+>>     ______________________________**___________________
+>>     erlang-questions mailing list
+>>     erlang-questions at erlang.org
+>>     http://erlang.org/mailman/__**listinfo/erlang-questions<http://erlang.org/mailman/__listinfo/erlang-questions>
+>>     <http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>> >
+>>
+>>
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130103/f6c7fd25/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000031.html b/_build/static/archives/extend/2013-January/000031.html new file mode 100644 index 00000000..e62e78e1 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000031.html @@ -0,0 +1,212 @@ + + + + [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 3 14:51:48 CET 2013 +

+
+ +
Existing acceptors were using the old options for the next connection 
+and then switched to the new options. But that has been fixed a long 
+time ago. Ranch doesn't have that issue.
+
+On 01/03/2013 02:32 PM, Max Lapshin wrote:
+> I mean situation that after cowboy:update_options existing acceptors are
+> still working with old routes.
+> Currently it is useless API, so I have to stop cowboy and start it back.
+>
+>
+> On Thu, Jan 3, 2013 at 4:46 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Haven't had any stability issue. What we did here is ensure that
+>     when any process gets killed for any reason, especially reasons we
+>     can't foresee, Ranch continues to work as expected.
+>
+>     Ranch not updating protocol options for existing connections isn't a
+>     problem, it won't be "fixed". Ranch can't guess how connection
+>     processes are implemented. It's up to you to allow this if you need
+>     it. The upgrade updates the options for all acceptors and all future
+>     connections, that's it.
+>
+>
+>     On 01/03/2013 10:30 AM, Max Lapshin wrote:
+>
+>         Loic, it would be great to hear a bit, what problems have you
+>         met with.
+>
+>         What issues with stability can be in acceptor pool?
+>
+>         Also I have question about updating protocol options: have you done
+>         something with the problem that after updating protocol options
+>         existing
+>         workers are running with old config?
+>
+>         On Tuesday, December 25, 2012, Loïc Hoguin wrote:
+>
+>              Ho ho ho!
+>
+>              I have just tagged version 0.6.0 of the Ranch project!
+>
+>              Ranch is a socket acceptor pool for TCP protocols.
+>
+>         https://github.com/extend/____ranch
+>         <https://github.com/extend/__ranch>
+>         <https://github.com/extend/__ranch
+>         <https://github.com/extend/ranch>>
+>
+>
+>              Ranch is used by the next version of Cowboy, 0.8.0, set to be
+>              released early February, but also in Basho's Riak
+>         multi-data center
+>              replication amongst others.
+>
+>              All tickets have been resolved. A significant contribution
+>         was made
+>              by Andrew Majorov to improve the fault tolerance
+>         capabilities of the
+>              application, making sure it always restarts properly when
+>         things go
+>              wrong. This has been made possible thanks to the amazing
+>         project
+>              from Daniel Luna, chaos_monkey
+>              (https://github.com/dluna/____chaos_monkey
+>         <https://github.com/dluna/__chaos_monkey>
+>              <https://github.com/dluna/__chaos_monkey
+>         <https://github.com/dluna/chaos_monkey>>).
+>
+>
+>              The guide has also been improved and completed.
+>
+>         http://ninenines.eu/docs/en/____ranch/HEAD/guide/introduction
+>         <http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction>
+>
+>
+>         <http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction
+>         <http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction>>
+>
+>              If the guide isn't enough, drop by our new IRC channel
+>         dedicated to
+>              Cowboy, Ranch and all our other projects! #ninenines on
+>         Freenode.
+>
+>              Following is the list of change since last time:
+>
+>                *  Improve fault tolerance thanks to chaos_monkey testing
+>                *  Add 'nodelay' option to transports
+>                *  Add 'verify' option to ranch_ssl transport
+>                *  Add 'socket' option to pass an already open socket to
+>         the listener
+>                *  Add Transport:sendfile/2 function (uses a fallback if
+>         unavailable)
+>                *  Allow IP tuples in Transport:connect/3
+>                *  Add ranch:set_max_connections/2 to update the value live
+>                *  Add ranch:get_max_connections/1 to retrieve it
+>
+>              We are always looking for feedback, especially now that
+>         there is no
+>              ticket left open on this project. If you are using Ranch
+>         and have
+>              questions or needs that it doesn't cover, please send them
+>         to us.
+>
+>              Commercial support will be available starting from January,
+>         ping me
+>              if you are interested. Details will be announced at a later
+>         time on
+>              the ninenines.eu <http://ninenines.eu>
+>         <http://ninenines.eu> mailing list.
+>
+>
+>              I want to thank all contributors for helping this project
+>         by opening
+>              tickets, sending patches and offering feedback. I am as
+>         always very
+>              grateful for any and all contributions. I wouldn't have
+>         made it this
+>              far without the tremendous help I receive everyday.
+>
+>              Thanks to all and have a nice holiday!
+>
+>              --
+>              Loïc Hoguin
+>              Erlang Santa
+>              Nine Nines
+>         http://ninenines.eu
+>              ___________________________________________________
+>              erlang-questions mailing list
+>         erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>         http://erlang.org/mailman/____listinfo/erlang-questions
+>         <http://erlang.org/mailman/__listinfo/erlang-questions>
+>              <http://erlang.org/mailman/__listinfo/erlang-questions
+>         <http://erlang.org/mailman/listinfo/erlang-questions>>
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000032.html b/_build/static/archives/extend/2013-January/000032.html new file mode 100644 index 00000000..814279e3 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000032.html @@ -0,0 +1,236 @@ + + + + [99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Ranch 0.6.0 Xmas Edition Released

+ Max Lapshin + max.lapshin at gmail.com +
+ Thu Jan 3 15:00:56 CET 2013 +

+
+ +
ok
+
+
+On Thu, Jan 3, 2013 at 5:51 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Existing acceptors were using the old options for the next connection and
+> then switched to the new options. But that has been fixed a long time ago.
+> Ranch doesn't have that issue.
+>
+>
+> On 01/03/2013 02:32 PM, Max Lapshin wrote:
+>
+>> I mean situation that after cowboy:update_options existing acceptors are
+>> still working with old routes.
+>> Currently it is useless API, so I have to stop cowboy and start it back.
+>>
+>>
+>> On Thu, Jan 3, 2013 at 4:46 PM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     Haven't had any stability issue. What we did here is ensure that
+>>     when any process gets killed for any reason, especially reasons we
+>>     can't foresee, Ranch continues to work as expected.
+>>
+>>     Ranch not updating protocol options for existing connections isn't a
+>>     problem, it won't be "fixed". Ranch can't guess how connection
+>>     processes are implemented. It's up to you to allow this if you need
+>>     it. The upgrade updates the options for all acceptors and all future
+>>     connections, that's it.
+>>
+>>
+>>     On 01/03/2013 10:30 AM, Max Lapshin wrote:
+>>
+>>         Loic, it would be great to hear a bit, what problems have you
+>>         met with.
+>>
+>>         What issues with stability can be in acceptor pool?
+>>
+>>         Also I have question about updating protocol options: have you
+>> done
+>>         something with the problem that after updating protocol options
+>>         existing
+>>         workers are running with old config?
+>>
+>>         On Tuesday, December 25, 2012, Loïc Hoguin wrote:
+>>
+>>              Ho ho ho!
+>>
+>>              I have just tagged version 0.6.0 of the Ranch project!
+>>
+>>              Ranch is a socket acceptor pool for TCP protocols.
+>>
+>>         https://github.com/extend/____**ranch<https://github.com/extend/____ranch>
+>>         <https://github.com/extend/__**ranch<https://github.com/extend/__ranch>
+>> >
+>>
+>>         <https://github.com/extend/__**ranch<https://github.com/extend/__ranch>
+>>         <https://github.com/extend/**ranch<https://github.com/extend/ranch>
+>> >>
+>>
+>>
+>>              Ranch is used by the next version of Cowboy, 0.8.0, set to be
+>>              released early February, but also in Basho's Riak
+>>         multi-data center
+>>              replication amongst others.
+>>
+>>              All tickets have been resolved. A significant contribution
+>>         was made
+>>              by Andrew Majorov to improve the fault tolerance
+>>         capabilities of the
+>>              application, making sure it always restarts properly when
+>>         things go
+>>              wrong. This has been made possible thanks to the amazing
+>>         project
+>>              from Daniel Luna, chaos_monkey
+>>              (https://github.com/dluna/____**chaos_monkey<https://github.com/dluna/____chaos_monkey>
+>>         <https://github.com/dluna/__**chaos_monkey<https://github.com/dluna/__chaos_monkey>
+>> >
+>>
+>>              <https://github.com/dluna/__**chaos_monkey<https://github.com/dluna/__chaos_monkey>
+>>         <https://github.com/dluna/**chaos_monkey<https://github.com/dluna/chaos_monkey>
+>> >>).
+>>
+>>
+>>              The guide has also been improved and completed.
+>>
+>>         http://ninenines.eu/docs/en/__**__ranch/HEAD/guide/**introduction<http://ninenines.eu/docs/en/____ranch/HEAD/guide/introduction>
+>>         <http://ninenines.eu/docs/en/_**_ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction>
+>> **>
+>>
+>>
+>>
+>>         <http://ninenines.eu/docs/en/_**_ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction>
+>>         <http://ninenines.eu/docs/en/**ranch/HEAD/guide/introduction<http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction>
+>> >**>
+>>
+>>              If the guide isn't enough, drop by our new IRC channel
+>>         dedicated to
+>>              Cowboy, Ranch and all our other projects! #ninenines on
+>>         Freenode.
+>>
+>>              Following is the list of change since last time:
+>>
+>>                *  Improve fault tolerance thanks to chaos_monkey testing
+>>                *  Add 'nodelay' option to transports
+>>                *  Add 'verify' option to ranch_ssl transport
+>>                *  Add 'socket' option to pass an already open socket to
+>>         the listener
+>>                *  Add Transport:sendfile/2 function (uses a fallback if
+>>         unavailable)
+>>                *  Allow IP tuples in Transport:connect/3
+>>                *  Add ranch:set_max_connections/2 to update the value live
+>>                *  Add ranch:get_max_connections/1 to retrieve it
+>>
+>>              We are always looking for feedback, especially now that
+>>         there is no
+>>              ticket left open on this project. If you are using Ranch
+>>         and have
+>>              questions or needs that it doesn't cover, please send them
+>>         to us.
+>>
+>>              Commercial support will be available starting from January,
+>>         ping me
+>>              if you are interested. Details will be announced at a later
+>>         time on
+>>              the ninenines.eu <http://ninenines.eu>
+>>         <http://ninenines.eu> mailing list.
+>>
+>>
+>>              I want to thank all contributors for helping this project
+>>         by opening
+>>              tickets, sending patches and offering feedback. I am as
+>>         always very
+>>              grateful for any and all contributions. I wouldn't have
+>>         made it this
+>>              far without the tremendous help I receive everyday.
+>>
+>>              Thanks to all and have a nice holiday!
+>>
+>>              --
+>>              Loïc Hoguin
+>>              Erlang Santa
+>>              Nine Nines
+>>         http://ninenines.eu
+>>              ______________________________**_____________________
+>>              erlang-questions mailing list
+>>         erlang-questions at erlang.org <mailto:erlang-questions@**erlang.org<erlang-questions at erlang.org>
+>> >
+>>         http://erlang.org/mailman/____**listinfo/erlang-questions<http://erlang.org/mailman/____listinfo/erlang-questions>
+>>         <http://erlang.org/mailman/__**listinfo/erlang-questions<http://erlang.org/mailman/__listinfo/erlang-questions>
+>> >
+>>
+>>              <http://erlang.org/mailman/__**listinfo/erlang-questions<http://erlang.org/mailman/__listinfo/erlang-questions>
+>>         <http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>> >>
+>>
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>
+>>
+>>
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130103/d9dbc1a5/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000033.html b/_build/static/archives/extend/2013-January/000033.html new file mode 100644 index 00000000..2967e683 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000033.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Call for testers: middleware support + + + + + + + + + + +

[99s-extend] Call for testers: middleware support

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 3 22:52:46 CET 2013 +

+
+ +
Hello!
+
+Been a year. How' ya been?
+
+Added middleware support. Probably broke things. Please test and open 
+tickets if I did?
+
+https://github.com/extend/cowboy/commit/1b3f510b7e8d5413901ba72adfe361773f3e9097
+
+Thanks.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000034.html b/_build/static/archives/extend/2013-January/000034.html new file mode 100644 index 00000000..058aedb0 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000034.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Call for testers: middleware support + + + + + + + + + + +

[99s-extend] Call for testers: middleware support

+ Thomas Allen + thomas at oinksoft.com +
+ Fri Jan 4 15:31:21 CET 2013 +

+
+ +
Thank you Löic, this looks much cleaner than what I've used in its place.
+
+Thomas
+
+
+On 01/03/2013 04:52 PM, Loïc Hoguin wrote:
+> Hello!
+>
+> Been a year. How' ya been?
+>
+> Added middleware support. Probably broke things. Please test and open
+> tickets if I did?
+>
+> https://github.com/extend/cowboy/commit/1b3f510b7e8d5413901ba72adfe361773f3e9097
+>
+>
+> Thanks.
+>
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000035.html b/_build/static/archives/extend/2013-January/000035.html new file mode 100644 index 00000000..0bc878fc --- /dev/null +++ b/_build/static/archives/extend/2013-January/000035.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Cowboy, how call my database select function + + + + + + + + + + +

[99s-extend] Cowboy, how call my database select function

+ Козлов Вячеслав + kozlov-ter at yandex.ru +
+ Tue Jan 8 22:36:56 CET 2013 +

+
+ +
Hello!
+Prompt please, beginning to study the Erlang.
+I have a library for working with ЕRedis.
+Plugged it into the project Cowboy with the help of Rebar.
+After the launch of a Cowboy through the script in the console ERL, I see that the function (eredis_db:get_script) is  works and I get the desired result:
+
+EDB R15B03 (erts-5.9.3.1) [source] [async-threads:0] [hipe] [kernel-poll:false]
+Eshell V5.9.3.1 (abort with ^G)
+1> eredis_db:get_script("example", "test").
+
+Tell me how can I use this function in a Cowboy, in hendlers.
+I hope I could explain clearly.
+-- 
+Engineer CAM 
+Vyacheslav Kozlov 
+LLC "TER" 
+http://www.ter-energo.ru
+tel.+7910909xxxx
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000036.html b/_build/static/archives/extend/2013-January/000036.html new file mode 100644 index 00000000..4a9db14c --- /dev/null +++ b/_build/static/archives/extend/2013-January/000036.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Cowboy, how call my database select function + + + + + + + + + + +

[99s-extend] Cowboy, how call my database select function

+ Thomas Allen + thomas at oinksoft.com +
+ Wed Jan 9 00:12:02 CET 2013 +

+
+ +
On 1/8/13 4:36 PM, Козлов Вячеслав wrote:
+> I hope I could explain clearly.
+
+This was not quite clear to me, but I'll do my best.
+
+> Tell me how can I use this function in a Cowboy, in hendlers.
+
+Well, you'd use it like any other Erlang function. If it's in a handler, 
+you probably want to use init/3 or handle/2:
+
+handle(Req, State) ->
+     _EredisScript = eredis_db:get_script("example", "test"),
+     {ok, Resp} = cowboy_req:reply(200, Req),
+     {ok, Resp, State}.
+
+See other examples of implementing `cowboy_http_handler' behaviour in 
+the Cowboy documentation and in the examples included with the library.
+
+Thomas Allen
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000037.html b/_build/static/archives/extend/2013-January/000037.html new file mode 100644 index 00000000..098c5631 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000037.html @@ -0,0 +1,74 @@ + + + + [99s-extend] [ANN] Ranch 0.6.1 + + + + + + + + + + +

[99s-extend] [ANN] Ranch 0.6.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 17 19:33:26 CET 2013 +

+
+ +
Short, quick and semi-private announcement: Ranch 0.6.1 has been tagged.
+
+It includes a few guide updates, the addition of the raw option for 
+specifying platform-specific socket options, and performance 
+improvements when using the {max_connections, infinity} option.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000038.html b/_build/static/archives/extend/2013-January/000038.html new file mode 100644 index 00000000..64343529 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000038.html @@ -0,0 +1,86 @@ + + + + [99s-extend] [ANN] Ranch 0.6.1 + + + + + + + + + + +

[99s-extend] [ANN] Ranch 0.6.1

+ Jeremy Ong + jeremy at quarkgames.com +
+ Thu Jan 17 20:42:38 CET 2013 +

+
+ +
Thanks Loïc!
+
+
+On Thu, Jan 17, 2013 at 10:33 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Short, quick and semi-private announcement: Ranch 0.6.1 has been tagged.
+>
+> It includes a few guide updates, the addition of the raw option for
+> specifying platform-specific socket options, and performance improvements
+> when using the {max_connections, infinity} option.
+>
+> Enjoy!
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130117/19bfde40/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000039.html b/_build/static/archives/extend/2013-January/000039.html new file mode 100644 index 00000000..adf15655 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000039.html @@ -0,0 +1,90 @@ + + + + [99s-extend] Cowboy feedback needed + + + + + + + + + + +

[99s-extend] Cowboy feedback needed

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 24 22:23:31 CET 2013 +

+
+ +
Hey,
+
+I'm looking into perhaps starting a project related to Cowboy and could 
+use some feedback from users, particularly in the realm of numbers.
+
+If you use Cowboy and have it in production where:
+
+  *  Latency is vital
+  *  Throughput is vital
+  *  Concurrent number of connections is huge
+  *  Load is huge (or would be with another solution)
+
+Then I'd like to hear from you!
+
+Please send me average numbers, statistics, graphs or anything where I 
+can see how well it performs for you! In private if you prefer. Tell me 
+if I can quote you or your company about it. Please answer even if we 
+briefly discussed it in the past.
+
+(If you found that it didn't perform enough for your needs you should 
+probably open a ticket, or, if you can't, send me a private email.)
+
+Looking forward to the feedback. Thanks!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000040.html b/_build/static/archives/extend/2013-January/000040.html new file mode 100644 index 00000000..81f5ad61 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000040.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Cowboy Makefile + + + + + + + + + + +

[99s-extend] Cowboy Makefile

+ Grzegorz Junka + list1 at gjunka.com +
+ Thu Jan 24 23:41:30 CET 2013 +

+
+ +
Hi,
+I understand the move away from Rebar but I'd like to see the project to 
+be still Rebar-compatible. Would that be a problem? Mainly I am thinking 
+about dependencies. The Cowboy Makefile assumes that Ranch is in its 
+deps folder. If Cowboy is a part of a bigger application, and most often 
+it will be in such a role rather than a standalone application, then all 
+dependencies should be kept in one place. In that case it would be the 
+main project's deps folder, not Cowboy's deps folder. Can the 
+compilation process be split into compiling Cowboy dependencies 
+separately from Cowboy itself?
+
+something like:
+
+all: compile-deps compile-cowboy
+
+Then if Cowboy is a dependency itself it may be just compiled without 
+the dependency (as it will be compiled when the main project is compiled).
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000041.html b/_build/static/archives/extend/2013-January/000041.html new file mode 100644 index 00000000..33df9c64 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000041.html @@ -0,0 +1,112 @@ + + + + [99s-extend] [erlang-questions] Cowboy feedback needed + + + + + + + + + + +

[99s-extend] [erlang-questions] Cowboy feedback needed

+ Barco You + barcojie at gmail.com +
+ Fri Jan 25 06:53:17 CET 2013 +

+
+ +
Hi Loic,
+
+I'd like to send feedback very much. But right now Cowboy is just used as
+demo in my company --- BesTV (www.bestv.com.cn), which is the largest IPTV
+and intenetTV operator in China. Although I think Cowby is good, the
+production environment is still dominated by Java and mainstream HTTP
+servers. Because I'm from Ericsson, I hope to promote Erlang here but it's
+not so easy. I would send the data if Cowboy would be used in production
+and fully tested.
+
+Thank you!
+Barco
+
+On Fri, Jan 25, 2013 at 5:23 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Hey,
+>
+> I'm looking into perhaps starting a project related to Cowboy and could
+> use some feedback from users, particularly in the realm of numbers.
+>
+> If you use Cowboy and have it in production where:
+>
+>  *  Latency is vital
+>  *  Throughput is vital
+>  *  Concurrent number of connections is huge
+>  *  Load is huge (or would be with another solution)
+>
+> Then I'd like to hear from you!
+>
+> Please send me average numbers, statistics, graphs or anything where I can
+> see how well it performs for you! In private if you prefer. Tell me if I
+> can quote you or your company about it. Please answer even if we briefly
+> discussed it in the past.
+>
+> (If you found that it didn't perform enough for your needs you should
+> probably open a ticket, or, if you can't, send me a private email.)
+>
+> Looking forward to the feedback. Thanks!
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130125/7d0820aa/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/000042.html b/_build/static/archives/extend/2013-January/000042.html new file mode 100644 index 00000000..c3394073 --- /dev/null +++ b/_build/static/archives/extend/2013-January/000042.html @@ -0,0 +1,92 @@ + + + + [99s-extend] [erlang-questions] Cowboy feedback needed + + + + + + + + + + +

[99s-extend] [erlang-questions] Cowboy feedback needed

+ Michael Truog + mjtruog at gmail.com +
+ Fri Jan 25 07:26:27 CET 2013 +

+
+ +
A comparison (summary) of cowboy 0.6.1 and misultin 0.9 final in the context of CloudI is here:
+https://github.com/okeuday/CloudI/blob/master/src/tests/http_req/loadtest/results_v1_1_0/201210_summary.pdf
+(the raw Tsung results are also within the same directory)
+
+The results are just showing the latency when putting cowboy and misultin under 10kreq/s load with both 20k and 40k connections, when the requests go through CloudI messaging into all the supported programming languages (Erlang, C/C++, pure-Java, Python/C, pure-Python, and pure-Ruby.... the "pure" part is where only the target language is used to create the CloudI API, which does the Erlang binary term format CloudI request encoding/decoding).  So, the test is showing the performance of a simple HTTP GET query parameter parse/response using XML (the XML is based on historical misultin testing).
+
+For these tests, it showed cowboy always has less latency which is significant, if the programming language internal latency is not significant.  The cpu usage of cowboy was slightly lower than misultin for high connection counts (40k instead of 20k).  The memory usage of cowboy was significantly lower than misultin.  The test results are for R15B01 and R15B02, just due to when I did the loadtesting.
+
+I will continue to do similar loadtests in the future to make sure and evaluate performance with more recent Erlang releases, as time allows, but the Tsung configurations are within the repository for people to test their own (hardware) environments.
+
+On 01/24/2013 01:23 PM, Loïc Hoguin wrote:
+> Hey,
+>
+> I'm looking into perhaps starting a project related to Cowboy and could use some feedback from users, particularly in the realm of numbers.
+>
+> If you use Cowboy and have it in production where:
+>
+>  *  Latency is vital
+>  *  Throughput is vital
+>  *  Concurrent number of connections is huge
+>  *  Load is huge (or would be with another solution)
+>
+> Then I'd like to hear from you!
+>
+> Please send me average numbers, statistics, graphs or anything where I can see how well it performs for you! In private if you prefer. Tell me if I can quote you or your company about it. Please answer even if we briefly discussed it in the past.
+>
+> (If you found that it didn't perform enough for your needs you should probably open a ticket, or, if you can't, send me a private email.)
+>
+> Looking forward to the feedback. Thanks!
+>
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-January/author.html b/_build/static/archives/extend/2013-January/author.html new file mode 100644 index 00000000..abc837cb --- /dev/null +++ b/_build/static/archives/extend/2013-January/author.html @@ -0,0 +1,122 @@ + + + + The Extend January 2013 Archive by author + + + + + +

January 2013 Archives by author

+ +

Starting: Thu Jan 3 10:30:30 CET 2013
+ Ending: Fri Jan 25 07:26:27 CET 2013
+ Messages: 15

+

+

+ Last message date: + Fri Jan 25 07:26:27 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-January/date.html b/_build/static/archives/extend/2013-January/date.html new file mode 100644 index 00000000..451345ad --- /dev/null +++ b/_build/static/archives/extend/2013-January/date.html @@ -0,0 +1,122 @@ + + + + The Extend January 2013 Archive by date + + + + + +

January 2013 Archives by date

+ +

Starting: Thu Jan 3 10:30:30 CET 2013
+ Ending: Fri Jan 25 07:26:27 CET 2013
+ Messages: 15

+

+

+ Last message date: + Fri Jan 25 07:26:27 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-January/index.html b/_build/static/archives/extend/2013-January/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-January/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-January/subject.html b/_build/static/archives/extend/2013-January/subject.html new file mode 100644 index 00000000..6bf3ddc3 --- /dev/null +++ b/_build/static/archives/extend/2013-January/subject.html @@ -0,0 +1,122 @@ + + + + The Extend January 2013 Archive by subject + + + + + +

January 2013 Archives by subject

+ +

Starting: Thu Jan 3 10:30:30 CET 2013
+ Ending: Fri Jan 25 07:26:27 CET 2013
+ Messages: 15

+

+

+ Last message date: + Fri Jan 25 07:26:27 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-January/thread.html b/_build/static/archives/extend/2013-January/thread.html new file mode 100644 index 00000000..262a0ac7 --- /dev/null +++ b/_build/static/archives/extend/2013-January/thread.html @@ -0,0 +1,151 @@ + + + + The Extend January 2013 Archive by thread + + + + + +

January 2013 Archives by thread

+ +

Starting: Thu Jan 3 10:30:30 CET 2013
+ Ending: Fri Jan 25 07:26:27 CET 2013
+ Messages: 15

+

+

+ Last message date: + Fri Jan 25 07:26:27 CET 2013
+ Archived on: Wed May 28 18:41:42 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-July.txt b/_build/static/archives/extend/2013-July.txt new file mode 100644 index 00000000..72bc16e4 --- /dev/null +++ b/_build/static/archives/extend/2013-July.txt @@ -0,0 +1,1977 @@ +From ivan at llaisdy.com Tue Jul 9 18:11:50 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Tue, 09 Jul 2013 17:11:50 +0100 +Subject: [99s-extend] Cowboy: http request maximum body size +Message-ID: <51DC3646.70207@llaisdy.com> + +Dear All + + From the source [1], it looks like the default maximum request body +size is 8 million bytes, but this can be set per request, up to +infinity. In the latter case there seems to be no upper limit set by +the server at all, and it will keep reading until some external force +makes it stop. + +That looks handy, if it means I don't have to stipulate a maximum +request body size (as long as I make sure the machine cowboy is running +on has a sensible amount of memory). + +Is that the case? If not, please correct. + +With thanks and best wishes + +Ivan + +[1] https://github.com/extend/cowboy/blob/master/src/cowboy_req.erl#L720-746 + + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From akuleshov at tpip.net Wed Jul 17 16:47:43 2013 +From: akuleshov at tpip.net (Alexander Kuleshov) +Date: Wed, 17 Jul 2013 16:47:43 +0200 (CEST) +Subject: [99s-extend] Serve static files with cowboy from some applications +Message-ID: <1124365136.645865.1374072463432.JavaMail.root@tpip.net> + +Hello, + +I have a web application which used cowboy (from master). I need to serve some static files, it's usual web application but i can use usual dispatch something like this: + + Dispatch = cowboy_router:compile([ + {'_', [ + {<<"/static/v/[...]">>, cowboy_static, [ + {etag, {attributes, [filepath, filesize, inode, mtime]}}, + {mimetypes, [ + {<<".js">> , [<<"application/javascript">>]}, + {<<".css">>, [<<"text/css">>]}, + {<<".gif">>, [<<"image/gif">>]}, + {<<".png">>, [<<"image/png">>]}, + {<<".jpg">>, [<<"image/jpeg">>]}, + {<<".html">>, [<<"text/html">>]} + ]}, + {directory, {priv_dir, my_app, [<<"static">>]}} + ]} + ]} + ]) + +And i try to explain why. In fact, i have one application (this application) which used cowboy and many plugins for it. Every plugin is an erlang application and also every application has own static files. I need routing something like this: + +if path /static/v/my_app/index.html than serve index.html from my_app + +if path /static/v/other_app/test.js that serve test.js from other_app. + +and etc.... + +Main goal to change: `my_app` from here: {directory, {priv_dir, my_app, [<<"static">>]} dynamically or write custom static handler. + +How to do it correctly with cowboy? + +Thank you. + +-- +Alex Kuleshov +Software Developer + +email: ak at travelping.com +phone: +77172227194 +mobile: +77019442517 + +----------------- enabling your networks --------------------- +Travelping GmbH phone: +49-391-8190990 +Roentgenstr. 13 fax: +49-391-819099299 +D-39108 Magdeburg email: info at travelping.com +GERMANY web: http://www.travelping.com + +Company Registration: Amtsgericht Stendal Reg No.: HRB 10578 +Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780 +-------------------------------------------------------------- + + +From adrian at id3as.co.uk Thu Jul 18 12:15:11 2013 +From: adrian at id3as.co.uk (Adrian Roe) +Date: Thu, 18 Jul 2013 11:15:11 +0100 +Subject: [99s-extend] Cowboy handler linked processes +Message-ID: + +We have been using spawn_linked workers to handle tasks that live for the lifetime of a single HTTP request + +Although in the cowboy guide it is clear that Cowboy can use "One Process of Many Requests" I am surprised that this is the case even if the handler crashes. For example, our use case is to copy a large file to the server over HTTP where a worker process relays the file contents to long term storage. The worker process is spawn_linked from the HTTP handler and (for our use case) should die if the handler stops. + +If the client stops the upload (for example by browsing away, or losing connectivity) we correctly receive an error (see sample Lager trace below), but what we are seeing is that spawn_linked processes are NOT being killed. + +Is this intended behaviour - I accept it makes sense to reuse the processes but should this continue to be the case even if the previous use of the process crashed? If it is intended behaviour I think the docs should highlight this as we've been leaking processes for some time now, but I've always seen it as erlang's job to look after related process trees in the event of error. Our current workaround is to hold a list of linked processes in process storage and then kill them in the terminate handler which is ugly in the extreme!! We don't know the PIDS of the linked processes until it is too late to return State to Cowboy (i.e. we are already in our handle code)... + +Kind regards + +Adrian + +16:09:32.347 [info] Trailer upload failed with reason {case_clause,{error,closed}} +16:09:32.348 [error] ** Cowboy handler upload_trailer_resource terminating in handle/2 + for the reason error:{case_clause,{error,closed}} +** Handler state was {state,undefined,0,undefined,undefined,undefined} +** Request was [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +** Stacktrace: [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] + + +-- +Dr Adrian Roe +Director + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jul 18 12:17:13 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 18 Jul 2013 12:17:13 +0200 +Subject: [99s-extend] Serve static files with cowboy from some + applications +In-Reply-To: <1124365136.645865.1374072463432.JavaMail.root@tpip.net> +References: <1124365136.645865.1374072463432.JavaMail.root@tpip.net> +Message-ID: <51E7C0A9.8050308@ninenines.eu> + +On 07/17/2013 04:47 PM, Alexander Kuleshov wrote: +> Hello, +> +> I have a web application which used cowboy (from master). I need to serve some static files, it's usual web application but i can use usual dispatch something like this: +> +> Dispatch = cowboy_router:compile([ +> {'_', [ +> {<<"/static/v/[...]">>, cowboy_static, [ +> {etag, {attributes, [filepath, filesize, inode, mtime]}}, +> {mimetypes, [ +> {<<".js">> , [<<"application/javascript">>]}, +> {<<".css">>, [<<"text/css">>]}, +> {<<".gif">>, [<<"image/gif">>]}, +> {<<".png">>, [<<"image/png">>]}, +> {<<".jpg">>, [<<"image/jpeg">>]}, +> {<<".html">>, [<<"text/html">>]} +> ]}, +> {directory, {priv_dir, my_app, [<<"static">>]}} +> ]} +> ]} +> ]) +> +> And i try to explain why. In fact, i have one application (this application) which used cowboy and many plugins for it. Every plugin is an erlang application and also every application has own static files. I need routing something like this: +> +> if path /static/v/my_app/index.html than serve index.html from my_app +> +> if path /static/v/other_app/test.js that serve test.js from other_app. +> +> and etc.... +> +> Main goal to change: `my_app` from here: {directory, {priv_dir, my_app, [<<"static">>]} dynamically or write custom static handler. +> +> How to do it correctly with cowboy? + +Why don't you add one rule per application? + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Thu Jul 18 12:20:36 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 18 Jul 2013 12:20:36 +0200 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: +References: +Message-ID: <51E7C174.2030501@ninenines.eu> + +I don't know what happens but there's two things I know: + + * Handlers don't trap_exit, so if the linked process crashes, they +crash too + * If the handler crashes, we close the connection and stop the +handler; if not this is a bug + +After your log message the handler should stop unless there's a bug +somewhere. + +On 07/18/2013 12:15 PM, Adrian Roe wrote: +> We have been using spawn_linked workers to handle tasks that live for +> the lifetime of a single HTTP request +> +> Although in the cowboy guide it is clear that Cowboy can use "One +> Process of Many Requests" I am surprised that this is the case even if +> the handler crashes. For example, our use case is to copy a large file +> to the server over HTTP where a worker process relays the file contents +> to long term storage. The worker process is spawn_linked from the HTTP +> handler and (for our use case) should die if the handler stops. +> +> If the client stops the upload (for example by browsing away, or losing +> connectivity) we correctly receive an error (see sample Lager trace +> below), but what we are seeing is that spawn_linked processes are NOT +> being killed. +> +> Is this intended behaviour - I accept it makes sense to reuse the +> processes but should this continue to be the case even if the previous +> use of the process crashed? If it is intended behaviour I think the +> docs should highlight this as we've been leaking processes for some time +> now, but I've always seen it as erlang's job to look after related +> process trees in the event of error. Our current workaround is to hold +> a list of linked processes in process storage and then kill them in the +> terminate handler which is ugly in the extreme!! We don't know the PIDS +> of the linked processes until it is too late to return State to Cowboy +> (i.e. we are already in our handle code)... +> +> Kind regards +> +> Adrian +> +> 16:09:32.347 [info] Trailer upload failed with reason +> {case_clause,{error,closed}} +> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +> terminating in handle/2 +> for the reason error:{case_clause,{error,closed}} +> ** Handler state was {state,undefined,0,undefined,undefined,undefined} +> ** Request was +> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, +> like Gecko) Chrome/28.0.1500.71 +> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +> ** Stacktrace: +> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +> +> +> -- +> Dr Adrian Roe +> Director +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From adrian at id3as.co.uk Thu Jul 18 12:31:45 2013 +From: adrian at id3as.co.uk (Adrian Roe) +Date: Thu, 18 Jul 2013 11:31:45 +0100 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: <51E7C174.2030501@ninenines.eu> +References: + <51E7C174.2030501@ninenines.eu> +Message-ID: + +My issue is the other way round. My handler crashes - and terminate gets called, but the linked process is NOT stopped (unless I stop it in terminate having stashed any processes I need to stop in the process dictionary - this is what I'm currently doing, but yuck!) + +. My question is whether it wouldn't be better to no re-use the handler process that has crashed and replace it so that handler's can use the canonical erlang way of stopping related processes rather than having to do it by hand. + +Obviously if the handler does not crash there's no need to kill the process, so the current efficiency saving works in the "normal" case/ + +-- +Dr Adrian Roe +Director + + +On Thursday, 18 July 2013 at 11:20, Lo?c Hoguin wrote: + +> I don't know what happens but there's two things I know: +> +> * Handlers don't trap_exit, so if the linked process crashes, they +> crash too +> * If the handler crashes, we close the connection and stop the +> handler; if not this is a bug +> +> After your log message the handler should stop unless there's a bug +> somewhere. +> +> On 07/18/2013 12:15 PM, Adrian Roe wrote: +> > We have been using spawn_linked workers to handle tasks that live for +> > the lifetime of a single HTTP request +> > +> > Although in the cowboy guide it is clear that Cowboy can use "One +> > Process of Many Requests" I am surprised that this is the case even if +> > the handler crashes. For example, our use case is to copy a large file +> > to the server over HTTP where a worker process relays the file contents +> > to long term storage. The worker process is spawn_linked from the HTTP +> > handler and (for our use case) should die if the handler stops. +> > +> > If the client stops the upload (for example by browsing away, or losing +> > connectivity) we correctly receive an error (see sample Lager trace +> > below), but what we are seeing is that spawn_linked processes are NOT +> > being killed. +> > +> > Is this intended behaviour - I accept it makes sense to reuse the +> > processes but should this continue to be the case even if the previous +> > use of the process crashed? If it is intended behaviour I think the +> > docs should highlight this as we've been leaking processes for some time +> > now, but I've always seen it as erlang's job to look after related +> > process trees in the event of error. Our current workaround is to hold +> > a list of linked processes in process storage and then kill them in the +> > terminate handler which is ugly in the extreme!! We don't know the PIDS +> > of the linked processes until it is too late to return State to Cowboy +> > (i.e. we are already in our handle code)... +> > +> > Kind regards +> > +> > Adrian +> > +> > 16:09:32.347 [info] Trailer upload failed with reason +> > {case_clause,{error,closed}} +> > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +> > terminating in handle/2 +> > for the reason error:{case_clause,{error,closed}} +> > ** Handler state was {state,undefined,0,undefined,undefined,undefined} +> > ** Request was +> > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +> > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +> > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, +> > like Gecko) Chrome/28.0.1500.71 +> > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +> > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +> > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +> > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +> > ** Stacktrace: +> > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +> > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +> > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +> > +> > +> > -- +> > Dr Adrian Roe +> > Director +> > +> > +> > +> > _______________________________________________ +> > Extend mailing list +> > Extend at lists.ninenines.eu (mailto:Extend at lists.ninenines.eu) +> > http://lists.ninenines.eu:81/listinfo/extend +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jul 18 12:36:04 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 18 Jul 2013 12:36:04 +0200 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: +References: + <51E7C174.2030501@ninenines.eu> + +Message-ID: <51E7C514.5040504@ninenines.eu> + +I don't think the problem is that the handler is reused, we don't reuse +them if there's an error. However we do catch errors to print them in +the logs, and then the process stops normally. If you link without +trap_exit you receive a normal exit signal which is ignored and doesn't +kill your process. I suppose we should throw an exit signal when we got +an error, after logging everything, instead of stopping normally. + +On 07/18/2013 12:31 PM, Adrian Roe wrote: +> My issue is the other way round. My handler crashes - and terminate +> gets called, but the linked process is NOT stopped (unless I stop it in +> terminate having stashed any processes I need to stop in the process +> dictionary - this is what I'm currently doing, but yuck!) +> +> . My question is whether it wouldn't be better to no re-use the handler +> process that has crashed and replace it so that handler's can use the +> canonical erlang way of stopping related processes rather than having to +> do it by hand. +> +> Obviously if the handler does not crash there's no need to kill the +> process, so the current efficiency saving works in the "normal" case/ +> +> -- +> Dr Adrian Roe +> Director +> +> On Thursday, 18 July 2013 at 11:20, Lo?c Hoguin wrote: +> +>> I don't know what happens but there's two things I know: +>> +>> * Handlers don't trap_exit, so if the linked process crashes, they +>> crash too +>> * If the handler crashes, we close the connection and stop the +>> handler; if not this is a bug +>> +>> After your log message the handler should stop unless there's a bug +>> somewhere. +>> +>> On 07/18/2013 12:15 PM, Adrian Roe wrote: +>>> We have been using spawn_linked workers to handle tasks that live for +>>> the lifetime of a single HTTP request +>>> +>>> Although in the cowboy guide it is clear that Cowboy can use "One +>>> Process of Many Requests" I am surprised that this is the case even if +>>> the handler crashes. For example, our use case is to copy a large file +>>> to the server over HTTP where a worker process relays the file contents +>>> to long term storage. The worker process is spawn_linked from the HTTP +>>> handler and (for our use case) should die if the handler stops. +>>> +>>> If the client stops the upload (for example by browsing away, or losing +>>> connectivity) we correctly receive an error (see sample Lager trace +>>> below), but what we are seeing is that spawn_linked processes are NOT +>>> being killed. +>>> +>>> Is this intended behaviour - I accept it makes sense to reuse the +>>> processes but should this continue to be the case even if the previous +>>> use of the process crashed? If it is intended behaviour I think the +>>> docs should highlight this as we've been leaking processes for some time +>>> now, but I've always seen it as erlang's job to look after related +>>> process trees in the event of error. Our current workaround is to hold +>>> a list of linked processes in process storage and then kill them in the +>>> terminate handler which is ugly in the extreme!! We don't know the PIDS +>>> of the linked processes until it is too late to return State to Cowboy +>>> (i.e. we are already in our handle code)... +>>> +>>> Kind regards +>>> +>>> Adrian +>>> +>>> 16:09:32.347 [info] Trailer upload failed with reason +>>> {case_clause,{error,closed}} +>>> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +>>> terminating in handle/2 +>>> for the reason error:{case_clause,{error,closed}} +>>> ** Handler state was {state,undefined,0,undefined,undefined,undefined} +>>> ** Request was +>>> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +>>> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +>>> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, +>>> like Gecko) Chrome/28.0.1500.71 +>>> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +>>> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +>>> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +>>> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +>>> ** Stacktrace: +>>> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +>>> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +>>> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +>>> +>>> +>>> -- +>>> Dr Adrian Roe +>>> Director +>>> +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From adrian at id3as.co.uk Thu Jul 18 12:37:30 2013 +From: adrian at id3as.co.uk (Adrian Roe) +Date: Thu, 18 Jul 2013 11:37:30 +0100 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: <51E7C514.5040504@ninenines.eu> +References: + <51E7C174.2030501@ninenines.eu> + + <51E7C514.5040504@ninenines.eu> +Message-ID: <66E9A8B267A946AF8F527593BBFD26B0@id3as.co.uk> + +That would be perfect! Do you want me to make the change and issue a pull request? + +-- +Dr Adrian Roe +Director + + +On Thursday, 18 July 2013 at 11:36, Lo?c Hoguin wrote: + +> I don't think the problem is that the handler is reused, we don't reuse +> them if there's an error. However we do catch errors to print them in +> the logs, and then the process stops normally. If you link without +> trap_exit you receive a normal exit signal which is ignored and doesn't +> kill your process. I suppose we should throw an exit signal when we got +> an error, after logging everything, instead of stopping normally. +> +> On 07/18/2013 12:31 PM, Adrian Roe wrote: +> > My issue is the other way round. My handler crashes - and terminate +> > gets called, but the linked process is NOT stopped (unless I stop it in +> > terminate having stashed any processes I need to stop in the process +> > dictionary - this is what I'm currently doing, but yuck!) +> > +> > . My question is whether it wouldn't be better to no re-use the handler +> > process that has crashed and replace it so that handler's can use the +> > canonical erlang way of stopping related processes rather than having to +> > do it by hand. +> > +> > Obviously if the handler does not crash there's no need to kill the +> > process, so the current efficiency saving works in the "normal" case/ +> > +> > -- +> > Dr Adrian Roe +> > Director +> > +> > On Thursday, 18 July 2013 at 11:20, Lo?c Hoguin wrote: +> > +> > > I don't know what happens but there's two things I know: +> > > +> > > * Handlers don't trap_exit, so if the linked process crashes, they +> > > crash too +> > > * If the handler crashes, we close the connection and stop the +> > > handler; if not this is a bug +> > > +> > > After your log message the handler should stop unless there's a bug +> > > somewhere. +> > > +> > > On 07/18/2013 12:15 PM, Adrian Roe wrote: +> > > > We have been using spawn_linked workers to handle tasks that live for +> > > > the lifetime of a single HTTP request +> > > > +> > > > Although in the cowboy guide it is clear that Cowboy can use "One +> > > > Process of Many Requests" I am surprised that this is the case even if +> > > > the handler crashes. For example, our use case is to copy a large file +> > > > to the server over HTTP where a worker process relays the file contents +> > > > to long term storage. The worker process is spawn_linked from the HTTP +> > > > handler and (for our use case) should die if the handler stops. +> > > > +> > > > If the client stops the upload (for example by browsing away, or losing +> > > > connectivity) we correctly receive an error (see sample Lager trace +> > > > below), but what we are seeing is that spawn_linked processes are NOT +> > > > being killed. +> > > > +> > > > Is this intended behaviour - I accept it makes sense to reuse the +> > > > processes but should this continue to be the case even if the previous +> > > > use of the process crashed? If it is intended behaviour I think the +> > > > docs should highlight this as we've been leaking processes for some time +> > > > now, but I've always seen it as erlang's job to look after related +> > > > process trees in the event of error. Our current workaround is to hold +> > > > a list of linked processes in process storage and then kill them in the +> > > > terminate handler which is ugly in the extreme!! We don't know the PIDS +> > > > of the linked processes until it is too late to return State to Cowboy +> > > > (i.e. we are already in our handle code)... +> > > > +> > > > Kind regards +> > > > +> > > > Adrian +> > > > +> > > > 16:09:32.347 [info] Trailer upload failed with reason +> > > > {case_clause,{error,closed}} +> > > > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +> > > > terminating in handle/2 +> > > > for the reason error:{case_clause,{error,closed}} +> > > > ** Handler state was {state,undefined,0,undefined,undefined,undefined} +> > > > ** Request was +> > > > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +> > > > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +> > > > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, +> > > > like Gecko) Chrome/28.0.1500.71 +> > > > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +> > > > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +> > > > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +> > > > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +> > > > ** Stacktrace: +> > > > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +> > > > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +> > > > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +> > > > +> > > > +> > > > -- +> > > > Dr Adrian Roe +> > > > Director +> > > > +> > > > +> > > > +> > > > _______________________________________________ +> > > > Extend mailing list +> > > > Extend at lists.ninenines.eu +> > > > http://lists.ninenines.eu:81/listinfo/extend +> > > > +> > > +> > > +> > > +> > > -- +> > > Lo?c Hoguin +> > > Erlang Cowboy +> > > Nine Nines +> > > http://ninenines.eu +> > > +> > +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jul 18 12:38:13 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 18 Jul 2013 12:38:13 +0200 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: <66E9A8B267A946AF8F527593BBFD26B0@id3as.co.uk> +References: + <51E7C174.2030501@ninenines.eu> + + <51E7C514.5040504@ninenines.eu> + <66E9A8B267A946AF8F527593BBFD26B0@id3as.co.uk> +Message-ID: <51E7C595.5050905@ninenines.eu> + +If you got time sure, I won't have much time until Monday. Have fun! + +On 07/18/2013 12:37 PM, Adrian Roe wrote: +> That would be perfect! Do you want me to make the change and issue a +> pull request? +> +> -- +> Dr Adrian Roe +> Director +> +> On Thursday, 18 July 2013 at 11:36, Lo?c Hoguin wrote: +> +>> I don't think the problem is that the handler is reused, we don't reuse +>> them if there's an error. However we do catch errors to print them in +>> the logs, and then the process stops normally. If you link without +>> trap_exit you receive a normal exit signal which is ignored and doesn't +>> kill your process. I suppose we should throw an exit signal when we got +>> an error, after logging everything, instead of stopping normally. +>> +>> On 07/18/2013 12:31 PM, Adrian Roe wrote: +>>> My issue is the other way round. My handler crashes - and terminate +>>> gets called, but the linked process is NOT stopped (unless I stop it in +>>> terminate having stashed any processes I need to stop in the process +>>> dictionary - this is what I'm currently doing, but yuck!) +>>> +>>> . My question is whether it wouldn't be better to no re-use the handler +>>> process that has crashed and replace it so that handler's can use the +>>> canonical erlang way of stopping related processes rather than having to +>>> do it by hand. +>>> +>>> Obviously if the handler does not crash there's no need to kill the +>>> process, so the current efficiency saving works in the "normal" case/ +>>> +>>> -- +>>> Dr Adrian Roe +>>> Director +>>> +>>> On Thursday, 18 July 2013 at 11:20, Lo?c Hoguin wrote: +>>> +>>>> I don't know what happens but there's two things I know: +>>>> +>>>> * Handlers don't trap_exit, so if the linked process crashes, they +>>>> crash too +>>>> * If the handler crashes, we close the connection and stop the +>>>> handler; if not this is a bug +>>>> +>>>> After your log message the handler should stop unless there's a bug +>>>> somewhere. +>>>> +>>>> On 07/18/2013 12:15 PM, Adrian Roe wrote: +>>>>> We have been using spawn_linked workers to handle tasks that live for +>>>>> the lifetime of a single HTTP request +>>>>> +>>>>> Although in the cowboy guide it is clear that Cowboy can use "One +>>>>> Process of Many Requests" I am surprised that this is the case even if +>>>>> the handler crashes. For example, our use case is to copy a large file +>>>>> to the server over HTTP where a worker process relays the file contents +>>>>> to long term storage. The worker process is spawn_linked from the HTTP +>>>>> handler and (for our use case) should die if the handler stops. +>>>>> +>>>>> If the client stops the upload (for example by browsing away, or losing +>>>>> connectivity) we correctly receive an error (see sample Lager trace +>>>>> below), but what we are seeing is that spawn_linked processes are NOT +>>>>> being killed. +>>>>> +>>>>> Is this intended behaviour - I accept it makes sense to reuse the +>>>>> processes but should this continue to be the case even if the previous +>>>>> use of the process crashed? If it is intended behaviour I think the +>>>>> docs should highlight this as we've been leaking processes for some +>>>>> time +>>>>> now, but I've always seen it as erlang's job to look after related +>>>>> process trees in the event of error. Our current workaround is to hold +>>>>> a list of linked processes in process storage and then kill them in the +>>>>> terminate handler which is ugly in the extreme!! We don't know the PIDS +>>>>> of the linked processes until it is too late to return State to Cowboy +>>>>> (i.e. we are already in our handle code)... +>>>>> +>>>>> Kind regards +>>>>> +>>>>> Adrian +>>>>> +>>>>> 16:09:32.347 [info] Trailer upload failed with reason +>>>>> {case_clause,{error,closed}} +>>>>> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +>>>>> terminating in handle/2 +>>>>> for the reason error:{case_clause,{error,closed}} +>>>>> ** Handler state was {state,undefined,0,undefined,undefined,undefined} +>>>>> ** Request was +>>>>> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +>>>>> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +>>>>> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 +>>>>> (KHTML, +>>>>> like Gecko) Chrome/28.0.1500.71 +>>>>> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +>>>>> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +>>>>> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +>>>>> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +>>>>> ** Stacktrace: +>>>>> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +>>>>> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +>>>>> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +>>>>> +>>>>> +>>>>> -- +>>>>> Dr Adrian Roe +>>>>> Director +>>>>> +>>>>> +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From adrian at id3as.co.uk Thu Jul 18 19:55:20 2013 +From: adrian at id3as.co.uk (Adrian Roe) +Date: Thu, 18 Jul 2013 18:55:20 +0100 +Subject: [99s-extend] Cowboy handler linked processes +In-Reply-To: <51E7C595.5050905@ninenines.eu> +References: + <51E7C174.2030501@ninenines.eu> + + <51E7C514.5040504@ninenines.eu> + <66E9A8B267A946AF8F527593BBFD26B0@id3as.co.uk> + <51E7C595.5050905@ninenines.eu> +Message-ID: <545C0D63E95147B48DA892A0ECB4382E@id3as.co.uk> + +I suspect it's just a case of adding a throw to error_terminate in cowboy_protocol, maybe with threading the reason back (though I don't really care what's thrown), but also fear there may be unintended consequences as all I've done is skim your code briefly! If you are able to look at it then great - if not I'll muddle through. I'm travelling so it would be mid next week at the earliest anyway. + +Cheers + +Adrian + +-- +Dr Adrian Roe +Director + + +On Thursday, 18 July 2013 at 11:38, Lo?c Hoguin wrote: + +> If you got time sure, I won't have much time until Monday. Have fun! +> +> On 07/18/2013 12:37 PM, Adrian Roe wrote: +> > That would be perfect! Do you want me to make the change and issue a +> > pull request? +> > +> > -- +> > Dr Adrian Roe +> > Director +> > +> > On Thursday, 18 July 2013 at 11:36, Lo?c Hoguin wrote: +> > +> > > I don't think the problem is that the handler is reused, we don't reuse +> > > them if there's an error. However we do catch errors to print them in +> > > the logs, and then the process stops normally. If you link without +> > > trap_exit you receive a normal exit signal which is ignored and doesn't +> > > kill your process. I suppose we should throw an exit signal when we got +> > > an error, after logging everything, instead of stopping normally. +> > > +> > > On 07/18/2013 12:31 PM, Adrian Roe wrote: +> > > > My issue is the other way round. My handler crashes - and terminate +> > > > gets called, but the linked process is NOT stopped (unless I stop it in +> > > > terminate having stashed any processes I need to stop in the process +> > > > dictionary - this is what I'm currently doing, but yuck!) +> > > > +> > > > . My question is whether it wouldn't be better to no re-use the handler +> > > > process that has crashed and replace it so that handler's can use the +> > > > canonical erlang way of stopping related processes rather than having to +> > > > do it by hand. +> > > > +> > > > Obviously if the handler does not crash there's no need to kill the +> > > > process, so the current efficiency saving works in the "normal" case/ +> > > > +> > > > -- +> > > > Dr Adrian Roe +> > > > Director +> > > > +> > > > On Thursday, 18 July 2013 at 11:20, Lo?c Hoguin wrote: +> > > > +> > > > > I don't know what happens but there's two things I know: +> > > > > +> > > > > * Handlers don't trap_exit, so if the linked process crashes, they +> > > > > crash too +> > > > > * If the handler crashes, we close the connection and stop the +> > > > > handler; if not this is a bug +> > > > > +> > > > > After your log message the handler should stop unless there's a bug +> > > > > somewhere. +> > > > > +> > > > > On 07/18/2013 12:15 PM, Adrian Roe wrote: +> > > > > > We have been using spawn_linked workers to handle tasks that live for +> > > > > > the lifetime of a single HTTP request +> > > > > > +> > > > > > Although in the cowboy guide it is clear that Cowboy can use "One +> > > > > > Process of Many Requests" I am surprised that this is the case even if +> > > > > > the handler crashes. For example, our use case is to copy a large file +> > > > > > to the server over HTTP where a worker process relays the file contents +> > > > > > to long term storage. The worker process is spawn_linked from the HTTP +> > > > > > handler and (for our use case) should die if the handler stops. +> > > > > > +> > > > > > If the client stops the upload (for example by browsing away, or losing +> > > > > > connectivity) we correctly receive an error (see sample Lager trace +> > > > > > below), but what we are seeing is that spawn_linked processes are NOT +> > > > > > being killed. +> > > > > > +> > > > > > Is this intended behaviour - I accept it makes sense to reuse the +> > > > > > processes but should this continue to be the case even if the previous +> > > > > > use of the process crashed? If it is intended behaviour I think the +> > > > > > docs should highlight this as we've been leaking processes for some +> > > > > > time +> > > > > > now, but I've always seen it as erlang's job to look after related +> > > > > > process trees in the event of error. Our current workaround is to hold +> > > > > > a list of linked processes in process storage and then kill them in the +> > > > > > terminate handler which is ugly in the extreme!! We don't know the PIDS +> > > > > > of the linked processes until it is too late to return State to Cowboy +> > > > > > (i.e. we are already in our handle code)... +> > > > > > +> > > > > > Kind regards +> > > > > > +> > > > > > Adrian +> > > > > > +> > > > > > 16:09:32.347 [info] Trailer upload failed with reason +> > > > > > {case_clause,{error,closed}} +> > > > > > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource +> > > > > > terminating in handle/2 +> > > > > > for the reason error:{case_clause,{error,closed}} +> > > > > > ** Handler state was {state,undefined,0,undefined,undefined,undefined} +> > > > > > ** Request was +> > > > > > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef +> > > > > > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M +> > > > > > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 +> > > > > > (KHTML, +> > > > > > like Gecko) Chrome/28.0.1500.71 +> > > > > > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce +> > > > > > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; +> > > > > > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde +> > > > > > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}] +> > > > > > ** Stacktrace: +> > > > > > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"} +> > > > > > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo +> > > > > > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}] +> > > > > > +> > > > > > +> > > > > > -- +> > > > > > Dr Adrian Roe +> > > > > > Director +> > > > > > +> > > > > > +> > > > > > +> > > > > > _______________________________________________ +> > > > > > Extend mailing list +> > > > > > Extend at lists.ninenines.eu +> > > > > > http://lists.ninenines.eu:81/listinfo/extend +> > > > > > +> > > > > +> > > > > +> > > > > +> > > > > -- +> > > > > Lo?c Hoguin +> > > > > Erlang Cowboy +> > > > > Nine Nines +> > > > > http://ninenines.eu +> > > > > +> > > > +> > > > +> > > +> > > +> > > +> > > -- +> > > Lo?c Hoguin +> > > Erlang Cowboy +> > > Nine Nines +> > > http://ninenines.eu +> > > +> > +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lee.sylvester at gmail.com Tue Jul 23 15:12:08 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Tue, 23 Jul 2013 14:12:08 +0100 +Subject: [99s-extend] Cowboy HTTPS Issue +Message-ID: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + +Hi guys, + +So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: + +application: ssl + exited: {bad_return, + {{ssl_app,start,[normal,[]]}, + {'EXIT', + {undef, + [{ssl_app,start,[normal,[]],[]}, + {application_master,start_it_old,4, + [{file,"application_master.erl"}, + {line,274}]}]}}}} + type: temporary + + +The way I'm starting Cowboy is like this: + + Env = [ + {env, [{dispatch, Dispatch}]}, + {onrequest, fun http_utils:set_request_cors/1} + ], + + case http_server:is_secure() of + true -> + cowboy:start_https(https, 100, [ + {ip, Ip}, {port, Port}, + {certfile, binary_to_list(http_server:secure_cert())}, + {keyfile, binary_to_list(http_server:secure_key())}, + {reuseaddr, true}, + {fail_if_no_peer_cert, true} + ], Env); + _ -> + {ok, _} = cowboy:start_http(http, 100, Options, Env) + end, + +Does anyone know why I might be getting this issue? + +Thanks, +Lee + + + + +From essen at ninenines.eu Tue Jul 23 15:41:42 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 23 Jul 2013 15:41:42 +0200 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> +Message-ID: <51EE8816.1040801@ninenines.eu> + +You need to include and start the public_key and ssl applications. + +On 07/23/2013 03:12 PM, Lee Sylvester wrote: +> Hi guys, +> +> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: +> +> application: ssl +> exited: {bad_return, +> {{ssl_app,start,[normal,[]]}, +> {'EXIT', +> {undef, +> [{ssl_app,start,[normal,[]],[]}, +> {application_master,start_it_old,4, +> [{file,"application_master.erl"}, +> {line,274}]}]}}}} +> type: temporary +> +> +> The way I'm starting Cowboy is like this: +> +> Env = [ +> {env, [{dispatch, Dispatch}]}, +> {onrequest, fun http_utils:set_request_cors/1} +> ], +> +> case http_server:is_secure() of +> true -> +> cowboy:start_https(https, 100, [ +> {ip, Ip}, {port, Port}, +> {certfile, binary_to_list(http_server:secure_cert())}, +> {keyfile, binary_to_list(http_server:secure_key())}, +> {reuseaddr, true}, +> {fail_if_no_peer_cert, true} +> ], Env); +> _ -> +> {ok, _} = cowboy:start_http(http, 100, Options, Env) +> end, +> +> Does anyone know why I might be getting this issue? +> +> Thanks, +> Lee +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Tue Jul 23 15:59:00 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Tue, 23 Jul 2013 14:59:00 +0100 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: <51EE8816.1040801@ninenines.eu> +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + <51EE8816.1040801@ninenines.eu> +Message-ID: + +Thank you, Loic. I'd forgotten to update my releases folder. + +I now have it running, but when I access an endpoint, I get + +=ERROR REPORT==== 23-Jul-2013::09:56:29 === +SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33, + 126,49,13, [snip] 45,193>>, + <<48,130,6 [snip] 118,247,97>>] /usr/certs/cert.pem + [{ssl_connection,init_certificates,8, + [{file,"ssl_connection.erl"},{line,1155}]}, + {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]}, + {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]}, + {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] + +Not a very helpful error. I'm assuming the cert isn't being accepted by the SSL module? + +Thanks, +Lee + + + +On 23 Jul 2013, at 14:41, Lo?c Hoguin wrote: + +> You need to include and start the public_key and ssl applications. +> +> On 07/23/2013 03:12 PM, Lee Sylvester wrote: +>> Hi guys, +>> +>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: +>> +>> application: ssl +>> exited: {bad_return, +>> {{ssl_app,start,[normal,[]]}, +>> {'EXIT', +>> {undef, +>> [{ssl_app,start,[normal,[]],[]}, +>> {application_master,start_it_old,4, +>> [{file,"application_master.erl"}, +>> {line,274}]}]}}}} +>> type: temporary +>> +>> +>> The way I'm starting Cowboy is like this: +>> +>> Env = [ +>> {env, [{dispatch, Dispatch}]}, +>> {onrequest, fun http_utils:set_request_cors/1} +>> ], +>> +>> case http_server:is_secure() of +>> true -> +>> cowboy:start_https(https, 100, [ +>> {ip, Ip}, {port, Port}, +>> {certfile, binary_to_list(http_server:secure_cert())}, +>> {keyfile, binary_to_list(http_server:secure_key())}, +>> {reuseaddr, true}, +>> {fail_if_no_peer_cert, true} +>> ], Env); +>> _ -> +>> {ok, _} = cowboy:start_http(http, 100, Options, Env) +>> end, +>> +>> Does anyone know why I might be getting this issue? +>> +>> Thanks, +>> Lee +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Tue Jul 23 16:00:13 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 23 Jul 2013 16:00:13 +0200 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + <51EE8816.1040801@ninenines.eu> + +Message-ID: <51EE8C6D.5060601@ninenines.eu> + +No idea. You'll probably have more luck asking erlang-questions for SSL +issues. + +On 07/23/2013 03:59 PM, Lee Sylvester wrote: +> Thank you, Loic. I'd forgotten to update my releases folder. +> +> I now have it running, but when I access an endpoint, I get +> +> =ERROR REPORT==== 23-Jul-2013::09:56:29 === +> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33, +> 126,49,13, [snip] 45,193>>, +> <<48,130,6 [snip] 118,247,97>>] /usr/certs/cert.pem +> [{ssl_connection,init_certificates,8, +> [{file,"ssl_connection.erl"},{line,1155}]}, +> {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]}, +> {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]}, +> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] +> +> Not a very helpful error. I'm assuming the cert isn't being accepted by the SSL module? +> +> Thanks, +> Lee +> +> +> +> On 23 Jul 2013, at 14:41, Lo?c Hoguin wrote: +> +>> You need to include and start the public_key and ssl applications. +>> +>> On 07/23/2013 03:12 PM, Lee Sylvester wrote: +>>> Hi guys, +>>> +>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: +>>> +>>> application: ssl +>>> exited: {bad_return, +>>> {{ssl_app,start,[normal,[]]}, +>>> {'EXIT', +>>> {undef, +>>> [{ssl_app,start,[normal,[]],[]}, +>>> {application_master,start_it_old,4, +>>> [{file,"application_master.erl"}, +>>> {line,274}]}]}}}} +>>> type: temporary +>>> +>>> +>>> The way I'm starting Cowboy is like this: +>>> +>>> Env = [ +>>> {env, [{dispatch, Dispatch}]}, +>>> {onrequest, fun http_utils:set_request_cors/1} +>>> ], +>>> +>>> case http_server:is_secure() of +>>> true -> +>>> cowboy:start_https(https, 100, [ +>>> {ip, Ip}, {port, Port}, +>>> {certfile, binary_to_list(http_server:secure_cert())}, +>>> {keyfile, binary_to_list(http_server:secure_key())}, +>>> {reuseaddr, true}, +>>> {fail_if_no_peer_cert, true} +>>> ], Env); +>>> _ -> +>>> {ok, _} = cowboy:start_http(http, 100, Options, Env) +>>> end, +>>> +>>> Does anyone know why I might be getting this issue? +>>> +>>> Thanks, +>>> Lee +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Tue Jul 23 16:01:07 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Tue, 23 Jul 2013 15:01:07 +0100 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: <51EE8C6D.5060601@ninenines.eu> +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + <51EE8816.1040801@ninenines.eu> + + <51EE8C6D.5060601@ninenines.eu> +Message-ID: <9B85045F-0FA0-4CCE-8F57-863CCF83E28C@gmail.com> + +Okay, thanks Lo?c. I'll try my luck there :-) + +Regards, +Lee + + + +On 23 Jul 2013, at 15:00, Lo?c Hoguin wrote: + +> No idea. You'll probably have more luck asking erlang-questions for SSL issues. +> +> On 07/23/2013 03:59 PM, Lee Sylvester wrote: +>> Thank you, Loic. I'd forgotten to update my releases folder. +>> +>> I now have it running, but when I access an endpoint, I get +>> +>> =ERROR REPORT==== 23-Jul-2013::09:56:29 === +>> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33, +>> 126,49,13, [snip] 45,193>>, +>> <<48,130,6 [snip] 118,247,97>>] /usr/certs/cert.pem +>> [{ssl_connection,init_certificates,8, +>> [{file,"ssl_connection.erl"},{line,1155}]}, +>> {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]}, +>> {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]}, +>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] +>> +>> Not a very helpful error. I'm assuming the cert isn't being accepted by the SSL module? +>> +>> Thanks, +>> Lee +>> +>> +>> +>> On 23 Jul 2013, at 14:41, Lo?c Hoguin wrote: +>> +>>> You need to include and start the public_key and ssl applications. +>>> +>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote: +>>>> Hi guys, +>>>> +>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: +>>>> +>>>> application: ssl +>>>> exited: {bad_return, +>>>> {{ssl_app,start,[normal,[]]}, +>>>> {'EXIT', +>>>> {undef, +>>>> [{ssl_app,start,[normal,[]],[]}, +>>>> {application_master,start_it_old,4, +>>>> [{file,"application_master.erl"}, +>>>> {line,274}]}]}}}} +>>>> type: temporary +>>>> +>>>> +>>>> The way I'm starting Cowboy is like this: +>>>> +>>>> Env = [ +>>>> {env, [{dispatch, Dispatch}]}, +>>>> {onrequest, fun http_utils:set_request_cors/1} +>>>> ], +>>>> +>>>> case http_server:is_secure() of +>>>> true -> +>>>> cowboy:start_https(https, 100, [ +>>>> {ip, Ip}, {port, Port}, +>>>> {certfile, binary_to_list(http_server:secure_cert())}, +>>>> {keyfile, binary_to_list(http_server:secure_key())}, +>>>> {reuseaddr, true}, +>>>> {fail_if_no_peer_cert, true} +>>>> ], Env); +>>>> _ -> +>>>> {ok, _} = cowboy:start_http(http, 100, Options, Env) +>>>> end, +>>>> +>>>> Does anyone know why I might be getting this issue? +>>>> +>>>> Thanks, +>>>> Lee +>>>> +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From edgurgel at gmail.com Tue Jul 23 16:15:36 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Tue, 23 Jul 2013 11:15:36 -0300 +Subject: [99s-extend] OPTIONS and is_authorized +Message-ID: + +What's the best way to skip is_authorized callback for OPTIONS methods? For +all my rest handlers? + +Thanks in advance for any help you are able to provide. + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From list1 at gjunka.com Thu Jul 25 11:24:24 2013 +From: list1 at gjunka.com (Grzegorz Junka) +Date: Thu, 25 Jul 2013 10:24:24 +0100 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: <9B85045F-0FA0-4CCE-8F57-863CCF83E28C@gmail.com> +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + <51EE8816.1040801@ninenines.eu> + + <51EE8C6D.5060601@ninenines.eu> + <9B85045F-0FA0-4CCE-8F57-863CCF83E28C@gmail.com> +Message-ID: <51F0EEC8.4080408@gjunka.com> + +Maybe the problem is with Erlang not seeing the crypto libraries? You +can verify that quickly by executing "crypto:start()." in the Erlang +shell. See this post for info: + +http://stackoverflow.com/questions/4742184/rebar-error-exit-on-create-app-crypto-start/14776521#14776521 + +Greg + +On 23/07/2013 15:01, Lee Sylvester wrote: +> Okay, thanks Lo?c. I'll try my luck there :-) +> +> Regards, +> Lee +> +> +> +> On 23 Jul 2013, at 15:00, Lo?c Hoguin wrote: +> +>> No idea. You'll probably have more luck asking erlang-questions for SSL issues. +>> +>> On 07/23/2013 03:59 PM, Lee Sylvester wrote: +>>> Thank you, Loic. I'd forgotten to update my releases folder. +>>> +>>> I now have it running, but when I access an endpoint, I get +>>> +>>> =ERROR REPORT==== 23-Jul-2013::09:56:29 === +>>> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33, +>>> 126,49,13, [snip] 45,193>>, +>>> <<48,130,6 [snip] 118,247,97>>] /usr/certs/cert.pem +>>> [{ssl_connection,init_certificates,8, +>>> [{file,"ssl_connection.erl"},{line,1155}]}, +>>> {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]}, +>>> {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]}, +>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] +>>> +>>> Not a very helpful error. I'm assuming the cert isn't being accepted by the SSL module? +>>> +>>> Thanks, +>>> Lee +>>> +>>> +>>> +>>> On 23 Jul 2013, at 14:41, Lo?c Hoguin wrote: +>>> +>>>> You need to include and start the public_key and ssl applications. +>>>> +>>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote: +>>>>> Hi guys, +>>>>> +>>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module: +>>>>> +>>>>> application: ssl +>>>>> exited: {bad_return, +>>>>> {{ssl_app,start,[normal,[]]}, +>>>>> {'EXIT', +>>>>> {undef, +>>>>> [{ssl_app,start,[normal,[]],[]}, +>>>>> {application_master,start_it_old,4, +>>>>> [{file,"application_master.erl"}, +>>>>> {line,274}]}]}}}} +>>>>> type: temporary +>>>>> +>>>>> +>>>>> The way I'm starting Cowboy is like this: +>>>>> +>>>>> Env = [ +>>>>> {env, [{dispatch, Dispatch}]}, +>>>>> {onrequest, fun http_utils:set_request_cors/1} +>>>>> ], +>>>>> +>>>>> case http_server:is_secure() of +>>>>> true -> +>>>>> cowboy:start_https(https, 100, [ +>>>>> {ip, Ip}, {port, Port}, +>>>>> {certfile, binary_to_list(http_server:secure_cert())}, +>>>>> {keyfile, binary_to_list(http_server:secure_key())}, +>>>>> {reuseaddr, true}, +>>>>> {fail_if_no_peer_cert, true} +>>>>> ], Env); +>>>>> _ -> +>>>>> {ok, _} = cowboy:start_http(http, 100, Options, Env) +>>>>> end, +>>>>> +>>>>> Does anyone know why I might be getting this issue? +>>>>> +>>>>> Thanks, +>>>>> Lee +>>>>> +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + + +From essen at ninenines.eu Thu Jul 25 11:25:02 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 25 Jul 2013 11:25:02 +0200 +Subject: [99s-extend] Cowboy HTTPS Issue +In-Reply-To: <51F0EEC8.4080408@gjunka.com> +References: <420FF871-86CC-4956-924A-514047C614EB@gmail.com> + <51EE8816.1040801@ninenines.eu> + + <51EE8C6D.5060601@ninenines.eu> + <9B85045F-0FA0-4CCE-8F57-863CCF83E28C@gmail.com> + <51F0EEC8.4080408@gjunka.com> +Message-ID: <51F0EEEE.8050002@ninenines.eu> + +Cowboy requires crypto to start. + +On 07/25/2013 11:24 AM, Grzegorz Junka wrote: +> Maybe the problem is with Erlang not seeing the crypto libraries? You +> can verify that quickly by executing "crypto:start()." in the Erlang +> shell. See this post for info: +> +> http://stackoverflow.com/questions/4742184/rebar-error-exit-on-create-app-crypto-start/14776521#14776521 +> +> +> Greg +> +> On 23/07/2013 15:01, Lee Sylvester wrote: +>> Okay, thanks Lo?c. I'll try my luck there :-) +>> +>> Regards, +>> Lee +>> +>> +>> +>> On 23 Jul 2013, at 15:00, Lo?c Hoguin wrote: +>> +>>> No idea. You'll probably have more luck asking erlang-questions for +>>> SSL issues. +>>> +>>> On 07/23/2013 03:59 PM, Lee Sylvester wrote: +>>>> Thank you, Loic. I'd forgotten to update my releases folder. +>>>> +>>>> I now have it running, but when I access an endpoint, I get +>>>> +>>>> =ERROR REPORT==== 23-Jul-2013::09:56:29 === +>>>> SSL: 1159: +>>>> error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33, +>>>> 126,49,13, [snip] 45,193>>, +>>>> <<48,130,6 [snip] 118,247,97>>] +>>>> /usr/certs/cert.pem +>>>> [{ssl_connection,init_certificates,8, +>>>> [{file,"ssl_connection.erl"},{line,1155}]}, +>>>> +>>>> {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]}, +>>>> {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]}, +>>>> {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}] +>>>> +>>>> Not a very helpful error. I'm assuming the cert isn't being +>>>> accepted by the SSL module? +>>>> +>>>> Thanks, +>>>> Lee +>>>> +>>>> +>>>> +>>>> On 23 Jul 2013, at 14:41, Lo?c Hoguin wrote: +>>>> +>>>>> You need to include and start the public_key and ssl applications. +>>>>> +>>>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote: +>>>>>> Hi guys, +>>>>>> +>>>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error +>>>>>> with the SSL module: +>>>>>> +>>>>>> application: ssl +>>>>>> exited: {bad_return, +>>>>>> {{ssl_app,start,[normal,[]]}, +>>>>>> {'EXIT', +>>>>>> {undef, +>>>>>> [{ssl_app,start,[normal,[]],[]}, +>>>>>> {application_master,start_it_old,4, +>>>>>> [{file,"application_master.erl"}, +>>>>>> {line,274}]}]}}}} +>>>>>> type: temporary +>>>>>> +>>>>>> +>>>>>> The way I'm starting Cowboy is like this: +>>>>>> +>>>>>> Env = [ +>>>>>> {env, [{dispatch, Dispatch}]}, +>>>>>> {onrequest, fun http_utils:set_request_cors/1} +>>>>>> ], +>>>>>> +>>>>>> case http_server:is_secure() of +>>>>>> true -> +>>>>>> cowboy:start_https(https, 100, [ +>>>>>> {ip, Ip}, {port, Port}, +>>>>>> {certfile, +>>>>>> binary_to_list(http_server:secure_cert())}, +>>>>>> {keyfile, binary_to_list(http_server:secure_key())}, +>>>>>> {reuseaddr, true}, +>>>>>> {fail_if_no_peer_cert, true} +>>>>>> ], Env); +>>>>>> _ -> +>>>>>> {ok, _} = cowboy:start_http(http, 100, Options, Env) +>>>>>> end, +>>>>>> +>>>>>> Does anyone know why I might be getting this issue? +>>>>>> +>>>>>> Thanks, +>>>>>> Lee +>>>>>> +>>>>>> +>>>>>> _______________________________________________ +>>>>>> Extend mailing list +>>>>>> Extend at lists.ninenines.eu +>>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>>>> +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> Erlang Cowboy +>>>>> Nine Nines +>>>>> http://ninenines.eu +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From samset at wanadoo.fr Fri Jul 26 18:08:37 2013 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 26 Jul 2013 18:08:37 +0200 +Subject: [99s-extend] query string with # sign +Message-ID: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> + +Hi, + +It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +Is there any way to change this behavior ? + +Thank you. + +Samir + +From essen at ninenines.eu Fri Jul 26 18:11:15 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 26 Jul 2013 18:11:15 +0200 +Subject: [99s-extend] query string with # sign +In-Reply-To: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> +References: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> +Message-ID: <51F29FA3.9020400@ninenines.eu> + +On 07/26/2013 06:08 PM, Samir Sow wrote: +> Hi, +> +> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +> Is there any way to change this behavior ? + +Look for the commit that removed "cowboy_req:fragment/1". + +But be aware that #fragments aren't expected to be sent by an HTTP +request and that browsers don't send it either. You probably should use +the query string for that. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From samset at wanadoo.fr Fri Jul 26 18:25:07 2013 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 26 Jul 2013 18:25:07 +0200 +Subject: [99s-extend] query string with # sign +In-Reply-To: <51F29FA3.9020400@ninenines.eu> +References: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> + <51F29FA3.9020400@ninenines.eu> +Message-ID: + +Thank you Loic + +I'm not http protocol fluent. +Could you explain me what you mean by "you should use the query string for that" ? + +Samir +On 26 juil. 2013, at 18:11, Lo?c Hoguin wrote: + +> On 07/26/2013 06:08 PM, Samir Sow wrote: +>> Hi, +>> +>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +>> Is there any way to change this behavior ? +> +> Look for the commit that removed "cowboy_req:fragment/1". +> +> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Fri Jul 26 18:25:52 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 26 Jul 2013 18:25:52 +0200 +Subject: [99s-extend] query string with # sign +In-Reply-To: +References: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> + <51F29FA3.9020400@ninenines.eu> + +Message-ID: <51F2A310.5030001@ninenines.eu> + +/path/to/resource?f=value + +instead of + +/path/to/resource#value + +On 07/26/2013 06:25 PM, Samir Sow wrote: +> Thank you Loic +> +> I'm not http protocol fluent. +> Could you explain me what you mean by "you should use the query string for that" ? +> +> Samir +> On 26 juil. 2013, at 18:11, Lo?c Hoguin wrote: +> +>> On 07/26/2013 06:08 PM, Samir Sow wrote: +>>> Hi, +>>> +>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +>>> Is there any way to change this behavior ? +>> +>> Look for the commit that removed "cowboy_req:fragment/1". +>> +>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that. +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From samset at wanadoo.fr Fri Jul 26 18:39:02 2013 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 26 Jul 2013 18:39:02 +0200 +Subject: [99s-extend] query string with # sign +In-Reply-To: <51F2A310.5030001@ninenines.eu> +References: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> + <51F29FA3.9020400@ninenines.eu> + + <51F2A310.5030001@ninenines.eu> +Message-ID: <056A51D7-8AD0-45C9-87CF-CC1CC744AE62@wanadoo.fr> + + +Actually my query is something like + +/path?=key=*value, value#&key=value2.... +But in the request i only receive the data before the # (the pound is removed) + + +On 26 juil. 2013, at 18:25, Lo?c Hoguin wrote: + +> /path/to/resource?f=value +> +> instead of +> +> /path/to/resource#value +> +> On 07/26/2013 06:25 PM, Samir Sow wrote: +>> Thank you Loic +>> +>> I'm not http protocol fluent. +>> Could you explain me what you mean by "you should use the query string for that" ? +>> +>> Samir +>> On 26 juil. 2013, at 18:11, Lo?c Hoguin wrote: +>> +>>> On 07/26/2013 06:08 PM, Samir Sow wrote: +>>>> Hi, +>>>> +>>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +>>>> Is there any way to change this behavior ? +>>> +>>> Look for the commit that removed "cowboy_req:fragment/1". +>>> +>>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that. +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + + +From essen at ninenines.eu Fri Jul 26 18:42:41 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 26 Jul 2013 18:42:41 +0200 +Subject: [99s-extend] query string with # sign +In-Reply-To: <056A51D7-8AD0-45C9-87CF-CC1CC744AE62@wanadoo.fr> +References: <5D960DEE-E0EE-4084-AF7D-127E8C9F8B37@wanadoo.fr> + <51F29FA3.9020400@ninenines.eu> + + <51F2A310.5030001@ninenines.eu> + <056A51D7-8AD0-45C9-87CF-CC1CC744AE62@wanadoo.fr> +Message-ID: <51F2A701.1040309@ninenines.eu> + +You have to encode the value (urlencode algorithm), some characters, +like #, have a special meaning. Cowboy will urldecode automatically and +give you the # you expect. + +On 07/26/2013 06:39 PM, Samir Sow wrote: +> +> Actually my query is something like +> +> /path?=key=*value, value#&key=value2.... +> But in the request i only receive the data before the # (the pound is removed) +> +> +> On 26 juil. 2013, at 18:25, Lo?c Hoguin wrote: +> +>> /path/to/resource?f=value +>> +>> instead of +>> +>> /path/to/resource#value +>> +>> On 07/26/2013 06:25 PM, Samir Sow wrote: +>>> Thank you Loic +>>> +>>> I'm not http protocol fluent. +>>> Could you explain me what you mean by "you should use the query string for that" ? +>>> +>>> Samir +>>> On 26 juil. 2013, at 18:11, Lo?c Hoguin wrote: +>>> +>>>> On 07/26/2013 06:08 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler. +>>>>> Is there any way to change this behavior ? +>>>> +>>>> Look for the commit that removed "cowboy_req:fragment/1". +>>>> +>>>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that. +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2013-July/000152.html b/_build/static/archives/extend/2013-July/000152.html new file mode 100644 index 00000000..81e00afd --- /dev/null +++ b/_build/static/archives/extend/2013-July/000152.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Cowboy: http request maximum body size + + + + + + + + + + +

[99s-extend] Cowboy: http request maximum body size

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Tue Jul 9 18:11:50 CEST 2013 +

+
+ +
Dear All
+
+ From the source [1], it looks like the default maximum request body 
+size is 8 million bytes, but this can be set per request, up to 
+infinity.  In the latter case there seems to be no upper limit set by 
+the server at all, and it will keep reading until some external force 
+makes it stop.
+
+That looks handy, if it means I don't have to stipulate a maximum 
+request body size (as long as I make sure the machine cowboy is running 
+on has a sensible amount of memory).
+
+Is that the case?  If not, please correct.
+
+With thanks and best wishes
+
+Ivan
+
+[1] https://github.com/extend/cowboy/blob/master/src/cowboy_req.erl#L720-746
+
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000153.html b/_build/static/archives/extend/2013-July/000153.html new file mode 100644 index 00000000..6041d7cd --- /dev/null +++ b/_build/static/archives/extend/2013-July/000153.html @@ -0,0 +1,113 @@ + + + + [99s-extend] Serve static files with cowboy from some applications + + + + + + + + + + +

[99s-extend] Serve static files with cowboy from some applications

+ Alexander Kuleshov + akuleshov at tpip.net +
+ Wed Jul 17 16:47:43 CEST 2013 +

+
+ +
Hello,
+
+I have a web application which used cowboy (from master). I need to serve some static files, it's usual web application but i can use usual dispatch something like this:
+
+    Dispatch = cowboy_router:compile([
+        {'_', [
+                {<<"/static/v/[...]">>, cowboy_static, [
+                    {etag, {attributes, [filepath, filesize, inode, mtime]}},
+                    {mimetypes, [
+                            {<<".js">> , [<<"application/javascript">>]},
+                            {<<".css">>, [<<"text/css">>]},
+                            {<<".gif">>, [<<"image/gif">>]},
+                            {<<".png">>, [<<"image/png">>]},
+                            {<<".jpg">>, [<<"image/jpeg">>]},
+                            {<<".html">>, [<<"text/html">>]}
+                    ]},
+                    {directory, {priv_dir, my_app, [<<"static">>]}}
+                ]}
+        ]}
+    ])
+
+And i try to explain why. In fact, i have one application (this application) which used cowboy and many plugins for it. Every plugin is an erlang application and also every application has own static files. I need routing something like this:
+
+if path /static/v/my_app/index.html than serve index.html from my_app
+
+if path /static/v/other_app/test.js that serve test.js from other_app.
+
+and etc....
+
+Main goal to change: `my_app` from here: {directory, {priv_dir, my_app, [<<"static">>]} dynamically or write custom static handler.
+
+How to do it correctly with cowboy?
+
+Thank you.
+
+-- 
+Alex Kuleshov
+Software Developer
+
+email: ak at travelping.com
+phone: +77172227194
+mobile: +77019442517
+
+----------------- enabling your networks ---------------------
+Travelping GmbH               phone: +49-391-8190990
+Roentgenstr. 13               fax: +49-391-819099299
+D-39108 Magdeburg             email: info at travelping.com
+GERMANY                       web: http://www.travelping.com
+
+Company Registration: Amtsgericht Stendal Reg No.: HRB 10578
+Geschaeftsfuehrer: Holger Winkelmann | VAT ID No.: DE236673780
+--------------------------------------------------------------
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000154.html b/_build/static/archives/extend/2013-July/000154.html new file mode 100644 index 00000000..bc1ec941 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000154.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Adrian Roe + adrian at id3as.co.uk +
+ Thu Jul 18 12:15:11 CEST 2013 +

+
+ +
We have been using spawn_linked workers to handle tasks that live for the lifetime of a single HTTP request
+
+Although in the cowboy guide it is clear that Cowboy can use "One Process of Many Requests" I am surprised that this is the case even if the handler crashes.  For example, our use case is to copy a large file to the server over HTTP where a worker process relays the file contents to long term storage.  The worker process is spawn_linked from the HTTP handler and (for our use case) should die if the handler stops.
+
+If the client stops the upload (for example by browsing away, or losing connectivity) we correctly receive an error (see sample Lager trace below), but what we are seeing is that spawn_linked processes are NOT being killed.
+
+Is this intended behaviour - I accept it makes sense to reuse the processes but should this continue to be the case even if the previous use of the process crashed?  If it is intended behaviour I think the docs should highlight this as we've been leaking processes for some time now, but I've always seen it as erlang's job to look after related process trees in the event of error.  Our current workaround is to hold a list of linked processes in process storage and then kill them in the terminate handler which is ugly in the extreme!!  We don't know the PIDS of the linked processes until it is too late to return State to Cowboy (i.e. we are already in our handle code)...
+
+Kind regards
+
+Adrian
+
+16:09:32.347 [info] Trailer upload failed with reason {case_clause,{error,closed}}
+16:09:32.348 [error] ** Cowboy handler upload_trailer_resource terminating in handle/2
+   for the reason error:{case_clause,{error,closed}}
+** Handler state was {state,undefined,0,undefined,undefined,undefined}
+** Request was [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+** Stacktrace: [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+
+
+-- 
+Dr Adrian Roe
+Director
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130718/d65f1aaf/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000155.html b/_build/static/archives/extend/2013-July/000155.html new file mode 100644 index 00000000..881c8ddc --- /dev/null +++ b/_build/static/archives/extend/2013-July/000155.html @@ -0,0 +1,102 @@ + + + + [99s-extend] Serve static files with cowboy from some applications + + + + + + + + + + +

[99s-extend] Serve static files with cowboy from some applications

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 18 12:17:13 CEST 2013 +

+
+ +
On 07/17/2013 04:47 PM, Alexander Kuleshov wrote:
+> Hello,
+>
+> I have a web application which used cowboy (from master). I need to serve some static files, it's usual web application but i can use usual dispatch something like this:
+>
+>      Dispatch = cowboy_router:compile([
+>          {'_', [
+>                  {<<"/static/v/[...]">>, cowboy_static, [
+>                      {etag, {attributes, [filepath, filesize, inode, mtime]}},
+>                      {mimetypes, [
+>                              {<<".js">> , [<<"application/javascript">>]},
+>                              {<<".css">>, [<<"text/css">>]},
+>                              {<<".gif">>, [<<"image/gif">>]},
+>                              {<<".png">>, [<<"image/png">>]},
+>                              {<<".jpg">>, [<<"image/jpeg">>]},
+>                              {<<".html">>, [<<"text/html">>]}
+>                      ]},
+>                      {directory, {priv_dir, my_app, [<<"static">>]}}
+>                  ]}
+>          ]}
+>      ])
+>
+> And i try to explain why. In fact, i have one application (this application) which used cowboy and many plugins for it. Every plugin is an erlang application and also every application has own static files. I need routing something like this:
+>
+> if path /static/v/my_app/index.html than serve index.html from my_app
+>
+> if path /static/v/other_app/test.js that serve test.js from other_app.
+>
+> and etc....
+>
+> Main goal to change: `my_app` from here: {directory, {priv_dir, my_app, [<<"static">>]} dynamically or write custom static handler.
+>
+> How to do it correctly with cowboy?
+
+Why don't you add one rule per application?
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000156.html b/_build/static/archives/extend/2013-July/000156.html new file mode 100644 index 00000000..0cf6e7f0 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000156.html @@ -0,0 +1,141 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 18 12:20:36 CEST 2013 +

+
+ +
I don't know what happens but there's two things I know:
+
+  *  Handlers don't trap_exit, so if the linked process crashes, they 
+crash too
+  *  If the handler crashes, we close the connection and stop the 
+handler; if not this is a bug
+
+After your log message the handler should stop unless there's a bug 
+somewhere.
+
+On 07/18/2013 12:15 PM, Adrian Roe wrote:
+> We have been using spawn_linked workers to handle tasks that live for
+> the lifetime of a single HTTP request
+>
+> Although in the cowboy guide it is clear that Cowboy can use "One
+> Process of Many Requests" I am surprised that this is the case even if
+> the handler crashes.  For example, our use case is to copy a large file
+> to the server over HTTP where a worker process relays the file contents
+> to long term storage.  The worker process is spawn_linked from the HTTP
+> handler and (for our use case) should die if the handler stops.
+>
+> If the client stops the upload (for example by browsing away, or losing
+> connectivity) we correctly receive an error (see sample Lager trace
+> below), but what we are seeing is that spawn_linked processes are NOT
+> being killed.
+>
+> Is this intended behaviour - I accept it makes sense to reuse the
+> processes but should this continue to be the case even if the previous
+> use of the process crashed?  If it is intended behaviour I think the
+> docs should highlight this as we've been leaking processes for some time
+> now, but I've always seen it as erlang's job to look after related
+> process trees in the event of error.  Our current workaround is to hold
+> a list of linked processes in process storage and then kill them in the
+> terminate handler which is ugly in the extreme!!  We don't know the PIDS
+> of the linked processes until it is too late to return State to Cowboy
+> (i.e. we are already in our handle code)...
+>
+> Kind regards
+>
+> Adrian
+>
+> 16:09:32.347 [info] Trailer upload failed with reason
+> {case_clause,{error,closed}}
+> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+> terminating in handle/2
+>     for the reason error:{case_clause,{error,closed}}
+> ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+> ** Request was
+> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,
+> like Gecko) Chrome/28.0.1500.71
+> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+> ** Stacktrace:
+> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+>
+>
+> --
+> Dr Adrian Roe
+> Director
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000157.html b/_build/static/archives/extend/2013-July/000157.html new file mode 100644 index 00000000..c6fcd53c --- /dev/null +++ b/_build/static/archives/extend/2013-July/000157.html @@ -0,0 +1,161 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Adrian Roe + adrian at id3as.co.uk +
+ Thu Jul 18 12:31:45 CEST 2013 +

+
+ +
My issue is the other way round.  My handler crashes - and terminate gets called, but the linked process is NOT stopped (unless I stop it in terminate having stashed any processes I need to stop in the process dictionary - this is what I'm currently doing, but yuck!)
+
+.  My question is whether it wouldn't be better to no re-use the handler process that has crashed and replace it so that handler's can use the canonical erlang way of stopping related processes rather than having to do it by hand.    
+
+Obviously if the handler does not crash there's no need to kill the process, so the current efficiency saving works in the "normal" case/  
+
+--  
+Dr Adrian Roe
+Director
+
+
+On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:
+
+> I don't know what happens but there's two things I know:
+>  
+> * Handlers don't trap_exit, so if the linked process crashes, they  
+> crash too
+> * If the handler crashes, we close the connection and stop the  
+> handler; if not this is a bug
+>  
+> After your log message the handler should stop unless there's a bug  
+> somewhere.
+>  
+> On 07/18/2013 12:15 PM, Adrian Roe wrote:
+> > We have been using spawn_linked workers to handle tasks that live for
+> > the lifetime of a single HTTP request
+> >  
+> > Although in the cowboy guide it is clear that Cowboy can use "One
+> > Process of Many Requests" I am surprised that this is the case even if
+> > the handler crashes. For example, our use case is to copy a large file
+> > to the server over HTTP where a worker process relays the file contents
+> > to long term storage. The worker process is spawn_linked from the HTTP
+> > handler and (for our use case) should die if the handler stops.
+> >  
+> > If the client stops the upload (for example by browsing away, or losing
+> > connectivity) we correctly receive an error (see sample Lager trace
+> > below), but what we are seeing is that spawn_linked processes are NOT
+> > being killed.
+> >  
+> > Is this intended behaviour - I accept it makes sense to reuse the
+> > processes but should this continue to be the case even if the previous
+> > use of the process crashed? If it is intended behaviour I think the
+> > docs should highlight this as we've been leaking processes for some time
+> > now, but I've always seen it as erlang's job to look after related
+> > process trees in the event of error. Our current workaround is to hold
+> > a list of linked processes in process storage and then kill them in the
+> > terminate handler which is ugly in the extreme!! We don't know the PIDS
+> > of the linked processes until it is too late to return State to Cowboy
+> > (i.e. we are already in our handle code)...
+> >  
+> > Kind regards
+> >  
+> > Adrian
+> >  
+> > 16:09:32.347 [info] Trailer upload failed with reason
+> > {case_clause,{error,closed}}
+> > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+> > terminating in handle/2
+> > for the reason error:{case_clause,{error,closed}}
+> > ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+> > ** Request was
+> > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+> > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+> > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,
+> > like Gecko) Chrome/28.0.1500.71
+> > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+> > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+> > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+> > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+> > ** Stacktrace:
+> > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+> > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+> > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+> >  
+> >  
+> > --
+> > Dr Adrian Roe
+> > Director
+> >  
+> >  
+> >  
+> > _______________________________________________
+> > Extend mailing list
+> > Extend at lists.ninenines.eu (mailto:Extend at lists.ninenines.eu)
+> > http://lists.ninenines.eu:81/listinfo/extend
+> >  
+>  
+>  
+>  
+> --  
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>  
+>  
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130718/c50bef17/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000158.html b/_build/static/archives/extend/2013-July/000158.html new file mode 100644 index 00000000..41d6dd01 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000158.html @@ -0,0 +1,175 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 18 12:36:04 CEST 2013 +

+
+ +
I don't think the problem is that the handler is reused, we don't reuse 
+them if there's an error. However we do catch errors to print them in 
+the logs, and then the process stops normally. If you link without 
+trap_exit you receive a normal exit signal which is ignored and doesn't 
+kill your process. I suppose we should throw an exit signal when we got 
+an error, after logging everything, instead of stopping normally.
+
+On 07/18/2013 12:31 PM, Adrian Roe wrote:
+> My issue is the other way round.  My handler crashes - and terminate
+> gets called, but the linked process is NOT stopped (unless I stop it in
+> terminate having stashed any processes I need to stop in the process
+> dictionary - this is what I'm currently doing, but yuck!)
+>
+> .  My question is whether it wouldn't be better to no re-use the handler
+> process that has crashed and replace it so that handler's can use the
+> canonical erlang way of stopping related processes rather than having to
+> do it by hand.
+>
+> Obviously if the handler does not crash there's no need to kill the
+> process, so the current efficiency saving works in the "normal" case/
+>
+> --
+> Dr Adrian Roe
+> Director
+>
+> On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:
+>
+>> I don't know what happens but there's two things I know:
+>>
+>> * Handlers don't trap_exit, so if the linked process crashes, they
+>> crash too
+>> * If the handler crashes, we close the connection and stop the
+>> handler; if not this is a bug
+>>
+>> After your log message the handler should stop unless there's a bug
+>> somewhere.
+>>
+>> On 07/18/2013 12:15 PM, Adrian Roe wrote:
+>>> We have been using spawn_linked workers to handle tasks that live for
+>>> the lifetime of a single HTTP request
+>>>
+>>> Although in the cowboy guide it is clear that Cowboy can use "One
+>>> Process of Many Requests" I am surprised that this is the case even if
+>>> the handler crashes. For example, our use case is to copy a large file
+>>> to the server over HTTP where a worker process relays the file contents
+>>> to long term storage. The worker process is spawn_linked from the HTTP
+>>> handler and (for our use case) should die if the handler stops.
+>>>
+>>> If the client stops the upload (for example by browsing away, or losing
+>>> connectivity) we correctly receive an error (see sample Lager trace
+>>> below), but what we are seeing is that spawn_linked processes are NOT
+>>> being killed.
+>>>
+>>> Is this intended behaviour - I accept it makes sense to reuse the
+>>> processes but should this continue to be the case even if the previous
+>>> use of the process crashed? If it is intended behaviour I think the
+>>> docs should highlight this as we've been leaking processes for some time
+>>> now, but I've always seen it as erlang's job to look after related
+>>> process trees in the event of error. Our current workaround is to hold
+>>> a list of linked processes in process storage and then kill them in the
+>>> terminate handler which is ugly in the extreme!! We don't know the PIDS
+>>> of the linked processes until it is too late to return State to Cowboy
+>>> (i.e. we are already in our handle code)...
+>>>
+>>> Kind regards
+>>>
+>>> Adrian
+>>>
+>>> 16:09:32.347 [info] Trailer upload failed with reason
+>>> {case_clause,{error,closed}}
+>>> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+>>> terminating in handle/2
+>>> for the reason error:{case_clause,{error,closed}}
+>>> ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+>>> ** Request was
+>>> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+>>> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+>>> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,
+>>> like Gecko) Chrome/28.0.1500.71
+>>> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+>>> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+>>> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+>>> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+>>> ** Stacktrace:
+>>> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+>>> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+>>> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+>>>
+>>>
+>>> --
+>>> Dr Adrian Roe
+>>> Director
+>>>
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000159.html b/_build/static/archives/extend/2013-July/000159.html new file mode 100644 index 00000000..cf096ef3 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000159.html @@ -0,0 +1,195 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Adrian Roe + adrian at id3as.co.uk +
+ Thu Jul 18 12:37:30 CEST 2013 +

+
+ +
That would be perfect!  Do you want me to make the change and issue a pull request?  
+
+--  
+Dr Adrian Roe
+Director
+
+
+On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:
+
+> I don't think the problem is that the handler is reused, we don't reuse  
+> them if there's an error. However we do catch errors to print them in  
+> the logs, and then the process stops normally. If you link without  
+> trap_exit you receive a normal exit signal which is ignored and doesn't  
+> kill your process. I suppose we should throw an exit signal when we got  
+> an error, after logging everything, instead of stopping normally.
+>  
+> On 07/18/2013 12:31 PM, Adrian Roe wrote:
+> > My issue is the other way round. My handler crashes - and terminate
+> > gets called, but the linked process is NOT stopped (unless I stop it in
+> > terminate having stashed any processes I need to stop in the process
+> > dictionary - this is what I'm currently doing, but yuck!)
+> >  
+> > . My question is whether it wouldn't be better to no re-use the handler
+> > process that has crashed and replace it so that handler's can use the
+> > canonical erlang way of stopping related processes rather than having to
+> > do it by hand.
+> >  
+> > Obviously if the handler does not crash there's no need to kill the
+> > process, so the current efficiency saving works in the "normal" case/
+> >  
+> > --
+> > Dr Adrian Roe
+> > Director
+> >  
+> > On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:
+> >  
+> > > I don't know what happens but there's two things I know:
+> > >  
+> > > * Handlers don't trap_exit, so if the linked process crashes, they
+> > > crash too
+> > > * If the handler crashes, we close the connection and stop the
+> > > handler; if not this is a bug
+> > >  
+> > > After your log message the handler should stop unless there's a bug
+> > > somewhere.
+> > >  
+> > > On 07/18/2013 12:15 PM, Adrian Roe wrote:
+> > > > We have been using spawn_linked workers to handle tasks that live for
+> > > > the lifetime of a single HTTP request
+> > > >  
+> > > > Although in the cowboy guide it is clear that Cowboy can use "One
+> > > > Process of Many Requests" I am surprised that this is the case even if
+> > > > the handler crashes. For example, our use case is to copy a large file
+> > > > to the server over HTTP where a worker process relays the file contents
+> > > > to long term storage. The worker process is spawn_linked from the HTTP
+> > > > handler and (for our use case) should die if the handler stops.
+> > > >  
+> > > > If the client stops the upload (for example by browsing away, or losing
+> > > > connectivity) we correctly receive an error (see sample Lager trace
+> > > > below), but what we are seeing is that spawn_linked processes are NOT
+> > > > being killed.
+> > > >  
+> > > > Is this intended behaviour - I accept it makes sense to reuse the
+> > > > processes but should this continue to be the case even if the previous
+> > > > use of the process crashed? If it is intended behaviour I think the
+> > > > docs should highlight this as we've been leaking processes for some time
+> > > > now, but I've always seen it as erlang's job to look after related
+> > > > process trees in the event of error. Our current workaround is to hold
+> > > > a list of linked processes in process storage and then kill them in the
+> > > > terminate handler which is ugly in the extreme!! We don't know the PIDS
+> > > > of the linked processes until it is too late to return State to Cowboy
+> > > > (i.e. we are already in our handle code)...
+> > > >  
+> > > > Kind regards
+> > > >  
+> > > > Adrian
+> > > >  
+> > > > 16:09:32.347 [info] Trailer upload failed with reason
+> > > > {case_clause,{error,closed}}
+> > > > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+> > > > terminating in handle/2
+> > > > for the reason error:{case_clause,{error,closed}}
+> > > > ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+> > > > ** Request was
+> > > > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+> > > > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+> > > > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,
+> > > > like Gecko) Chrome/28.0.1500.71
+> > > > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+> > > > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+> > > > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+> > > > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+> > > > ** Stacktrace:
+> > > > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+> > > > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+> > > > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+> > > >  
+> > > >  
+> > > > --
+> > > > Dr Adrian Roe
+> > > > Director
+> > > >  
+> > > >  
+> > > >  
+> > > > _______________________________________________
+> > > > Extend mailing list
+> > > > Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+> > > > http://lists.ninenines.eu:81/listinfo/extend
+> > > >  
+> > >  
+> > >  
+> > >  
+> > > --
+> > > Loïc Hoguin
+> > > Erlang Cowboy
+> > > Nine Nines
+> > > http://ninenines.eu
+> > >  
+> >  
+> >  
+>  
+>  
+>  
+> --  
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>  
+>  
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130718/79e075b8/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000160.html b/_build/static/archives/extend/2013-July/000160.html new file mode 100644 index 00000000..695cdbcc --- /dev/null +++ b/_build/static/archives/extend/2013-July/000160.html @@ -0,0 +1,196 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 18 12:38:13 CEST 2013 +

+
+ +
If you got time sure, I won't have much time until Monday. Have fun!
+
+On 07/18/2013 12:37 PM, Adrian Roe wrote:
+> That would be perfect!  Do you want me to make the change and issue a
+> pull request?
+>
+> --
+> Dr Adrian Roe
+> Director
+>
+> On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:
+>
+>> I don't think the problem is that the handler is reused, we don't reuse
+>> them if there's an error. However we do catch errors to print them in
+>> the logs, and then the process stops normally. If you link without
+>> trap_exit you receive a normal exit signal which is ignored and doesn't
+>> kill your process. I suppose we should throw an exit signal when we got
+>> an error, after logging everything, instead of stopping normally.
+>>
+>> On 07/18/2013 12:31 PM, Adrian Roe wrote:
+>>> My issue is the other way round. My handler crashes - and terminate
+>>> gets called, but the linked process is NOT stopped (unless I stop it in
+>>> terminate having stashed any processes I need to stop in the process
+>>> dictionary - this is what I'm currently doing, but yuck!)
+>>>
+>>> . My question is whether it wouldn't be better to no re-use the handler
+>>> process that has crashed and replace it so that handler's can use the
+>>> canonical erlang way of stopping related processes rather than having to
+>>> do it by hand.
+>>>
+>>> Obviously if the handler does not crash there's no need to kill the
+>>> process, so the current efficiency saving works in the "normal" case/
+>>>
+>>> --
+>>> Dr Adrian Roe
+>>> Director
+>>>
+>>> On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:
+>>>
+>>>> I don't know what happens but there's two things I know:
+>>>>
+>>>> * Handlers don't trap_exit, so if the linked process crashes, they
+>>>> crash too
+>>>> * If the handler crashes, we close the connection and stop the
+>>>> handler; if not this is a bug
+>>>>
+>>>> After your log message the handler should stop unless there's a bug
+>>>> somewhere.
+>>>>
+>>>> On 07/18/2013 12:15 PM, Adrian Roe wrote:
+>>>>> We have been using spawn_linked workers to handle tasks that live for
+>>>>> the lifetime of a single HTTP request
+>>>>>
+>>>>> Although in the cowboy guide it is clear that Cowboy can use "One
+>>>>> Process of Many Requests" I am surprised that this is the case even if
+>>>>> the handler crashes. For example, our use case is to copy a large file
+>>>>> to the server over HTTP where a worker process relays the file contents
+>>>>> to long term storage. The worker process is spawn_linked from the HTTP
+>>>>> handler and (for our use case) should die if the handler stops.
+>>>>>
+>>>>> If the client stops the upload (for example by browsing away, or losing
+>>>>> connectivity) we correctly receive an error (see sample Lager trace
+>>>>> below), but what we are seeing is that spawn_linked processes are NOT
+>>>>> being killed.
+>>>>>
+>>>>> Is this intended behaviour - I accept it makes sense to reuse the
+>>>>> processes but should this continue to be the case even if the previous
+>>>>> use of the process crashed? If it is intended behaviour I think the
+>>>>> docs should highlight this as we've been leaking processes for some
+>>>>> time
+>>>>> now, but I've always seen it as erlang's job to look after related
+>>>>> process trees in the event of error. Our current workaround is to hold
+>>>>> a list of linked processes in process storage and then kill them in the
+>>>>> terminate handler which is ugly in the extreme!! We don't know the PIDS
+>>>>> of the linked processes until it is too late to return State to Cowboy
+>>>>> (i.e. we are already in our handle code)...
+>>>>>
+>>>>> Kind regards
+>>>>>
+>>>>> Adrian
+>>>>>
+>>>>> 16:09:32.347 [info] Trailer upload failed with reason
+>>>>> {case_clause,{error,closed}}
+>>>>> 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+>>>>> terminating in handle/2
+>>>>> for the reason error:{case_clause,{error,closed}}
+>>>>> ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+>>>>> ** Request was
+>>>>> [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+>>>>> ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+>>>>> ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36
+>>>>> (KHTML,
+>>>>> like Gecko) Chrome/28.0.1500.71
+>>>>> Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+>>>>> pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+>>>>> id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+>>>>> fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+>>>>> ** Stacktrace:
+>>>>> [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+>>>>> ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+>>>>> ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+>>>>>
+>>>>>
+>>>>> --
+>>>>> Dr Adrian Roe
+>>>>> Director
+>>>>>
+>>>>>
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000161.html b/_build/static/archives/extend/2013-July/000161.html new file mode 100644 index 00000000..1ed557be --- /dev/null +++ b/_build/static/archives/extend/2013-July/000161.html @@ -0,0 +1,224 @@ + + + + [99s-extend] Cowboy handler linked processes + + + + + + + + + + +

[99s-extend] Cowboy handler linked processes

+ Adrian Roe + adrian at id3as.co.uk +
+ Thu Jul 18 19:55:20 CEST 2013 +

+
+ +
I suspect it's just a case of adding a throw to error_terminate in cowboy_protocol, maybe with threading the reason back (though I don't really care what's thrown), but also fear there may be unintended consequences as all I've done is skim your code briefly!  If you are able to look at it then great - if not I'll muddle through.  I'm travelling so it would be mid next week at the earliest anyway.  
+
+Cheers
+
+Adrian  
+
+--  
+Dr Adrian Roe
+Director
+
+
+On Thursday, 18 July 2013 at 11:38, Loïc Hoguin wrote:
+
+> If you got time sure, I won't have much time until Monday. Have fun!
+>  
+> On 07/18/2013 12:37 PM, Adrian Roe wrote:
+> > That would be perfect! Do you want me to make the change and issue a
+> > pull request?
+> >  
+> > --
+> > Dr Adrian Roe
+> > Director
+> >  
+> > On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:
+> >  
+> > > I don't think the problem is that the handler is reused, we don't reuse
+> > > them if there's an error. However we do catch errors to print them in
+> > > the logs, and then the process stops normally. If you link without
+> > > trap_exit you receive a normal exit signal which is ignored and doesn't
+> > > kill your process. I suppose we should throw an exit signal when we got
+> > > an error, after logging everything, instead of stopping normally.
+> > >  
+> > > On 07/18/2013 12:31 PM, Adrian Roe wrote:
+> > > > My issue is the other way round. My handler crashes - and terminate
+> > > > gets called, but the linked process is NOT stopped (unless I stop it in
+> > > > terminate having stashed any processes I need to stop in the process
+> > > > dictionary - this is what I'm currently doing, but yuck!)
+> > > >  
+> > > > . My question is whether it wouldn't be better to no re-use the handler
+> > > > process that has crashed and replace it so that handler's can use the
+> > > > canonical erlang way of stopping related processes rather than having to
+> > > > do it by hand.
+> > > >  
+> > > > Obviously if the handler does not crash there's no need to kill the
+> > > > process, so the current efficiency saving works in the "normal" case/
+> > > >  
+> > > > --
+> > > > Dr Adrian Roe
+> > > > Director
+> > > >  
+> > > > On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:
+> > > >  
+> > > > > I don't know what happens but there's two things I know:
+> > > > >  
+> > > > > * Handlers don't trap_exit, so if the linked process crashes, they
+> > > > > crash too
+> > > > > * If the handler crashes, we close the connection and stop the
+> > > > > handler; if not this is a bug
+> > > > >  
+> > > > > After your log message the handler should stop unless there's a bug
+> > > > > somewhere.
+> > > > >  
+> > > > > On 07/18/2013 12:15 PM, Adrian Roe wrote:
+> > > > > > We have been using spawn_linked workers to handle tasks that live for
+> > > > > > the lifetime of a single HTTP request
+> > > > > >  
+> > > > > > Although in the cowboy guide it is clear that Cowboy can use "One
+> > > > > > Process of Many Requests" I am surprised that this is the case even if
+> > > > > > the handler crashes. For example, our use case is to copy a large file
+> > > > > > to the server over HTTP where a worker process relays the file contents
+> > > > > > to long term storage. The worker process is spawn_linked from the HTTP
+> > > > > > handler and (for our use case) should die if the handler stops.
+> > > > > >  
+> > > > > > If the client stops the upload (for example by browsing away, or losing
+> > > > > > connectivity) we correctly receive an error (see sample Lager trace
+> > > > > > below), but what we are seeing is that spawn_linked processes are NOT
+> > > > > > being killed.
+> > > > > >  
+> > > > > > Is this intended behaviour - I accept it makes sense to reuse the
+> > > > > > processes but should this continue to be the case even if the previous
+> > > > > > use of the process crashed? If it is intended behaviour I think the
+> > > > > > docs should highlight this as we've been leaking processes for some
+> > > > > > time
+> > > > > > now, but I've always seen it as erlang's job to look after related
+> > > > > > process trees in the event of error. Our current workaround is to hold
+> > > > > > a list of linked processes in process storage and then kill them in the
+> > > > > > terminate handler which is ugly in the extreme!! We don't know the PIDS
+> > > > > > of the linked processes until it is too late to return State to Cowboy
+> > > > > > (i.e. we are already in our handle code)...
+> > > > > >  
+> > > > > > Kind regards
+> > > > > >  
+> > > > > > Adrian
+> > > > > >  
+> > > > > > 16:09:32.347 [info] Trailer upload failed with reason
+> > > > > > {case_clause,{error,closed}}
+> > > > > > 16:09:32.348 [error] ** Cowboy handler upload_trailer_resource
+> > > > > > terminating in handle/2
+> > > > > > for the reason error:{case_clause,{error,closed}}
+> > > > > > ** Handler state was {state,undefined,0,undefined,undefined,undefined}
+> > > > > > ** Request was
+> > > > > > [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef
+> > > > > > ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M
+> > > > > > ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36
+> > > > > > (KHTML,
+> > > > > > like Gecko) Chrome/28.0.1500.71
+> > > > > > Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce
+> > > > > > pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;
+> > > > > > id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde
+> > > > > > fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]
+> > > > > > ** Stacktrace:
+> > > > > > [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}
+> > > > > > ,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo
+> > > > > > ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]
+> > > > > >  
+> > > > > >  
+> > > > > > --
+> > > > > > Dr Adrian Roe
+> > > > > > Director
+> > > > > >  
+> > > > > >  
+> > > > > >  
+> > > > > > _______________________________________________
+> > > > > > Extend mailing list
+> > > > > > Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+> > > > > > http://lists.ninenines.eu:81/listinfo/extend
+> > > > > >  
+> > > > >  
+> > > > >  
+> > > > >  
+> > > > > --
+> > > > > Loïc Hoguin
+> > > > > Erlang Cowboy
+> > > > > Nine Nines
+> > > > > http://ninenines.eu
+> > > > >  
+> > > >  
+> > > >  
+> > >  
+> > >  
+> > >  
+> > > --
+> > > Loïc Hoguin
+> > > Erlang Cowboy
+> > > Nine Nines
+> > > http://ninenines.eu
+> > >  
+> >  
+> >  
+>  
+>  
+>  
+> --  
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>  
+>  
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130718/a3961a6f/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000162.html b/_build/static/archives/extend/2013-July/000162.html new file mode 100644 index 00000000..45870ad9 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000162.html @@ -0,0 +1,103 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Tue Jul 23 15:12:08 CEST 2013 +

+
+ +
Hi guys,
+
+So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+
+application: ssl
+    exited: {bad_return,
+                {{ssl_app,start,[normal,[]]},
+                 {'EXIT',
+                     {undef,
+                         [{ssl_app,start,[normal,[]],[]},
+                          {application_master,start_it_old,4,
+                              [{file,"application_master.erl"},
+                               {line,274}]}]}}}}
+    type: temporary
+
+
+The way I'm starting Cowboy is like this:
+
+	Env = [
+		{env, [{dispatch, Dispatch}]},
+		{onrequest, fun http_utils:set_request_cors/1}
+	],
+
+	case http_server:is_secure() of
+		true ->
+			cowboy:start_https(https, 100, [
+				{ip, Ip}, {port, Port},
+				{certfile, binary_to_list(http_server:secure_cert())},
+				{keyfile, binary_to_list(http_server:secure_key())},
+				{reuseaddr, true},
+				{fail_if_no_peer_cert, true}
+			], Env);
+		_ ->
+			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+	end,
+
+Does anyone know why I might be getting this issue?
+
+Thanks,
+Lee
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000163.html b/_build/static/archives/extend/2013-July/000163.html new file mode 100644 index 00000000..188507a8 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000163.html @@ -0,0 +1,118 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jul 23 15:41:42 CEST 2013 +

+
+ +
You need to include and start the public_key and ssl applications.
+
+On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+> Hi guys,
+>
+> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+>
+> application: ssl
+>      exited: {bad_return,
+>                  {{ssl_app,start,[normal,[]]},
+>                   {'EXIT',
+>                       {undef,
+>                           [{ssl_app,start,[normal,[]],[]},
+>                            {application_master,start_it_old,4,
+>                                [{file,"application_master.erl"},
+>                                 {line,274}]}]}}}}
+>      type: temporary
+>
+>
+> The way I'm starting Cowboy is like this:
+>
+> 	Env = [
+> 		{env, [{dispatch, Dispatch}]},
+> 		{onrequest, fun http_utils:set_request_cors/1}
+> 	],
+>
+> 	case http_server:is_secure() of
+> 		true ->
+> 			cowboy:start_https(https, 100, [
+> 				{ip, Ip}, {port, Port},
+> 				{certfile, binary_to_list(http_server:secure_cert())},
+> 				{keyfile, binary_to_list(http_server:secure_key())},
+> 				{reuseaddr, true},
+> 				{fail_if_no_peer_cert, true}
+> 			], Env);
+> 		_ ->
+> 			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+> 	end,
+>
+> Does anyone know why I might be getting this issue?
+>
+> Thanks,
+> Lee
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000164.html b/_build/static/archives/extend/2013-July/000164.html new file mode 100644 index 00000000..6e053e04 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000164.html @@ -0,0 +1,142 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Tue Jul 23 15:59:00 CEST 2013 +

+
+ +
Thank you, Loic.  I'd forgotten to update my releases folder.
+
+I now have it running, but when I access an endpoint, I get
+
+=ERROR REPORT==== 23-Jul-2013::09:56:29 ===
+SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33,
+                    126,49,13,  [snip]  45,193>>,
+                  <<48,130,6  [snip]  118,247,97>>] /usr/certs/cert.pem
+  [{ssl_connection,init_certificates,8,
+                   [{file,"ssl_connection.erl"},{line,1155}]},
+   {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]},
+   {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]},
+   {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
+
+Not a very helpful error.  I'm assuming the cert isn't being accepted by the SSL module?
+
+Thanks,
+Lee
+
+
+
+On 23 Jul 2013, at 14:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> You need to include and start the public_key and ssl applications.
+> 
+> On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+>> Hi guys,
+>> 
+>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+>> 
+>> application: ssl
+>>     exited: {bad_return,
+>>                 {{ssl_app,start,[normal,[]]},
+>>                  {'EXIT',
+>>                      {undef,
+>>                          [{ssl_app,start,[normal,[]],[]},
+>>                           {application_master,start_it_old,4,
+>>                               [{file,"application_master.erl"},
+>>                                {line,274}]}]}}}}
+>>     type: temporary
+>> 
+>> 
+>> The way I'm starting Cowboy is like this:
+>> 
+>> 	Env = [
+>> 		{env, [{dispatch, Dispatch}]},
+>> 		{onrequest, fun http_utils:set_request_cors/1}
+>> 	],
+>> 
+>> 	case http_server:is_secure() of
+>> 		true ->
+>> 			cowboy:start_https(https, 100, [
+>> 				{ip, Ip}, {port, Port},
+>> 				{certfile, binary_to_list(http_server:secure_cert())},
+>> 				{keyfile, binary_to_list(http_server:secure_key())},
+>> 				{reuseaddr, true},
+>> 				{fail_if_no_peer_cert, true}
+>> 			], Env);
+>> 		_ ->
+>> 			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+>> 	end,
+>> 
+>> Does anyone know why I might be getting this issue?
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000165.html b/_build/static/archives/extend/2013-July/000165.html new file mode 100644 index 00000000..7466d83e --- /dev/null +++ b/_build/static/archives/extend/2013-July/000165.html @@ -0,0 +1,153 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jul 23 16:00:13 CEST 2013 +

+
+ +
No idea. You'll probably have more luck asking erlang-questions for SSL 
+issues.
+
+On 07/23/2013 03:59 PM, Lee Sylvester wrote:
+> Thank you, Loic.  I'd forgotten to update my releases folder.
+>
+> I now have it running, but when I access an endpoint, I get
+>
+> =ERROR REPORT==== 23-Jul-2013::09:56:29 ===
+> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33,
+>                      126,49,13,  [snip]  45,193>>,
+>                    <<48,130,6  [snip]  118,247,97>>] /usr/certs/cert.pem
+>    [{ssl_connection,init_certificates,8,
+>                     [{file,"ssl_connection.erl"},{line,1155}]},
+>     {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]},
+>     {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]},
+>     {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
+>
+> Not a very helpful error.  I'm assuming the cert isn't being accepted by the SSL module?
+>
+> Thanks,
+> Lee
+>
+>
+>
+> On 23 Jul 2013, at 14:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> You need to include and start the public_key and ssl applications.
+>>
+>> On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+>>> Hi guys,
+>>>
+>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+>>>
+>>> application: ssl
+>>>      exited: {bad_return,
+>>>                  {{ssl_app,start,[normal,[]]},
+>>>                   {'EXIT',
+>>>                       {undef,
+>>>                           [{ssl_app,start,[normal,[]],[]},
+>>>                            {application_master,start_it_old,4,
+>>>                                [{file,"application_master.erl"},
+>>>                                 {line,274}]}]}}}}
+>>>      type: temporary
+>>>
+>>>
+>>> The way I'm starting Cowboy is like this:
+>>>
+>>> 	Env = [
+>>> 		{env, [{dispatch, Dispatch}]},
+>>> 		{onrequest, fun http_utils:set_request_cors/1}
+>>> 	],
+>>>
+>>> 	case http_server:is_secure() of
+>>> 		true ->
+>>> 			cowboy:start_https(https, 100, [
+>>> 				{ip, Ip}, {port, Port},
+>>> 				{certfile, binary_to_list(http_server:secure_cert())},
+>>> 				{keyfile, binary_to_list(http_server:secure_key())},
+>>> 				{reuseaddr, true},
+>>> 				{fail_if_no_peer_cert, true}
+>>> 			], Env);
+>>> 		_ ->
+>>> 			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+>>> 	end,
+>>>
+>>> Does anyone know why I might be getting this issue?
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000166.html b/_build/static/archives/extend/2013-July/000166.html new file mode 100644 index 00000000..67d1185c --- /dev/null +++ b/_build/static/archives/extend/2013-July/000166.html @@ -0,0 +1,162 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Tue Jul 23 16:01:07 CEST 2013 +

+
+ +
Okay, thanks Loïc.  I'll try my luck there :-)
+
+Regards,
+Lee
+
+
+
+On 23 Jul 2013, at 15:00, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> No idea. You'll probably have more luck asking erlang-questions for SSL issues.
+> 
+> On 07/23/2013 03:59 PM, Lee Sylvester wrote:
+>> Thank you, Loic.  I'd forgotten to update my releases folder.
+>> 
+>> I now have it running, but when I access an endpoint, I get
+>> 
+>> =ERROR REPORT==== 23-Jul-2013::09:56:29 ===
+>> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33,
+>>                     126,49,13,  [snip]  45,193>>,
+>>                   <<48,130,6  [snip]  118,247,97>>] /usr/certs/cert.pem
+>>   [{ssl_connection,init_certificates,8,
+>>                    [{file,"ssl_connection.erl"},{line,1155}]},
+>>    {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]},
+>>    {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]},
+>>    {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
+>> 
+>> Not a very helpful error.  I'm assuming the cert isn't being accepted by the SSL module?
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> 
+>> On 23 Jul 2013, at 14:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> 
+>>> You need to include and start the public_key and ssl applications.
+>>> 
+>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+>>>> Hi guys,
+>>>> 
+>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+>>>> 
+>>>> application: ssl
+>>>>     exited: {bad_return,
+>>>>                 {{ssl_app,start,[normal,[]]},
+>>>>                  {'EXIT',
+>>>>                      {undef,
+>>>>                          [{ssl_app,start,[normal,[]],[]},
+>>>>                           {application_master,start_it_old,4,
+>>>>                               [{file,"application_master.erl"},
+>>>>                                {line,274}]}]}}}}
+>>>>     type: temporary
+>>>> 
+>>>> 
+>>>> The way I'm starting Cowboy is like this:
+>>>> 
+>>>> 	Env = [
+>>>> 		{env, [{dispatch, Dispatch}]},
+>>>> 		{onrequest, fun http_utils:set_request_cors/1}
+>>>> 	],
+>>>> 
+>>>> 	case http_server:is_secure() of
+>>>> 		true ->
+>>>> 			cowboy:start_https(https, 100, [
+>>>> 				{ip, Ip}, {port, Port},
+>>>> 				{certfile, binary_to_list(http_server:secure_cert())},
+>>>> 				{keyfile, binary_to_list(http_server:secure_key())},
+>>>> 				{reuseaddr, true},
+>>>> 				{fail_if_no_peer_cert, true}
+>>>> 			], Env);
+>>>> 		_ ->
+>>>> 			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+>>>> 	end,
+>>>> 
+>>>> Does anyone know why I might be getting this issue?
+>>>> 
+>>>> Thanks,
+>>>> Lee
+>>>> 
+>>>> 
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>> 
+>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000167.html b/_build/static/archives/extend/2013-July/000167.html new file mode 100644 index 00000000..31b21867 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000167.html @@ -0,0 +1,70 @@ + + + + [99s-extend] OPTIONS and is_authorized + + + + + + + + + + +

[99s-extend] OPTIONS and is_authorized

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Tue Jul 23 16:15:36 CEST 2013 +

+
+ +
What's the best way to skip is_authorized callback for OPTIONS methods? For
+all my rest handlers?
+
+Thanks in advance for any help you are able to provide.
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130723/3e51c337/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000168.html b/_build/static/archives/extend/2013-July/000168.html new file mode 100644 index 00000000..2190fec8 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000168.html @@ -0,0 +1,173 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Grzegorz Junka + list1 at gjunka.com +
+ Thu Jul 25 11:24:24 CEST 2013 +

+
+ +
Maybe the problem is with Erlang not seeing the crypto libraries? You 
+can verify that quickly by executing "crypto:start()." in the Erlang 
+shell. See this post for info:
+
+http://stackoverflow.com/questions/4742184/rebar-error-exit-on-create-app-crypto-start/14776521#14776521
+
+Greg
+
+On 23/07/2013 15:01, Lee Sylvester wrote:
+> Okay, thanks Loïc.  I'll try my luck there :-)
+>
+> Regards,
+> Lee
+>
+>
+>
+> On 23 Jul 2013, at 15:00, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> No idea. You'll probably have more luck asking erlang-questions for SSL issues.
+>>
+>> On 07/23/2013 03:59 PM, Lee Sylvester wrote:
+>>> Thank you, Loic.  I'd forgotten to update my releases folder.
+>>>
+>>> I now have it running, but when I access an endpoint, I get
+>>>
+>>> =ERROR REPORT==== 23-Jul-2013::09:56:29 ===
+>>> SSL: 1159: error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33,
+>>>                      126,49,13,  [snip]  45,193>>,
+>>>                    <<48,130,6  [snip]  118,247,97>>] /usr/certs/cert.pem
+>>>    [{ssl_connection,init_certificates,8,
+>>>                     [{file,"ssl_connection.erl"},{line,1155}]},
+>>>     {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]},
+>>>     {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]},
+>>>     {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
+>>>
+>>> Not a very helpful error.  I'm assuming the cert isn't being accepted by the SSL module?
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>>
+>>>
+>>> On 23 Jul 2013, at 14:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>>> You need to include and start the public_key and ssl applications.
+>>>>
+>>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+>>>>> Hi guys,
+>>>>>
+>>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error with the SSL module:
+>>>>>
+>>>>> application: ssl
+>>>>>      exited: {bad_return,
+>>>>>                  {{ssl_app,start,[normal,[]]},
+>>>>>                   {'EXIT',
+>>>>>                       {undef,
+>>>>>                           [{ssl_app,start,[normal,[]],[]},
+>>>>>                            {application_master,start_it_old,4,
+>>>>>                                [{file,"application_master.erl"},
+>>>>>                                 {line,274}]}]}}}}
+>>>>>      type: temporary
+>>>>>
+>>>>>
+>>>>> The way I'm starting Cowboy is like this:
+>>>>>
+>>>>> 	Env = [
+>>>>> 		{env, [{dispatch, Dispatch}]},
+>>>>> 		{onrequest, fun http_utils:set_request_cors/1}
+>>>>> 	],
+>>>>>
+>>>>> 	case http_server:is_secure() of
+>>>>> 		true ->
+>>>>> 			cowboy:start_https(https, 100, [
+>>>>> 				{ip, Ip}, {port, Port},
+>>>>> 				{certfile, binary_to_list(http_server:secure_cert())},
+>>>>> 				{keyfile, binary_to_list(http_server:secure_key())},
+>>>>> 				{reuseaddr, true},
+>>>>> 				{fail_if_no_peer_cert, true}
+>>>>> 			], Env);
+>>>>> 		_ ->
+>>>>> 			{ok, _} = cowboy:start_http(http, 100, Options, Env)
+>>>>> 	end,
+>>>>>
+>>>>> Does anyone know why I might be getting this issue?
+>>>>>
+>>>>> Thanks,
+>>>>> Lee
+>>>>>
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>
+>> -- 
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000169.html b/_build/static/archives/extend/2013-July/000169.html new file mode 100644 index 00000000..4e28c3d1 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000169.html @@ -0,0 +1,195 @@ + + + + [99s-extend] Cowboy HTTPS Issue + + + + + + + + + + +

[99s-extend] Cowboy HTTPS Issue

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 25 11:25:02 CEST 2013 +

+
+ +
Cowboy requires crypto to start.
+
+On 07/25/2013 11:24 AM, Grzegorz Junka wrote:
+> Maybe the problem is with Erlang not seeing the crypto libraries? You
+> can verify that quickly by executing "crypto:start()." in the Erlang
+> shell. See this post for info:
+>
+> http://stackoverflow.com/questions/4742184/rebar-error-exit-on-create-app-crypto-start/14776521#14776521
+>
+>
+> Greg
+>
+> On 23/07/2013 15:01, Lee Sylvester wrote:
+>> Okay, thanks Loïc.  I'll try my luck there :-)
+>>
+>> Regards,
+>> Lee
+>>
+>>
+>>
+>> On 23 Jul 2013, at 15:00, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>>> No idea. You'll probably have more luck asking erlang-questions for
+>>> SSL issues.
+>>>
+>>> On 07/23/2013 03:59 PM, Lee Sylvester wrote:
+>>>> Thank you, Loic.  I'd forgotten to update my releases folder.
+>>>>
+>>>> I now have it running, but when I access an endpoint, I get
+>>>>
+>>>> =ERROR REPORT==== 23-Jul-2013::09:56:29 ===
+>>>> SSL: 1159:
+>>>> error:[<<48,130,6,220,48,130,5,196,160,3,2,1,2,2,16,15,199,72,40,33,
+>>>>                      126,49,13,  [snip]  45,193>>,
+>>>>                    <<48,130,6  [snip]  118,247,97>>]
+>>>> /usr/certs/cert.pem
+>>>>    [{ssl_connection,init_certificates,8,
+>>>>                     [{file,"ssl_connection.erl"},{line,1155}]},
+>>>>
+>>>> {ssl_connection,ssl_init,2,[{file,"ssl_connection.erl"},{line,1110}]},
+>>>>     {ssl_connection,init,1,[{file,"ssl_connection.erl"},{line,303}]},
+>>>>     {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,239}]}]
+>>>>
+>>>> Not a very helpful error.  I'm assuming the cert isn't being
+>>>> accepted by the SSL module?
+>>>>
+>>>> Thanks,
+>>>> Lee
+>>>>
+>>>>
+>>>>
+>>>> On 23 Jul 2013, at 14:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>
+>>>>> You need to include and start the public_key and ssl applications.
+>>>>>
+>>>>> On 07/23/2013 03:12 PM, Lee Sylvester wrote:
+>>>>>> Hi guys,
+>>>>>>
+>>>>>> So, I'm trying to run Cowboy with SSL, but keep getting an error
+>>>>>> with the SSL module:
+>>>>>>
+>>>>>> application: ssl
+>>>>>>      exited: {bad_return,
+>>>>>>                  {{ssl_app,start,[normal,[]]},
+>>>>>>                   {'EXIT',
+>>>>>>                       {undef,
+>>>>>>                           [{ssl_app,start,[normal,[]],[]},
+>>>>>>                            {application_master,start_it_old,4,
+>>>>>>                                [{file,"application_master.erl"},
+>>>>>>                                 {line,274}]}]}}}}
+>>>>>>      type: temporary
+>>>>>>
+>>>>>>
+>>>>>> The way I'm starting Cowboy is like this:
+>>>>>>
+>>>>>>     Env = [
+>>>>>>         {env, [{dispatch, Dispatch}]},
+>>>>>>         {onrequest, fun http_utils:set_request_cors/1}
+>>>>>>     ],
+>>>>>>
+>>>>>>     case http_server:is_secure() of
+>>>>>>         true ->
+>>>>>>             cowboy:start_https(https, 100, [
+>>>>>>                 {ip, Ip}, {port, Port},
+>>>>>>                 {certfile,
+>>>>>> binary_to_list(http_server:secure_cert())},
+>>>>>>                 {keyfile, binary_to_list(http_server:secure_key())},
+>>>>>>                 {reuseaddr, true},
+>>>>>>                 {fail_if_no_peer_cert, true}
+>>>>>>             ], Env);
+>>>>>>         _ ->
+>>>>>>             {ok, _} = cowboy:start_http(http, 100, Options, Env)
+>>>>>>     end,
+>>>>>>
+>>>>>> Does anyone know why I might be getting this issue?
+>>>>>>
+>>>>>> Thanks,
+>>>>>> Lee
+>>>>>>
+>>>>>>
+>>>>>> _______________________________________________
+>>>>>> Extend mailing list
+>>>>>> Extend at lists.ninenines.eu
+>>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>>>
+>>>>>
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> Erlang Cowboy
+>>>>> Nine Nines
+>>>>> http://ninenines.eu
+>>>
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000170.html b/_build/static/archives/extend/2013-July/000170.html new file mode 100644 index 00000000..734498fb --- /dev/null +++ b/_build/static/archives/extend/2013-July/000170.html @@ -0,0 +1,68 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Samir Sow + samset at wanadoo.fr +
+ Fri Jul 26 18:08:37 CEST 2013 +

+
+ +
Hi, 
+
+It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+Is there any way to change this behavior ?
+
+Thank you.
+
+Samir
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000171.html b/_build/static/archives/extend/2013-July/000171.html new file mode 100644 index 00000000..c82d0880 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000171.html @@ -0,0 +1,78 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Jul 26 18:11:15 CEST 2013 +

+
+ +
On 07/26/2013 06:08 PM, Samir Sow wrote:
+> Hi,
+>
+> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+> Is there any way to change this behavior ?
+
+Look for the commit that removed "cowboy_req:fragment/1".
+
+But be aware that #fragments aren't expected to be sent by an HTTP 
+request and that browsers don't send it either. You probably should use 
+the query string for that.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000172.html b/_build/static/archives/extend/2013-July/000172.html new file mode 100644 index 00000000..04e7bce7 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000172.html @@ -0,0 +1,85 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Samir Sow + samset at wanadoo.fr +
+ Fri Jul 26 18:25:07 CEST 2013 +

+
+ +
Thank you Loic
+
+I'm not http protocol fluent.
+Could you explain me what you mean by "you should use the query string for that" ?
+
+Samir 
+On 26 juil. 2013, at 18:11, Loïc Hoguin wrote:
+
+> On 07/26/2013 06:08 PM, Samir Sow wrote:
+>> Hi,
+>> 
+>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+>> Is there any way to change this behavior ?
+> 
+> Look for the commit that removed "cowboy_req:fragment/1".
+> 
+> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that.
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000173.html b/_build/static/archives/extend/2013-July/000173.html new file mode 100644 index 00000000..c473a796 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000173.html @@ -0,0 +1,99 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Jul 26 18:25:52 CEST 2013 +

+
+ +
/path/to/resource?f=value
+
+instead of
+
+/path/to/resource#value
+
+On 07/26/2013 06:25 PM, Samir Sow wrote:
+> Thank you Loic
+>
+> I'm not http protocol fluent.
+> Could you explain me what you mean by "you should use the query string for that" ?
+>
+> Samir
+> On 26 juil. 2013, at 18:11, Loïc Hoguin wrote:
+>
+>> On 07/26/2013 06:08 PM, Samir Sow wrote:
+>>> Hi,
+>>>
+>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+>>> Is there any way to change this behavior ?
+>>
+>> Look for the commit that removed "cowboy_req:fragment/1".
+>>
+>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that.
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000174.html b/_build/static/archives/extend/2013-July/000174.html new file mode 100644 index 00000000..73a1106c --- /dev/null +++ b/_build/static/archives/extend/2013-July/000174.html @@ -0,0 +1,109 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Samir Sow + samset at wanadoo.fr +
+ Fri Jul 26 18:39:02 CEST 2013 +

+
+ +
+Actually my query is something like
+
+/path?=key=*value, value#&key=value2....
+But in the request i only receive the data before the # (the pound is removed)
+
+
+On 26 juil. 2013, at 18:25, Loïc Hoguin wrote:
+
+> /path/to/resource?f=value
+> 
+> instead of
+> 
+> /path/to/resource#value
+> 
+> On 07/26/2013 06:25 PM, Samir Sow wrote:
+>> Thank you Loic
+>> 
+>> I'm not http protocol fluent.
+>> Could you explain me what you mean by "you should use the query string for that" ?
+>> 
+>> Samir
+>> On 26 juil. 2013, at 18:11, Loïc Hoguin wrote:
+>> 
+>>> On 07/26/2013 06:08 PM, Samir Sow wrote:
+>>>> Hi,
+>>>> 
+>>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+>>>> Is there any way to change this behavior ?
+>>> 
+>>> Look for the commit that removed "cowboy_req:fragment/1".
+>>> 
+>>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that.
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>> 
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/000175.html b/_build/static/archives/extend/2013-July/000175.html new file mode 100644 index 00000000..30e5c3f1 --- /dev/null +++ b/_build/static/archives/extend/2013-July/000175.html @@ -0,0 +1,119 @@ + + + + [99s-extend] query string with # sign + + + + + + + + + + +

[99s-extend] query string with # sign

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Jul 26 18:42:41 CEST 2013 +

+
+ +
You have to encode the value (urlencode algorithm), some characters, 
+like #, have a special meaning. Cowboy will urldecode automatically and 
+give you the # you expect.
+
+On 07/26/2013 06:39 PM, Samir Sow wrote:
+>
+> Actually my query is something like
+>
+> /path?=key=*value, value#&key=value2....
+> But in the request i only receive the data before the # (the pound is removed)
+>
+>
+> On 26 juil. 2013, at 18:25, Loïc Hoguin wrote:
+>
+>> /path/to/resource?f=value
+>>
+>> instead of
+>>
+>> /path/to/resource#value
+>>
+>> On 07/26/2013 06:25 PM, Samir Sow wrote:
+>>> Thank you Loic
+>>>
+>>> I'm not http protocol fluent.
+>>> Could you explain me what you mean by "you should use the query string for that" ?
+>>>
+>>> Samir
+>>> On 26 juil. 2013, at 18:11, Loïc Hoguin wrote:
+>>>
+>>>> On 07/26/2013 06:08 PM, Samir Sow wrote:
+>>>>> Hi,
+>>>>>
+>>>>> It seems that Cowboy removes the data after the # sign from the query string (GET) before handing the req to the handler.
+>>>>> Is there any way to change this behavior ?
+>>>>
+>>>> Look for the commit that removed "cowboy_req:fragment/1".
+>>>>
+>>>> But be aware that #fragments aren't expected to be sent by an HTTP request and that browsers don't send it either. You probably should use the query string for that.
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-July/author.html b/_build/static/archives/extend/2013-July/author.html new file mode 100644 index 00000000..16af8e9b --- /dev/null +++ b/_build/static/archives/extend/2013-July/author.html @@ -0,0 +1,167 @@ + + + + The Extend July 2013 Archive by author + + + + + +

July 2013 Archives by author

+ +

Starting: Tue Jul 9 18:11:50 CEST 2013
+ Ending: Fri Jul 26 18:42:41 CEST 2013
+ Messages: 24

+

+

+ Last message date: + Fri Jul 26 18:42:41 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-July/date.html b/_build/static/archives/extend/2013-July/date.html new file mode 100644 index 00000000..3cacbcc1 --- /dev/null +++ b/_build/static/archives/extend/2013-July/date.html @@ -0,0 +1,167 @@ + + + + The Extend July 2013 Archive by date + + + + + +

July 2013 Archives by date

+ +

Starting: Tue Jul 9 18:11:50 CEST 2013
+ Ending: Fri Jul 26 18:42:41 CEST 2013
+ Messages: 24

+

+

+ Last message date: + Fri Jul 26 18:42:41 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-July/index.html b/_build/static/archives/extend/2013-July/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-July/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-July/subject.html b/_build/static/archives/extend/2013-July/subject.html new file mode 100644 index 00000000..043ddebb --- /dev/null +++ b/_build/static/archives/extend/2013-July/subject.html @@ -0,0 +1,167 @@ + + + + The Extend July 2013 Archive by subject + + + + + +

July 2013 Archives by subject

+ +

Starting: Tue Jul 9 18:11:50 CEST 2013
+ Ending: Fri Jul 26 18:42:41 CEST 2013
+ Messages: 24

+

+

+ Last message date: + Fri Jul 26 18:42:41 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-July/thread.html b/_build/static/archives/extend/2013-July/thread.html new file mode 100644 index 00000000..22246907 --- /dev/null +++ b/_build/static/archives/extend/2013-July/thread.html @@ -0,0 +1,211 @@ + + + + The Extend July 2013 Archive by thread + + + + + +

July 2013 Archives by thread

+ +

Starting: Tue Jul 9 18:11:50 CEST 2013
+ Ending: Fri Jul 26 18:42:41 CEST 2013
+ Messages: 24

+

+

+ Last message date: + Fri Jul 26 18:42:41 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-June.txt b/_build/static/archives/extend/2013-June.txt new file mode 100644 index 00000000..aff4b659 --- /dev/null +++ b/_build/static/archives/extend/2013-June.txt @@ -0,0 +1,80 @@ +From darkit at gmail.com Wed Jun 5 21:50:25 2013 +From: darkit at gmail.com (Max Grigoriev) +Date: Wed, 5 Jun 2013 22:50:25 +0300 +Subject: [99s-extend] Cowboy handler and custom gen_server link +Message-ID: + +Hi, + +I'm trying to implement REST handler which communicates to custom +gen_servers. + +Get gen_server from supervisor and link to current handler process: + +rest_init(Req, _Opts) -> +... + process_flag(trap_exit, true), + {ok, Pid} = pbshare_logic_sup:start_registration(), + link(Pid), +... + +make_get(Req, State) -> +.... +make error here !!! +.... + + +And gen_server code: +start_link() -> + gen_server:start_link(?MODULE, [], []). + +init(Args) -> + process_flag(trap_exit, true), + {ok, []}. + +handle_info({'EXIT', FromPid, Reason}, State) -> + lager:info("Exit Logic from ~p Reason: ~p~n", [FromPid, Reason]), + {noreply, State}; + +So I expect to receive EXIT signal from REST handler to my gen_server when +error occurs in cowboy. +But I don't receive it. Am I doing something wrong? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jun 20 16:15:34 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 20 Jun 2013 16:15:34 +0200 +Subject: [99s-extend] [ANN] Cowboy 0.8.6 and Ranch 0.8.4 (R16B01 compatible) +Message-ID: <51C30E86.8050305@ninenines.eu> + +Hello, + +Just a heads up, a new version of Cowboy and Ranch has been pushed that +fixes compilation and documentation for R16B01: you now need the asn1 +application to be started when using SSL. They will be started +automatically if they weren't before, but you will need them in your +release (done automatically with relx). + +Other interesting changes for Cowboy include: + + * Support for compression of Websocket frames (thanks Ali Sabil) + + * Initial support for SPDY + +Both are experimental features and undocumented at this point, but +feedback is more than welcome. See the changelog for more information. + + * https://github.com/extend/cowboy + * https://github.com/extend/ranch + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2013-June/000150.html b/_build/static/archives/extend/2013-June/000150.html new file mode 100644 index 00000000..a50c48bf --- /dev/null +++ b/_build/static/archives/extend/2013-June/000150.html @@ -0,0 +1,96 @@ + + + + [99s-extend] Cowboy handler and custom gen_server link + + + + + + + + + + +

[99s-extend] Cowboy handler and custom gen_server link

+ Max Grigoriev + darkit at gmail.com +
+ Wed Jun 5 21:50:25 CEST 2013 +

+
+ +
Hi,
+
+I'm trying to implement REST handler which communicates to custom
+gen_servers.
+
+Get gen_server from supervisor and link to current handler process:
+
+rest_init(Req, _Opts) ->
+...
+  process_flag(trap_exit, true),
+  {ok, Pid} = pbshare_logic_sup:start_registration(),
+  link(Pid),
+...
+
+make_get(Req, State) ->
+....
+make error here !!!
+....
+
+
+And gen_server code:
+start_link() ->
+  gen_server:start_link(?MODULE, [], []).
+
+init(Args) ->
+  process_flag(trap_exit, true),
+  {ok, []}.
+
+handle_info({'EXIT', FromPid, Reason}, State) ->
+  lager:info("Exit Logic from ~p  Reason: ~p~n", [FromPid, Reason]),
+  {noreply, State};
+
+So I expect to receive EXIT signal from REST handler to my gen_server when
+error occurs in cowboy.
+But I don't receive it. Am I doing something wrong?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130605/568478c8/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-June/000151.html b/_build/static/archives/extend/2013-June/000151.html new file mode 100644 index 00000000..9393761f --- /dev/null +++ b/_build/static/archives/extend/2013-June/000151.html @@ -0,0 +1,86 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.6 and Ranch 0.8.4 (R16B01 compatible) + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.6 and Ranch 0.8.4 (R16B01 compatible)

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jun 20 16:15:34 CEST 2013 +

+
+ +
Hello,
+
+Just a heads up, a new version of Cowboy and Ranch has been pushed that 
+fixes compilation and documentation for R16B01: you now need the asn1 
+application to be started when using SSL. They will be started 
+automatically if they weren't before, but you will need them in your 
+release (done automatically with relx).
+
+Other interesting changes for Cowboy include:
+
+  *  Support for compression of Websocket frames (thanks Ali Sabil)
+
+  *  Initial support for SPDY
+
+Both are experimental features and undocumented at this point, but 
+feedback is more than welcome. See the changelog for more information.
+
+  *  https://github.com/extend/cowboy
+  *  https://github.com/extend/ranch
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-June/author.html b/_build/static/archives/extend/2013-June/author.html new file mode 100644 index 00000000..635bdc2a --- /dev/null +++ b/_build/static/archives/extend/2013-June/author.html @@ -0,0 +1,57 @@ + + + + The Extend June 2013 Archive by author + + + + + +

June 2013 Archives by author

+ +

Starting: Wed Jun 5 21:50:25 CEST 2013
+ Ending: Thu Jun 20 16:15:34 CEST 2013
+ Messages: 2

+

+

+ Last message date: + Thu Jun 20 16:15:34 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-June/date.html b/_build/static/archives/extend/2013-June/date.html new file mode 100644 index 00000000..065c03ec --- /dev/null +++ b/_build/static/archives/extend/2013-June/date.html @@ -0,0 +1,57 @@ + + + + The Extend June 2013 Archive by date + + + + + +

June 2013 Archives by date

+ +

Starting: Wed Jun 5 21:50:25 CEST 2013
+ Ending: Thu Jun 20 16:15:34 CEST 2013
+ Messages: 2

+

+

+ Last message date: + Thu Jun 20 16:15:34 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-June/index.html b/_build/static/archives/extend/2013-June/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-June/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-June/subject.html b/_build/static/archives/extend/2013-June/subject.html new file mode 100644 index 00000000..6038dd9d --- /dev/null +++ b/_build/static/archives/extend/2013-June/subject.html @@ -0,0 +1,57 @@ + + + + The Extend June 2013 Archive by subject + + + + + +

June 2013 Archives by subject

+ +

Starting: Wed Jun 5 21:50:25 CEST 2013
+ Ending: Thu Jun 20 16:15:34 CEST 2013
+ Messages: 2

+

+

+ Last message date: + Thu Jun 20 16:15:34 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-June/thread.html b/_build/static/archives/extend/2013-June/thread.html new file mode 100644 index 00000000..8e8eb77e --- /dev/null +++ b/_build/static/archives/extend/2013-June/thread.html @@ -0,0 +1,59 @@ + + + + The Extend June 2013 Archive by thread + + + + + +

June 2013 Archives by thread

+ +

Starting: Wed Jun 5 21:50:25 CEST 2013
+ Ending: Thu Jun 20 16:15:34 CEST 2013
+ Messages: 2

+

+

+ Last message date: + Thu Jun 20 16:15:34 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-March.txt b/_build/static/archives/extend/2013-March.txt new file mode 100644 index 00000000..60997407 --- /dev/null +++ b/_build/static/archives/extend/2013-March.txt @@ -0,0 +1,161 @@ +From essen at ninenines.eu Wed Mar 6 20:09:27 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 06 Mar 2013 20:09:27 +0100 +Subject: [99s-extend] [ANN] Ranch 0.6.2 +Message-ID: <51379467.3080504@ninenines.eu> + +Small update to Ranch: https://github.com/extend/ranch + + * Allow fail_if_no_peer_cert option in ranch_ssl + * Allow next_protocols_advertised option in ranch_ssl + +Second one is mostly just for SPDY. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Sat Mar 9 15:25:27 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sat, 09 Mar 2013 15:25:27 +0100 +Subject: [99s-extend] [ANN] Cowboy 0.8.2 +Message-ID: <513B4657.4050001@ninenines.eu> + +Just tagged a new version: https://github.com/extend/cowboy + +Focus has been mostly the body reading API, which should be much faster +and also safer to use now. + +Enjoy! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From kozlov-ter at yandex.ru Sun Mar 17 17:22:01 2013 +From: kozlov-ter at yandex.ru (=?koi8-r?B?68/azM/XIPfR3sXTzMHX?=) +Date: Sun, 17 Mar 2013 20:22:01 +0400 +Subject: [99s-extend] cowboy header +Message-ID: <696341363537321@web14h.yandex.ru> + +An HTML attachment was scrubbed... +URL: + +From Christopher.Phillips at turner.com Sun Mar 17 17:27:40 2013 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Sun, 17 Mar 2013 16:27:40 +0000 +Subject: [99s-extend] cowboy header +In-Reply-To: <696341363537321@web14h.yandex.ru> +Message-ID: + + Cowboy aims to use binaries, not strings, and unless there's a change in the head branch I don't have, the returned tuple has only two values, the value and the request. So it should look like something like - + + {Value, Req2} = cowboy_req:header(<<"user-agent">>, Req) + + + + +From: ?????? ???????? > +Date: Sunday, March 17, 2013 9:22 AM +To: "extend at lists.ninenines.eu" > +Subject: [99s-extend] cowboy header + +Hello tell me how I can get for example http header "user-agent"? +I do so: + +handle(Req, State) -> + +{ok, FwdIP, Req5} = cowboy_req:header("user-agent, Req) + +but in this place I get the error + + + +-- +Vjacheslav Kozlov +Engineer of AEMS +Ltd. "EER-Novomichurinsk" +-- +http://www.ter-energo.ru ++79109095144 09:00-18:00 (GMT+04:00) +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mjollnir.ray at gmail.com Mon Mar 18 09:39:20 2013 +From: mjollnir.ray at gmail.com (Wu Ray) +Date: Mon, 18 Mar 2013 16:39:20 +0800 +Subject: [99s-extend] Big body via REST +Message-ID: + +>> Hi list, +>> +>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database? +>> +>Hey, +> +>If you know the size, reply with {stream, Size, StreamFun}, otherwise +>{stream, StreamFun}, with StreamFun the function that will send all the +>data to the socket. + +Hi, guys, +my problem is, if the client is closed or network broken, how to +handle these situation with cowboy. + + +From mjollnir.ray at gmail.com Mon Mar 18 10:21:13 2013 +From: mjollnir.ray at gmail.com (Wu Ray) +Date: Mon, 18 Mar 2013 17:21:13 +0800 +Subject: [99s-extend] Big body via REST +In-Reply-To: +References: +Message-ID: + +Get it. When something happed with client or network, socket will +broke, and Transport:send/2 will return {error, closed}, etc. + +So, just make sure each Transport:send(...) is correct, like this: +ok = Transport:send(Socket, Data), + +the rest will be handle by cowboy. + +On Mon, Mar 18, 2013 at 4:39 PM, Wu Ray wrote: +>>> Hi list, +>>> +>>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database? +>>> +>>Hey, +>> +>>If you know the size, reply with {stream, Size, StreamFun}, otherwise +>>{stream, StreamFun}, with StreamFun the function that will send all the +>>data to the socket. +> +> Hi, guys, +> my problem is, if the client is closed or network broken, how to +> handle these situation with cowboy. + + +From erlang at rambocoder.com Wed Mar 20 13:54:07 2013 +From: erlang at rambocoder.com (rambocoder) +Date: Wed, 20 Mar 2013 08:54:07 -0400 +Subject: [99s-extend] Login page and session based auth example +Message-ID: + +Does anybody have an example of Cowboy app that includes a login page, +secure area and user registration form? It's easy to put this together +using ChicagoBoss framework, but I was wondering if somebody has done +this just using pure Cowboy. + +Thank you, + +-rambocoder + + diff --git a/_build/static/archives/extend/2013-March/000066.html b/_build/static/archives/extend/2013-March/000066.html new file mode 100644 index 00000000..716ac870 --- /dev/null +++ b/_build/static/archives/extend/2013-March/000066.html @@ -0,0 +1,73 @@ + + + + [99s-extend] [ANN] Ranch 0.6.2 + + + + + + + + + + +

[99s-extend] [ANN] Ranch 0.6.2

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Mar 6 20:09:27 CET 2013 +

+
+ +
Small update to Ranch: https://github.com/extend/ranch
+
+  *  Allow fail_if_no_peer_cert option in ranch_ssl
+  *  Allow next_protocols_advertised option in ranch_ssl
+
+Second one is mostly just for SPDY.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000067.html b/_build/static/archives/extend/2013-March/000067.html new file mode 100644 index 00000000..3f496466 --- /dev/null +++ b/_build/static/archives/extend/2013-March/000067.html @@ -0,0 +1,73 @@ + + + + [99s-extend] [ANN] Cowboy 0.8.2 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 0.8.2

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Mar 9 15:25:27 CET 2013 +

+
+ +
Just tagged a new version: https://github.com/extend/cowboy
+
+Focus has been mostly the body reading API, which should be much faster 
+and also safer to use now.
+
+Enjoy!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000068.html b/_build/static/archives/extend/2013-March/000068.html new file mode 100644 index 00000000..68768b0d --- /dev/null +++ b/_build/static/archives/extend/2013-March/000068.html @@ -0,0 +1,62 @@ + + + + [99s-extend] cowboy header + + + + + + + + + + +

[99s-extend] cowboy header

+ Козлов Вячеслав + kozlov-ter at yandex.ru +
+ Sun Mar 17 17:22:01 CET 2013 +

+
+ +
An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130317/2f20f449/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000069.html b/_build/static/archives/extend/2013-March/000069.html new file mode 100644 index 00000000..96114ecc --- /dev/null +++ b/_build/static/archives/extend/2013-March/000069.html @@ -0,0 +1,93 @@ + + + + [99s-extend] cowboy header + + + + + + + + + + +

[99s-extend] cowboy header

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Sun Mar 17 17:27:40 CET 2013 +

+
+ +
  Cowboy aims to use binaries, not strings, and unless there's a change in the head branch I don't have, the returned tuple has only two values, the value and the request. So it should look like something like -
+
+  {Value, Req2} = cowboy_req:header(<<"user-agent">>, Req)
+
+
+
+
+From: Козлов Вячеслав <kozlov-ter at yandex.ru<mailto:kozlov-ter at yandex.ru>>
+Date: Sunday, March 17, 2013 9:22 AM
+To: "extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>" <extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>>
+Subject: [99s-extend] cowboy header
+
+Hello tell me how I can get for example http header "user-agent"?
+I do so:
+
+handle(Req, State) ->
+
+{ok, FwdIP, Req5} = cowboy_req:header("user-agent, Req)
+
+but in this place I get the error
+
+
+
+--
+Vjacheslav Kozlov
+Engineer of AEMS
+Ltd. "EER-Novomichurinsk"
+--
+http://www.ter-energo.ru
++79109095144 09:00-18:00 (GMT+04:00)
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130317/2ee0bc92/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000070.html b/_build/static/archives/extend/2013-March/000070.html new file mode 100644 index 00000000..6c25a328 --- /dev/null +++ b/_build/static/archives/extend/2013-March/000070.html @@ -0,0 +1,74 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Wu Ray + mjollnir.ray at gmail.com +
+ Mon Mar 18 09:39:20 CET 2013 +

+
+ +
>> Hi list,
+>>
+>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+>>
+>Hey,
+>
+>If you know the size, reply with {stream, Size, StreamFun}, otherwise
+>{stream, StreamFun}, with StreamFun the function that will send all the
+>data to the socket.
+
+Hi, guys,
+my problem is, if the client is closed or network broken, how to
+handle these situation with cowboy.
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000071.html b/_build/static/archives/extend/2013-March/000071.html new file mode 100644 index 00000000..27fd22c1 --- /dev/null +++ b/_build/static/archives/extend/2013-March/000071.html @@ -0,0 +1,83 @@ + + + + [99s-extend] Big body via REST + + + + + + + + + + +

[99s-extend] Big body via REST

+ Wu Ray + mjollnir.ray at gmail.com +
+ Mon Mar 18 10:21:13 CET 2013 +

+
+ +
Get it. When something happed with client or network, socket will
+broke, and Transport:send/2 will return {error, closed}, etc.
+
+So, just make sure each Transport:send(...) is correct, like this:
+ok = Transport:send(Socket, Data),
+
+the rest will be handle by cowboy.
+
+On Mon, Mar 18, 2013 at 4:39 PM, Wu Ray <mjollnir.ray at gmail.com> wrote:
+>>> Hi list,
+>>>
+>>> how properly send big response (hundreds of megabytes) via REST callback? As far as I can see REST handler in cowboy handles special case for callback functions (cowboy_rest.erl, line 844): {stream, StreamFun} - is it right place for stream big response from SQL database?
+>>>
+>>Hey,
+>>
+>>If you know the size, reply with {stream, Size, StreamFun}, otherwise
+>>{stream, StreamFun}, with StreamFun the function that will send all the
+>>data to the socket.
+>
+> Hi, guys,
+> my problem is, if the client is closed or network broken, how to
+> handle these situation with cowboy.
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/000072.html b/_build/static/archives/extend/2013-March/000072.html new file mode 100644 index 00000000..40b60860 --- /dev/null +++ b/_build/static/archives/extend/2013-March/000072.html @@ -0,0 +1,67 @@ + + + + [99s-extend] Login page and session based auth example + + + + + + + + + + +

[99s-extend] Login page and session based auth example

+ rambocoder + erlang at rambocoder.com +
+ Wed Mar 20 13:54:07 CET 2013 +

+
+ +
Does anybody have an example of Cowboy app that includes a login page,
+secure area and user registration form? It's easy to put this together
+using ChicagoBoss framework, but I was wondering if somebody has done
+this just using pure Cowboy.
+
+Thank you,
+
+-rambocoder
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-March/author.html b/_build/static/archives/extend/2013-March/author.html new file mode 100644 index 00000000..a75b4dd2 --- /dev/null +++ b/_build/static/archives/extend/2013-March/author.html @@ -0,0 +1,82 @@ + + + + The Extend March 2013 Archive by author + + + + + +

March 2013 Archives by author

+ +

Starting: Wed Mar 6 20:09:27 CET 2013
+ Ending: Wed Mar 20 13:54:07 CET 2013
+ Messages: 7

+

+

+ Last message date: + Wed Mar 20 13:54:07 CET 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-March/date.html b/_build/static/archives/extend/2013-March/date.html new file mode 100644 index 00000000..b265c6b5 --- /dev/null +++ b/_build/static/archives/extend/2013-March/date.html @@ -0,0 +1,82 @@ + + + + The Extend March 2013 Archive by date + + + + + +

March 2013 Archives by date

+ +

Starting: Wed Mar 6 20:09:27 CET 2013
+ Ending: Wed Mar 20 13:54:07 CET 2013
+ Messages: 7

+

+

+ Last message date: + Wed Mar 20 13:54:07 CET 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-March/index.html b/_build/static/archives/extend/2013-March/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-March/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-March/subject.html b/_build/static/archives/extend/2013-March/subject.html new file mode 100644 index 00000000..4739657b --- /dev/null +++ b/_build/static/archives/extend/2013-March/subject.html @@ -0,0 +1,82 @@ + + + + The Extend March 2013 Archive by subject + + + + + +

March 2013 Archives by subject

+ +

Starting: Wed Mar 6 20:09:27 CET 2013
+ Ending: Wed Mar 20 13:54:07 CET 2013
+ Messages: 7

+

+

+ Last message date: + Wed Mar 20 13:54:07 CET 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-March/thread.html b/_build/static/archives/extend/2013-March/thread.html new file mode 100644 index 00000000..1ab0df70 --- /dev/null +++ b/_build/static/archives/extend/2013-March/thread.html @@ -0,0 +1,93 @@ + + + + The Extend March 2013 Archive by thread + + + + + +

March 2013 Archives by thread

+ +

Starting: Wed Mar 6 20:09:27 CET 2013
+ Ending: Wed Mar 20 13:54:07 CET 2013
+ Messages: 7

+

+

+ Last message date: + Wed Mar 20 13:54:07 CET 2013
+ Archived on: Wed May 28 18:41:43 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-May.txt b/_build/static/archives/extend/2013-May.txt new file mode 100644 index 00000000..0088d72d --- /dev/null +++ b/_build/static/archives/extend/2013-May.txt @@ -0,0 +1,961 @@ +From dave at dloh.org Mon May 6 04:23:00 2013 +From: dave at dloh.org (Dave Goehrig) +Date: Sun, 5 May 2013 22:23:00 -0400 +Subject: [99s-extend] No draft-hybi-00 hixie-76 support? +Message-ID: <40605B6A-E45F-491A-9B9D-70B2C5675F0F@dloh.org> + +Looking at the websocket code it doesn't seem to support the still rather widely adopted hybi-00 draft. This is pretty fatal for use with mobile. + +Patches wanted? + +Dave + +From dave at dloh.org Mon May 6 04:44:58 2013 +From: dave at dloh.org (Dave Goehrig) +Date: Sun, 5 May 2013 22:44:58 -0400 +Subject: [99s-extend] Draft hybi-00 and hixie-76 support +Message-ID: <8AA3BDB9-9A43-40AA-8C13-9444353B4F32@dloh.org> + +Does cowboy currently support draft-hybi-00 of the websocket protocol? My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for. + +Patches welcome? + +Dave + +From jeremy at quarkgames.com Mon May 6 05:47:44 2013 +From: jeremy at quarkgames.com (Jeremy Ong) +Date: Sun, 5 May 2013 20:47:44 -0700 +Subject: [99s-extend] Draft hybi-00 and hixie-76 support +In-Reply-To: <8AA3BDB9-9A43-40AA-8C13-9444353B4F32@dloh.org> +References: <8AA3BDB9-9A43-40AA-8C13-9444353B4F32@dloh.org> +Message-ID: + +if you are talking about the websocket protocol version that did not +have length delimited messaging and stuff, this has been deprecated +for a while. An older version exists that supports it though. + +On Sun, May 5, 2013 at 7:44 PM, Dave Goehrig wrote: +> Does cowboy currently support draft-hybi-00 of the websocket protocol? My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for. +> +> Patches welcome? +> +> Dave +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +From essen at ninenines.eu Mon May 6 13:27:28 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 06 May 2013 13:27:28 +0200 +Subject: [99s-extend] Draft hybi-00 and hixie-76 support +In-Reply-To: +References: <8AA3BDB9-9A43-40AA-8C13-9444353B4F32@dloh.org> + +Message-ID: <518793A0.9020604@ninenines.eu> + +It was removed after 0.6.1 because it was in the way of improving the +more recent Websocket versions. You can easily port the module to +current Cowboy if you need it. + +On 05/06/2013 05:47 AM, Jeremy Ong wrote: +> if you are talking about the websocket protocol version that did not +> have length delimited messaging and stuff, this has been deprecated +> for a while. An older version exists that supports it though. +> +> On Sun, May 5, 2013 at 7:44 PM, Dave Goehrig wrote: +>> Does cowboy currently support draft-hybi-00 of the websocket protocol? My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for. +>> +>> Patches welcome? +>> +>> Dave +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Mon May 6 17:38:44 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 06 May 2013 17:38:44 +0200 +Subject: [99s-extend] cowboy websocket and wamp +In-Reply-To: +References: +Message-ID: <5187CE84.5060406@ninenines.eu> + +It's a JSON based protocol, so I suppose you need to write a Websocket +handler that implements that protocol using one of the JSON libraries +available in Erlang like jsx for example. + +On 04/30/2013 08:59 PM, Gregory de Souza wrote: +> Hi, +> I'm new to the community and am exploring cowboy for a project. +> +> Can anyone offer guidance/links on how to use cowboy's websocket support +> with WAMP (http://wamp.ws/)? +> The cowboy docs mention bullet +> as a convenient +> client/server lib (with an AJAX fallback) which is great, but I'd like +> to use WAMP's RPC and PubSub so I'm unsure how to proceed. +> +> Any tips would be appreciated! +> +> Thanks in advance +> -- +> Gregory | @gdesouza | http://blog.gdesouza.me +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From quiquepaz at gmail.com Sun May 12 13:42:38 2013 +From: quiquepaz at gmail.com (Enrique Paz) +Date: Sun, 12 May 2013 13:42:38 +0200 +Subject: [99s-extend] Cowboy: retrieving "just set" cookies +Message-ID: + +Hi, + +I have a piece of code that receives a cowboy_req:http_req() object and +depending on some Context sets 1 or more cookies +using cowboy_req:set_resp_cookie/4. + +add_cookies(Req, Context) -> ReqWithCookiesSet + +I want to write a unit test for it, checking that the right cookies are set +for the right Context. How can I do that? I miss something like +cowboy_req:get_resp_cookie/2 or so. + +Thx in advance for your help. + +-- +Enrique +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Sun May 12 13:44:44 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 12 May 2013 13:44:44 +0200 +Subject: [99s-extend] Cowboy: retrieving "just set" cookies +In-Reply-To: +References: +Message-ID: <518F80AC.6060408@ninenines.eu> + +It sets a set-cookie header directly. You can retrieve all response +headers by calling something like cowboy_req:get(resp_headers, Req). + +On 05/12/2013 01:42 PM, Enrique Paz wrote: +> Hi, +> +> I have a piece of code that receives a cowboy_req:http_req() object and +> depending on some Context sets 1 or more cookies +> using cowboy_req:set_resp_cookie/4. +> +> add_cookies(Req, Context) -> ReqWithCookiesSet +> +> I want to write a unit test for it, checking that the right cookies are +> set for the right Context. How can I do that? I miss something like +> cowboy_req:get_resp_cookie/2 or so. +> +> Thx in advance for your help. +> +> -- +> Enrique +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From quiquepaz at gmail.com Sun May 12 13:59:44 2013 +From: quiquepaz at gmail.com (Enrique Paz) +Date: Sun, 12 May 2013 13:59:44 +0200 +Subject: [99s-extend] Cowboy: retrieving "just set" cookies +In-Reply-To: <518F80AC.6060408@ninenines.eu> +References: + <518F80AC.6060408@ninenines.eu> +Message-ID: + +Ok, thx, I missed that one :) + + +2013/5/12 Lo?c Hoguin + +> It sets a set-cookie header directly. You can retrieve all response +> headers by calling something like cowboy_req:get(resp_headers, Req). +> +> +> On 05/12/2013 01:42 PM, Enrique Paz wrote: +> +>> Hi, +>> +>> I have a piece of code that receives a cowboy_req:http_req() object and +>> depending on some Context sets 1 or more cookies +>> using cowboy_req:set_resp_cookie/4. +>> +>> add_cookies(Req, Context) -> ReqWithCookiesSet +>> +>> I want to write a unit test for it, checking that the right cookies are +>> set for the right Context. How can I do that? I miss something like +>> cowboy_req:get_resp_cookie/2 or so. +>> +>> Thx in advance for your help. +>> +>> -- +>> Enrique +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> + + + +-- +quique +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ivan at llaisdy.com Wed May 15 12:56:57 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Wed, 15 May 2013 11:56:57 +0100 +Subject: [99s-extend] "access.log" for Cowboy +Message-ID: <519369F9.4090008@llaisdy.com> + +Dear All + +I'm using cowboy for a restful web application, and I've set up +on_request_hook and on_response_hook to log requests and responses. + +I'm using lager for logging and at the moment the above log messages are +just going out to the console.log file (via lager:info/2). + +I'd like to have these log messages sent to a separate file, e.g., +"access.log", that contains only the request & response logs. + +Is anyone doing something like this now? I think it's not an unusual +pattern with web servers. Can I do this with lager (i.e., send only +messages at level X, not level X or above)? Is there a more appropriate +logging mechanism? + +With thanks and best wishes + +Ivan + + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From hq at mtod.org Wed May 15 13:09:45 2013 +From: hq at mtod.org (Adam Rutkowski) +Date: Wed, 15 May 2013 13:09:45 +0200 +Subject: [99s-extend] "access.log" for Cowboy +In-Reply-To: <519369F9.4090008@llaisdy.com> +References: <519369F9.4090008@llaisdy.com> +Message-ID: + + +On 15 May 2013, at 12:56, Ivan Uemlianin wrote: +> +> Is anyone doing something like this now? I think it's not an unusual pattern with web servers. Can I do this with lager (i.e., send only messages at level X, not level X or above)? Is there a more appropriate logging mechanism? + +See lager's tracing feature. You can tag your messages and redirect them to a specific backend. +Since 353dd21fde tracing is configurable. + +A. + +From ivan at llaisdy.com Wed May 15 13:40:47 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Wed, 15 May 2013 12:40:47 +0100 +Subject: [99s-extend] SOLVED -- Re: "access.log" for Cowboy +In-Reply-To: +References: <519369F9.4090008@llaisdy.com> + +Message-ID: <5193743F.4010007@llaisdy.com> + +Thanks! I got that working. + +When I start cowboy, I call + + {ok, Trace} = lager:trace_file("path/to//access.log", + [{type, access}]), + +When you say + + > Since 353dd21fde tracing is configurable. + +Do you mean the above could go in a .config file? I haven't found +anything to that effect. I'll keep looking. + +Best wishes + +Ivan + + +On 15/05/2013 12:09, Adam Rutkowski wrote: +> +> On 15 May 2013, at 12:56, Ivan Uemlianin wrote: +>> +>> Is anyone doing something like this now? I think it's not an unusual pattern with web servers. Can I do this with lager (i.e., send only messages at level X, not level X or above)? Is there a more appropriate logging mechanism? +> +> See lager's tracing feature. You can tag your messages and redirect them to a specific backend. +> Since 353dd21fde tracing is configurable. +> +> A. +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From hq at mtod.org Wed May 15 13:56:09 2013 +From: hq at mtod.org (Adam Rutkowski) +Date: Wed, 15 May 2013 13:56:09 +0200 +Subject: [99s-extend] SOLVED -- Re: "access.log" for Cowboy +In-Reply-To: <5193743F.4010007@llaisdy.com> +References: <519369F9.4090008@llaisdy.com> + + <5193743F.4010007@llaisdy.com> +Message-ID: + + +On 15 May 2013, at 13:40, Ivan Uemlianin wrote: + +> Thanks! I got that working. +> +> When I start cowboy, I call +> +> {ok, Trace} = lager:trace_file("path/to//access.log", +> [{type, access}]), +> +> When you say +> +> > Since 353dd21fde tracing is configurable. +> +> Do you mean the above could go in a .config file? I haven't found anything to that effect. I'll keep looking. + +See https://github.com/basho/lager/pull/134 + +From ivan at llaisdy.com Wed May 15 14:43:28 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Wed, 15 May 2013 13:43:28 +0100 +Subject: [99s-extend] SOLVED -- Re: "access.log" for Cowboy +In-Reply-To: +References: <519369F9.4090008@llaisdy.com> + + <5193743F.4010007@llaisdy.com> + +Message-ID: <519382F0.4040309@llaisdy.com> + +Thanks for this. I've tried it. It seems to be adding a trace to an +already existing log file (which is already handling log messagse of a +certain level). e.g., it uses lager:trace not lager:trace_file. + +I can't set it up so the trace file receives *only* trace messages. I'l +revert to the lager:trace_file call. + +Best wishes + +Ivan + + +Below is the config I've been using. + + {lager, [ + {handlers, + [ + {lager_console_backend, info}, + {lager_file_backend, + [ + [{file, "log/error.log"}, {level, error}, + {size, 10485760}, + {date, "$D0"}, {count, 5}], + [{file, "log/console.log"}, {level, info}, + {size, 10485760}, + {date, "$D0"}, {count, 5}], + [{file, "log/access.log"}, + {size, 10485760}, + {date, "$D0"}, {count, 5}] + ]} + ]}, + {traces, + [ + {{lager_file_backend, "log/access.log"}, + [{type, access}], debug} + ]} + ]}, + + +On 15/05/2013 12:56, Adam Rutkowski wrote: +> +> On 15 May 2013, at 13:40, Ivan Uemlianin wrote: +> +>> Thanks! I got that working. +>> +>> When I start cowboy, I call +>> +>> {ok, Trace} = lager:trace_file("path/to//access.log", +>> [{type, access}]), +>> +>> When you say +>> +>>> Since 353dd21fde tracing is configurable. +>> +>> Do you mean the above could go in a .config file? I haven't found anything to that effect. I'll keep looking. +> +> See https://github.com/basho/lager/pull/134 +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From hq at mtod.org Wed May 15 15:33:28 2013 +From: hq at mtod.org (Adam Rutkowski) +Date: Wed, 15 May 2013 15:33:28 +0200 +Subject: [99s-extend] SOLVED -- Re: "access.log" for Cowboy +In-Reply-To: <519382F0.4040309@llaisdy.com> +References: <519369F9.4090008@llaisdy.com> + + <5193743F.4010007@llaisdy.com> + + <519382F0.4040309@llaisdy.com> +Message-ID: + + +On 15 May 2013, at 14:43, Ivan Uemlianin wrote: + +> Thanks for this. I've tried it. It seems to be adding a trace to an already existing log file (which is already handling log messagse of a certain level). e.g., it uses lager:trace not lager:trace_file. +> +> I can't set it up so the trace file receives *only* trace messages. I'l revert to the lager:trace_file call. + +The following setup works for me: + +[ + +{lager, [ + {colored, true}, + {handlers, [ + {lager_console_backend, info}, + {lager_file_backend, [ + {file, "log/error.log"}, {level, error}, {size, 10485760}, {date, "$D0"}, {count, 5}]}, + {lager_file_backend, [ + {file, "log/cdr.log"}, {level, none}, {size, 1000}, {date, "$D0"}, {count, 5}]} + ]}, + {crash_log, "log/crash.log"}, + + +{traces, +[ +{{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug} +]} + +]} + + +]. + +Hope it helps, take care. +A. + +From ivan at llaisdy.com Wed May 15 15:47:05 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Wed, 15 May 2013 14:47:05 +0100 +Subject: [99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" for + Cowboy +In-Reply-To: +References: <519369F9.4090008@llaisdy.com> + + <5193743F.4010007@llaisdy.com> + + <519382F0.4040309@llaisdy.com> + +Message-ID: <519391D9.1000207@llaisdy.com> + +Thanks! That works for me too: it was the "{level, none}" that did it. +(I've also spruced up my syntax for lager 2.*) + +Thanks for your help and patience. + +Ivan + + +On 15/05/2013 14:33, Adam Rutkowski wrote: +> +> On 15 May 2013, at 14:43, Ivan Uemlianin wrote: +> +>> Thanks for this. I've tried it. It seems to be adding a trace to an already existing log file (which is already handling log messagse of a certain level). e.g., it uses lager:trace not lager:trace_file. +>> +>> I can't set it up so the trace file receives *only* trace messages. I'l revert to the lager:trace_file call. +> +> The following setup works for me: +> +> [ +> +> {lager, [ +> {colored, true}, +> {handlers, [ +> {lager_console_backend, info}, +> {lager_file_backend, [ +> {file, "log/error.log"}, {level, error}, {size, 10485760}, {date, "$D0"}, {count, 5}]}, +> {lager_file_backend, [ +> {file, "log/cdr.log"}, {level, none}, {size, 1000}, {date, "$D0"}, {count, 5}]} +> ]}, +> {crash_log, "log/crash.log"}, +> +> +> {traces, +> [ +> {{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug} +> ]} +> +> ]} +> +> +> ]. +> +> Hope it helps, take care. +> A. +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From chatlano at googlemail.com Fri May 17 17:41:11 2013 +From: chatlano at googlemail.com (Witali Monastyrjow) +Date: Fri, 17 May 2013 17:41:11 +0200 +Subject: [99s-extend] question to rest handler +Message-ID: + +Hi all, + +I am learning cowboy by building a small application with rest interface. +I have a hello_world rest handler and I want to implement POST method that +returns +json as response to a client. Therefor I implemented callbacks +allowed_methods, +content_types_accepted and hello_json. The docu says user callbacks can +return {Value, Req, State} and also can return {halt, Req, State}. It is +not really clear +what that Value should be. So I tried {ok, Req, State} and {true, Req, +State} and with +both values I have + +=ERROR REPORT==== 11-May-2013::16:06:40 === +Error in process <0.6649.0> with exit value: +{function_clause,[{cowboy_req,reply,[303,.... + +and client gets right response. If I use {halt, Req, State} the client gets +right response too +and there is no errors. So, Is it right way to write a POST callback and +what Values can +be used for user callbacks? I write my code below. + +amike, +Vitali + +allowed_methods(Req, State) -> +{[<<"POST">>, <<"DELETE">>], Req, State}. + +content_types_accepted(Req, State) -> +{[ + {{<<"application">>, <<"x-www-form-urlencoded">>, []}, hello_json} + ], Req, State}. + +hello_json(Req, State) -> +{ok, Req2} = cowboy_req:reply(200, [{<<"content-type">>, +<<"application/json">>} ], <<"{\"rest\": \"Hello World!\"}">>, Req), +{halt, Req2, State}. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri May 17 18:15:47 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 17 May 2013 18:15:47 +0200 +Subject: [99s-extend] question to rest handler +In-Reply-To: +References: +Message-ID: <519657B3.1080104@ninenines.eu> + +All the callbacks are explained in +http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest + +In your case take a special look at content_types_accepted. + +On 05/17/2013 05:41 PM, Witali Monastyrjow wrote: +> Hi all, +> +> I am learning cowboy by building a small application with rest interface. +> I have a hello_world rest handler and I want to implement POST method +> that returns +> json as response to a client. Therefor I implemented callbacks +> allowed_methods, +> content_types_accepted and hello_json. The docu says user callbacks can +> return {Value, Req, State} and also can return {halt, Req, State}. It is +> not really clear +> what that Value should be. So I tried {ok, Req, State} and {true, Req, +> State} and with +> both values I have +> +> =ERROR REPORT==== 11-May-2013::16:06:40 === +> Error in process <0.6649.0> with exit value: +> {function_clause,[{cowboy_req,reply,[303,.... +> +> and client gets right response. If I use {halt, Req, State} the client +> gets right response too +> and there is no errors. So, Is it right way to write a POST callback and +> what Values can +> be used for user callbacks? I write my code below. +> +> amike, +> Vitali +> +> allowed_methods(Req, State) -> +> {[<<"POST">>, <<"DELETE">>], Req, State}. +> +> content_types_accepted(Req, State) -> +> {[ +> {{<<"application">>, <<"x-www-form-urlencoded">>, []}, hello_json} +> ], Req, State}. +> +> hello_json(Req, State) -> +> {ok, Req2} = cowboy_req:reply(200, [{<<"content-type">>, +> <<"application/json">>} ], <<"{\"rest\": \"Hello World!\"}">>, Req), +> {halt, Req2, State}. +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From edgurgel at gmail.com Mon May 20 03:01:24 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Sun, 19 May 2013 22:01:24 -0300 +Subject: [99s-extend] Cowboy Middleware and websockets +Message-ID: + +I want to write a cowboy middleware that works only on non-websocket +requests. How can I achieve this? Is there any way that I ask the Request +if this is a websocket request? + +Thank you + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From edgurgel at gmail.com Mon May 20 13:53:33 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Mon, 20 May 2013 08:53:33 -0300 +Subject: [99s-extend] Cowboy Middleware and websockets +In-Reply-To: +References: +Message-ID: + +On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel wrote: + +> I want to write a cowboy middleware that works only on non-websocket +> requests. How can I achieve this? Is there any way that I ask the Request +> if this is a websocket request? +> +> +Thinking about my question, I see that the middleware (if it's behind the +cowboy_handler) can't figure if the connection will be upgraded or not. + +Still, it would be cool if I could select which routes will be applied to +my middleware. + +Am I making any sense? :) + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon May 20 15:25:53 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 20 May 2013 15:25:53 +0200 +Subject: [99s-extend] Cowboy Middleware and websockets +In-Reply-To: +References: + +Message-ID: <519A2461.1000305@ninenines.eu> + +On 05/20/2013 01:53 PM, Eduardo Gurgel wrote: +> +> +> +> On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel > wrote: +> +> I want to write a cowboy middleware that works only on non-websocket +> requests. How can I achieve this? Is there any way that I ask the +> Request if this is a websocket request? +> +> +> Thinking about my question, I see that the middleware (if it's behind +> the cowboy_handler) can't figure if the connection will be upgraded or not. +> +> Still, it would be cool if I could select which routes will be applied +> to my middleware. + +You have the Req which can help you do things based on host or path, and +you also have the environment, which contains the name of the handler +that's gonna be used if you execute your middleware after cowboy_router. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From edgurgel at gmail.com Mon May 20 16:06:20 2013 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Mon, 20 May 2013 11:06:20 -0300 +Subject: [99s-extend] Cowboy Middleware and websockets +In-Reply-To: <519A2461.1000305@ninenines.eu> +References: + + <519A2461.1000305@ninenines.eu> +Message-ID: + +On Mon, May 20, 2013 at 10:25 AM, Lo?c Hoguin wrote: + +> On 05/20/2013 01:53 PM, Eduardo Gurgel wrote: +> +>> +>> +>> +>> On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel > > wrote: +>> +>> I want to write a cowboy middleware that works only on non-websocket +>> requests. How can I achieve this? Is there any way that I ask the +>> Request if this is a websocket request? +>> +>> +>> Thinking about my question, I see that the middleware (if it's behind +>> the cowboy_handler) can't figure if the connection will be upgraded or +>> not. +>> +>> Still, it would be cool if I could select which routes will be applied +>> to my middleware. +>> +> +> You have the Req which can help you do things based on host or path, and +> you also have the environment, which contains the name of the handler +> that's gonna be used if you execute your middleware after cowboy_router. +> +> +Perfect! The environment can help me :) + + +Thank you, again! + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From Kevin.Brown at turner.com Mon May 20 20:54:20 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Mon, 20 May 2013 18:54:20 +0000 +Subject: [99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" + for Cowboy +In-Reply-To: <519391D9.1000207@llaisdy.com> +Message-ID: + +Would there be any interest in an access_combined log format? + +http://httpd.apache.org/docs/2.2/logs.html + + + +On 5/15/13 9:47 AM, "Ivan Uemlianin" wrote: + +>Thanks! That works for me too: it was the "{level, none}" that did it. +>(I've also spruced up my syntax for lager 2.*) +> +>Thanks for your help and patience. +> +>Ivan +> +> +>On 15/05/2013 14:33, Adam Rutkowski wrote: +>> +>> On 15 May 2013, at 14:43, Ivan Uemlianin wrote: +>> +>>> Thanks for this. I've tried it. It seems to be adding a trace to an +>>>already existing log file (which is already handling log messagse of a +>>>certain level). e.g., it uses lager:trace not lager:trace_file. +>>> +>>> I can't set it up so the trace file receives *only* trace messages. +>>>I'l revert to the lager:trace_file call. +>> +>> The following setup works for me: +>> +>> [ +>> +>> {lager, [ +>> {colored, true}, +>> {handlers, [ +>> {lager_console_backend, info}, +>> {lager_file_backend, [ +>> {file, "log/error.log"}, {level, error}, {size, +>>10485760}, {date, "$D0"}, {count, 5}]}, +>> {lager_file_backend, [ +>> {file, "log/cdr.log"}, {level, none}, {size, 1000}, +>>{date, "$D0"}, {count, 5}]} +>> ]}, +>> {crash_log, "log/crash.log"}, +>> +>> +>> {traces, +>> [ +>> {{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug} +>> ]} +>> +>> ]} +>> +>> +>> ]. +>> +>> Hope it helps, take care. +>> A. +>> +> +>-- +>============================================================ +>Ivan A. Uemlianin PhD +>Llaisdy +>Speech Technology Research and Development +> +> ivan at llaisdy.com +> www.llaisdy.com +> llaisdy.wordpress.com +> github.com/llaisdy +> www.linkedin.com/in/ivanuemlianin +> +> festina lente +>============================================================ +>_______________________________________________ +>Extend mailing list +>Extend at lists.ninenines.eu +>http://lists.ninenines.eu:81/listinfo/extend +> + + + + diff --git a/_build/static/archives/extend/2013-May/000128.html b/_build/static/archives/extend/2013-May/000128.html new file mode 100644 index 00000000..df8440d2 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000128.html @@ -0,0 +1,63 @@ + + + + [99s-extend] No draft-hybi-00 hixie-76 support? + + + + + + + + + + +

[99s-extend] No draft-hybi-00 hixie-76 support?

+ Dave Goehrig + dave at dloh.org +
+ Mon May 6 04:23:00 CEST 2013 +

+
+ +
Looking at the websocket code it doesn't seem to support the still rather widely adopted hybi-00 draft.  This is pretty fatal for use with mobile. 
+
+Patches wanted?
+
+Dave
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000129.html b/_build/static/archives/extend/2013-May/000129.html new file mode 100644 index 00000000..cd6462a7 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000129.html @@ -0,0 +1,65 @@ + + + + [99s-extend] Draft hybi-00 and hixie-76 support + + + + + + + + + + +

[99s-extend] Draft hybi-00 and hixie-76 support

+ Dave Goehrig + dave at dloh.org +
+ Mon May 6 04:44:58 CEST 2013 +

+
+ +
Does cowboy currently support draft-hybi-00 of the websocket protocol?  My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for. 
+
+Patches welcome?
+
+Dave
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000130.html b/_build/static/archives/extend/2013-May/000130.html new file mode 100644 index 00000000..6500f4f8 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000130.html @@ -0,0 +1,75 @@ + + + + [99s-extend] Draft hybi-00 and hixie-76 support + + + + + + + + + + +

[99s-extend] Draft hybi-00 and hixie-76 support

+ Jeremy Ong + jeremy at quarkgames.com +
+ Mon May 6 05:47:44 CEST 2013 +

+
+ +
if you are talking about the websocket protocol version that did not
+have length delimited messaging and stuff, this has been deprecated
+for a while. An older version exists that supports it though.
+
+On Sun, May 5, 2013 at 7:44 PM, Dave Goehrig <dave at dloh.org> wrote:
+> Does cowboy currently support draft-hybi-00 of the websocket protocol?  My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for.
+>
+> Patches welcome?
+>
+> Dave
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000131.html b/_build/static/archives/extend/2013-May/000131.html new file mode 100644 index 00000000..2e706b29 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000131.html @@ -0,0 +1,92 @@ + + + + [99s-extend] Draft hybi-00 and hixie-76 support + + + + + + + + + + +

[99s-extend] Draft hybi-00 and hixie-76 support

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon May 6 13:27:28 CEST 2013 +

+
+ +
It was removed after 0.6.1 because it was in the way of improving the 
+more recent Websocket versions. You can easily port the module to 
+current Cowboy if you need it.
+
+On 05/06/2013 05:47 AM, Jeremy Ong wrote:
+> if you are talking about the websocket protocol version that did not
+> have length delimited messaging and stuff, this has been deprecated
+> for a while. An older version exists that supports it though.
+>
+> On Sun, May 5, 2013 at 7:44 PM, Dave Goehrig <dave at dloh.org> wrote:
+>> Does cowboy currently support draft-hybi-00 of the websocket protocol?  My current testing seems like it does not. And a cursory review of the code failed to show anything other than more recent versions of the spec being tested for.
+>>
+>> Patches welcome?
+>>
+>> Dave
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000132.html b/_build/static/archives/extend/2013-May/000132.html new file mode 100644 index 00000000..c7f9784d --- /dev/null +++ b/_build/static/archives/extend/2013-May/000132.html @@ -0,0 +1,95 @@ + + + + [99s-extend] cowboy websocket and wamp + + + + + + + + + + +

[99s-extend] cowboy websocket and wamp

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon May 6 17:38:44 CEST 2013 +

+
+ +
It's a JSON based protocol, so I suppose you need to write a Websocket 
+handler that implements that protocol using one of the JSON libraries 
+available in Erlang like jsx for example.
+
+On 04/30/2013 08:59 PM, Gregory de Souza wrote:
+> Hi,
+> I'm new to the community and am exploring cowboy for a project.
+>
+> Can anyone offer guidance/links on how to use cowboy's websocket support
+> with WAMP (http://wamp.ws/)?
+> The cowboy docs mention bullet
+> <https://github.com/extend/bullet?source=cr> as a convenient
+> client/server lib (with an AJAX fallback) which is great, but I'd like
+> to use WAMP's RPC and PubSub so I'm unsure how to proceed.
+>
+> Any tips would be appreciated!
+>
+> Thanks in advance
+> --
+> Gregory | @gdesouza <http://twitter.com/gdesouza> | http://blog.gdesouza.me
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000133.html b/_build/static/archives/extend/2013-May/000133.html new file mode 100644 index 00000000..74754faf --- /dev/null +++ b/_build/static/archives/extend/2013-May/000133.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Cowboy: retrieving "just set" cookies + + + + + + + + + + +

[99s-extend] Cowboy: retrieving "just set" cookies

+ Enrique Paz + quiquepaz at gmail.com +
+ Sun May 12 13:42:38 CEST 2013 +

+
+ +
Hi,
+
+I have a piece of code that receives a cowboy_req:http_req() object and
+depending on some Context sets 1 or more cookies
+using cowboy_req:set_resp_cookie/4.
+
+add_cookies(Req, Context) -> ReqWithCookiesSet
+
+I want to write a unit test for it, checking that the right cookies are set
+for the right Context.  How can I do that? I miss something like
+cowboy_req:get_resp_cookie/2 or so.
+
+Thx in advance for your help.
+
+-- 
+Enrique
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130512/dd43116e/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000134.html b/_build/static/archives/extend/2013-May/000134.html new file mode 100644 index 00000000..6c46f5b8 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000134.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy: retrieving "just set" cookies + + + + + + + + + + +

[99s-extend] Cowboy: retrieving "just set" cookies

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun May 12 13:44:44 CEST 2013 +

+
+ +
It sets a set-cookie header directly. You can retrieve all response 
+headers by calling something like cowboy_req:get(resp_headers, Req).
+
+On 05/12/2013 01:42 PM, Enrique Paz wrote:
+> Hi,
+>
+> I have a piece of code that receives a cowboy_req:http_req() object and
+> depending on some Context sets 1 or more cookies
+> using cowboy_req:set_resp_cookie/4.
+>
+> add_cookies(Req, Context) -> ReqWithCookiesSet
+>
+> I want to write a unit test for it, checking that the right cookies are
+> set for the right Context.  How can I do that? I miss something like
+> cowboy_req:get_resp_cookie/2 or so.
+>
+> Thx in advance for your help.
+>
+> --
+> Enrique
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000135.html b/_build/static/archives/extend/2013-May/000135.html new file mode 100644 index 00000000..f5f1934a --- /dev/null +++ b/_build/static/archives/extend/2013-May/000135.html @@ -0,0 +1,110 @@ + + + + [99s-extend] Cowboy: retrieving "just set" cookies + + + + + + + + + + +

[99s-extend] Cowboy: retrieving "just set" cookies

+ Enrique Paz + quiquepaz at gmail.com +
+ Sun May 12 13:59:44 CEST 2013 +

+
+ +
Ok, thx, I missed that one :)
+
+
+2013/5/12 Loïc Hoguin <essen at ninenines.eu>
+
+> It sets a set-cookie header directly. You can retrieve all response
+> headers by calling something like cowboy_req:get(resp_headers, Req).
+>
+>
+> On 05/12/2013 01:42 PM, Enrique Paz wrote:
+>
+>> Hi,
+>>
+>> I have a piece of code that receives a cowboy_req:http_req() object and
+>> depending on some Context sets 1 or more cookies
+>> using cowboy_req:set_resp_cookie/4.
+>>
+>> add_cookies(Req, Context) -> ReqWithCookiesSet
+>>
+>> I want to write a unit test for it, checking that the right cookies are
+>> set for the right Context.  How can I do that? I miss something like
+>> cowboy_req:get_resp_cookie/2 or so.
+>>
+>> Thx in advance for your help.
+>>
+>> --
+>> Enrique
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+
+
+
+-- 
+quique
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130512/65929751/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000136.html b/_build/static/archives/extend/2013-May/000136.html new file mode 100644 index 00000000..6de9e081 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000136.html @@ -0,0 +1,96 @@ + + + + [99s-extend] "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] "access.log" for Cowboy

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Wed May 15 12:56:57 CEST 2013 +

+
+ +
Dear All
+
+I'm using cowboy for a restful web application, and I've set up 
+on_request_hook and on_response_hook to log requests and responses.
+
+I'm using lager for logging and at the moment the above log messages are 
+just going out to the console.log file (via lager:info/2).
+
+I'd like to have these log messages sent to a separate file, e.g., 
+"access.log", that contains only the request & response logs.
+
+Is anyone doing something like this now?  I think it's not an unusual 
+pattern with web servers.  Can I do this with lager (i.e., send only 
+messages at level X, not level X or above)?  Is there a more appropriate 
+logging mechanism?
+
+With thanks and best wishes
+
+Ivan
+
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000137.html b/_build/static/archives/extend/2013-May/000137.html new file mode 100644 index 00000000..d6aee24f --- /dev/null +++ b/_build/static/archives/extend/2013-May/000137.html @@ -0,0 +1,69 @@ + + + + [99s-extend] "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] "access.log" for Cowboy

+ Adam Rutkowski + hq at mtod.org +
+ Wed May 15 13:09:45 CEST 2013 +

+
+ +
+On 15 May 2013, at 12:56, Ivan Uemlianin wrote:
+> 
+> Is anyone doing something like this now?  I think it's not an unusual pattern with web servers.  Can I do this with lager (i.e., send only messages at level X, not level X or above)?  Is there a more appropriate logging mechanism?
+
+See lager's tracing feature. You can tag your messages and redirect them to a specific backend. 
+Since 353dd21fde tracing is configurable.
+
+A.
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000138.html b/_build/static/archives/extend/2013-May/000138.html new file mode 100644 index 00000000..20e9818d --- /dev/null +++ b/_build/static/archives/extend/2013-May/000138.html @@ -0,0 +1,106 @@ + + + + [99s-extend] SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] SOLVED -- Re: "access.log" for Cowboy

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Wed May 15 13:40:47 CEST 2013 +

+
+ +
Thanks!  I got that working.
+
+When I start cowboy, I call
+
+   {ok, Trace} = lager:trace_file("path/to//access.log",
+                                 [{type, access}]),
+
+When you say
+
+ > Since 353dd21fde tracing is configurable.
+
+Do you mean the above could go in a .config file?  I haven't found 
+anything to that effect.  I'll keep looking.
+
+Best wishes
+
+Ivan
+
+
+On 15/05/2013 12:09, Adam Rutkowski wrote:
+>
+> On 15 May 2013, at 12:56, Ivan Uemlianin wrote:
+>>
+>> Is anyone doing something like this now?  I think it's not an unusual pattern with web servers.  Can I do this with lager (i.e., send only messages at level X, not level X or above)?  Is there a more appropriate logging mechanism?
+>
+> See lager's tracing feature. You can tag your messages and redirect them to a specific backend.
+> Since 353dd21fde tracing is configurable.
+>
+> A.
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000139.html b/_build/static/archives/extend/2013-May/000139.html new file mode 100644 index 00000000..464e9fe8 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000139.html @@ -0,0 +1,77 @@ + + + + [99s-extend] SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] SOLVED -- Re: "access.log" for Cowboy

+ Adam Rutkowski + hq at mtod.org +
+ Wed May 15 13:56:09 CEST 2013 +

+
+ +
+On 15 May 2013, at 13:40, Ivan Uemlianin wrote:
+
+> Thanks!  I got that working.
+> 
+> When I start cowboy, I call
+> 
+>  {ok, Trace} = lager:trace_file("path/to//access.log",
+>                                [{type, access}]),
+> 
+> When you say
+> 
+> > Since 353dd21fde tracing is configurable.
+> 
+> Do you mean the above could go in a .config file?  I haven't found anything to that effect.  I'll keep looking.
+
+See https://github.com/basho/lager/pull/134
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000140.html b/_build/static/archives/extend/2013-May/000140.html new file mode 100644 index 00000000..069fc47a --- /dev/null +++ b/_build/static/archives/extend/2013-May/000140.html @@ -0,0 +1,134 @@ + + + + [99s-extend] SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] SOLVED -- Re: "access.log" for Cowboy

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Wed May 15 14:43:28 CEST 2013 +

+
+ +
Thanks for this.  I've tried it.  It seems to be adding a trace to an 
+already existing log file (which is already handling log messagse of a 
+certain level).  e.g., it uses lager:trace not lager:trace_file.
+
+I can't set it up so the trace file receives *only* trace messages.  I'l 
+revert to the lager:trace_file call.
+
+Best wishes
+
+Ivan
+
+
+Below is the config I've been using.
+
+  {lager, [
+           {handlers,
+	   [
+	    {lager_console_backend, info},
+	    {lager_file_backend,
+	     [
+	      [{file, "log/error.log"}, {level, error},
+                {size, 10485760},
+	       {date, "$D0"}, {count, 5}],
+	      [{file, "log/console.log"}, {level, info},
+                {size, 10485760},
+	       {date, "$D0"}, {count, 5}],
+	      [{file, "log/access.log"},
+                {size, 10485760},
+	       {date, "$D0"}, {count, 5}]
+	     ]}
+	   ]},
+	  {traces,
+	   [
+	    {{lager_file_backend, "log/access.log"},
+              [{type, access}], debug}
+	   ]}
+          ]},
+
+
+On 15/05/2013 12:56, Adam Rutkowski wrote:
+>
+> On 15 May 2013, at 13:40, Ivan Uemlianin wrote:
+>
+>> Thanks!  I got that working.
+>>
+>> When I start cowboy, I call
+>>
+>>   {ok, Trace} = lager:trace_file("path/to//access.log",
+>>                                 [{type, access}]),
+>>
+>> When you say
+>>
+>>> Since 353dd21fde tracing is configurable.
+>>
+>> Do you mean the above could go in a .config file?  I haven't found anything to that effect.  I'll keep looking.
+>
+> See https://github.com/basho/lager/pull/134
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000141.html b/_build/static/archives/extend/2013-May/000141.html new file mode 100644 index 00000000..3c53090a --- /dev/null +++ b/_build/static/archives/extend/2013-May/000141.html @@ -0,0 +1,95 @@ + + + + [99s-extend] SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] SOLVED -- Re: "access.log" for Cowboy

+ Adam Rutkowski + hq at mtod.org +
+ Wed May 15 15:33:28 CEST 2013 +

+
+ +
+On 15 May 2013, at 14:43, Ivan Uemlianin wrote:
+
+> Thanks for this.  I've tried it.  It seems to be adding a trace to an already existing log file (which is already handling log messagse of a certain level).  e.g., it uses lager:trace not lager:trace_file.
+> 
+> I can't set it up so the trace file receives *only* trace messages.  I'l revert to the lager:trace_file call.
+
+The following setup works for me:
+
+[
+
+{lager, [
+    {colored, true},
+    {handlers, [
+      {lager_console_backend, info},
+      {lager_file_backend, [
+                {file, "log/error.log"}, {level, error}, {size, 10485760}, {date, "$D0"}, {count, 5}]},
+      {lager_file_backend, [
+                {file, "log/cdr.log"}, {level, none}, {size, 1000}, {date, "$D0"}, {count, 5}]}
+      ]},
+    {crash_log, "log/crash.log"},
+
+
+{traces,
+[
+{{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug}
+]}
+
+]}
+
+
+].
+
+Hope it helps, take care.
+A.
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000142.html b/_build/static/archives/extend/2013-May/000142.html new file mode 100644 index 00000000..2ecf2e4b --- /dev/null +++ b/_build/static/archives/extend/2013-May/000142.html @@ -0,0 +1,121 @@ + + + + [99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" for Cowboy

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Wed May 15 15:47:05 CEST 2013 +

+
+ +
Thanks!  That works for me too: it was the "{level, none}" that did it. 
+(I've also spruced up my syntax for lager 2.*)
+
+Thanks for your help and patience.
+
+Ivan
+
+
+On 15/05/2013 14:33, Adam Rutkowski wrote:
+>
+> On 15 May 2013, at 14:43, Ivan Uemlianin wrote:
+>
+>> Thanks for this.  I've tried it.  It seems to be adding a trace to an already existing log file (which is already handling log messagse of a certain level).  e.g., it uses lager:trace not lager:trace_file.
+>>
+>> I can't set it up so the trace file receives *only* trace messages.  I'l revert to the lager:trace_file call.
+>
+> The following setup works for me:
+>
+> [
+>
+> {lager, [
+>      {colored, true},
+>      {handlers, [
+>        {lager_console_backend, info},
+>        {lager_file_backend, [
+>                  {file, "log/error.log"}, {level, error}, {size, 10485760}, {date, "$D0"}, {count, 5}]},
+>        {lager_file_backend, [
+>                  {file, "log/cdr.log"}, {level, none}, {size, 1000}, {date, "$D0"}, {count, 5}]}
+>        ]},
+>      {crash_log, "log/crash.log"},
+>
+>
+> {traces,
+> [
+> {{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug}
+> ]}
+>
+> ]}
+>
+>
+> ].
+>
+> Hope it helps, take care.
+> A.
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000143.html b/_build/static/archives/extend/2013-May/000143.html new file mode 100644 index 00000000..5e6fe91b --- /dev/null +++ b/_build/static/archives/extend/2013-May/000143.html @@ -0,0 +1,102 @@ + + + + [99s-extend] question to rest handler + + + + + + + + + + +

[99s-extend] question to rest handler

+ Witali Monastyrjow + chatlano at googlemail.com +
+ Fri May 17 17:41:11 CEST 2013 +

+
+ +
Hi all,
+
+I am learning cowboy by building a small application with rest interface.
+I have a hello_world rest handler and I want to implement POST method that
+returns
+json as response to a client. Therefor I implemented  callbacks
+allowed_methods,
+content_types_accepted and hello_json. The docu says user callbacks can
+return {Value, Req, State} and also can return {halt, Req, State}. It is
+not really clear
+what that Value should be. So I tried {ok, Req, State} and {true, Req,
+State} and with
+both values I have
+
+=ERROR REPORT==== 11-May-2013::16:06:40 ===
+Error in process <0.6649.0> with exit value:
+{function_clause,[{cowboy_req,reply,[303,....
+
+and client gets right response. If I use {halt, Req, State} the client gets
+right response too
+and there is no errors. So, Is it right way to write a POST callback and
+what Values can
+be used for user callbacks? I write my code below.
+
+amike,
+Vitali
+
+allowed_methods(Req, State) ->
+{[<<"POST">>, <<"DELETE">>], Req, State}.
+
+content_types_accepted(Req, State) ->
+{[
+    {{<<"application">>, <<"x-www-form-urlencoded">>, []}, hello_json}
+ ], Req, State}.
+
+hello_json(Req, State) ->
+{ok, Req2} = cowboy_req:reply(200, [{<<"content-type">>,
+<<"application/json">>} ], <<"{\"rest\": \"Hello World!\"}">>, Req),
+{halt, Req2, State}.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130517/629071b8/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000144.html b/_build/static/archives/extend/2013-May/000144.html new file mode 100644 index 00000000..bab09432 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000144.html @@ -0,0 +1,120 @@ + + + + [99s-extend] question to rest handler + + + + + + + + + + +

[99s-extend] question to rest handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri May 17 18:15:47 CEST 2013 +

+
+ +
All the callbacks are explained in 
+http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest
+
+In your case take a special look at content_types_accepted.
+
+On 05/17/2013 05:41 PM, Witali Monastyrjow wrote:
+> Hi all,
+>
+> I am learning cowboy by building a small application with rest interface.
+> I have a hello_world rest handler and I want to implement POST method
+> that returns
+> json as response to a client. Therefor I implemented  callbacks
+> allowed_methods,
+> content_types_accepted and hello_json. The docu says user callbacks can
+> return {Value, Req, State} and also can return {halt, Req, State}. It is
+> not really clear
+> what that Value should be. So I tried {ok, Req, State} and {true, Req,
+> State} and with
+> both values I have
+>
+> =ERROR REPORT==== 11-May-2013::16:06:40 ===
+> Error in process <0.6649.0> with exit value:
+> {function_clause,[{cowboy_req,reply,[303,....
+>
+> and client gets right response. If I use {halt, Req, State} the client
+> gets right response too
+> and there is no errors. So, Is it right way to write a POST callback and
+> what Values can
+> be used for user callbacks? I write my code below.
+>
+> amike,
+> Vitali
+>
+> allowed_methods(Req, State) ->
+> {[<<"POST">>, <<"DELETE">>], Req, State}.
+>
+> content_types_accepted(Req, State) ->
+> {[
+>      {{<<"application">>, <<"x-www-form-urlencoded">>, []}, hello_json}
+>   ], Req, State}.
+>
+> hello_json(Req, State) ->
+> {ok, Req2} = cowboy_req:reply(200, [{<<"content-type">>,
+> <<"application/json">>} ], <<"{\"rest\": \"Hello World!\"}">>, Req),
+> {halt, Req2, State}.
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000145.html b/_build/static/archives/extend/2013-May/000145.html new file mode 100644 index 00000000..5f585005 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000145.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Cowboy Middleware and websockets + + + + + + + + + + +

[99s-extend] Cowboy Middleware and websockets

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Mon May 20 03:01:24 CEST 2013 +

+
+ +
I want to write a cowboy middleware that works only on non-websocket
+requests. How can I achieve this? Is there any way that I ask the Request
+if this is a websocket request?
+
+Thank you
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130519/db7f08ab/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000146.html b/_build/static/archives/extend/2013-May/000146.html new file mode 100644 index 00000000..12746340 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000146.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Cowboy Middleware and websockets + + + + + + + + + + +

[99s-extend] Cowboy Middleware and websockets

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Mon May 20 13:53:33 CEST 2013 +

+
+ +
On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel <edgurgel at gmail.com> wrote:
+
+> I want to write a cowboy middleware that works only on non-websocket
+> requests. How can I achieve this? Is there any way that I ask the Request
+> if this is a websocket request?
+>
+>
+Thinking about my question, I see that the middleware (if it's behind the
+cowboy_handler) can't figure if the connection will be upgraded or not.
+
+Still, it would be cool if I could select which routes will be applied to
+my middleware.
+
+Am I making any sense? :)
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130520/3cc045e8/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000147.html b/_build/static/archives/extend/2013-May/000147.html new file mode 100644 index 00000000..ed46fddf --- /dev/null +++ b/_build/static/archives/extend/2013-May/000147.html @@ -0,0 +1,88 @@ + + + + [99s-extend] Cowboy Middleware and websockets + + + + + + + + + + +

[99s-extend] Cowboy Middleware and websockets

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon May 20 15:25:53 CEST 2013 +

+
+ +
On 05/20/2013 01:53 PM, Eduardo Gurgel wrote:
+>
+>
+>
+> On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel <edgurgel at gmail.com
+> <mailto:edgurgel at gmail.com>> wrote:
+>
+>     I want to write a cowboy middleware that works only on non-websocket
+>     requests. How can I achieve this? Is there any way that I ask the
+>     Request if this is a websocket request?
+>
+>
+> Thinking about my question, I see that the middleware (if it's behind
+> the cowboy_handler) can't figure if the connection will be upgraded or not.
+>
+> Still, it would be cool if I could select which routes will be applied
+> to my middleware.
+
+You have the Req which can help you do things based on host or path, and 
+you also have the environment, which contains the name of the handler 
+that's gonna be used if you execute your middleware after cowboy_router.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000148.html b/_build/static/archives/extend/2013-May/000148.html new file mode 100644 index 00000000..5c85e287 --- /dev/null +++ b/_build/static/archives/extend/2013-May/000148.html @@ -0,0 +1,96 @@ + + + + [99s-extend] Cowboy Middleware and websockets + + + + + + + + + + +

[99s-extend] Cowboy Middleware and websockets

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Mon May 20 16:06:20 CEST 2013 +

+
+ +
On Mon, May 20, 2013 at 10:25 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 05/20/2013 01:53 PM, Eduardo Gurgel wrote:
+>
+>>
+>>
+>>
+>> On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel <edgurgel at gmail.com
+>> <mailto:edgurgel at gmail.com>> wrote:
+>>
+>>     I want to write a cowboy middleware that works only on non-websocket
+>>     requests. How can I achieve this? Is there any way that I ask the
+>>     Request if this is a websocket request?
+>>
+>>
+>> Thinking about my question, I see that the middleware (if it's behind
+>> the cowboy_handler) can't figure if the connection will be upgraded or
+>> not.
+>>
+>> Still, it would be cool if I could select which routes will be applied
+>> to my middleware.
+>>
+>
+> You have the Req which can help you do things based on host or path, and
+> you also have the environment, which contains the name of the handler
+> that's gonna be used if you execute your middleware after cowboy_router.
+>
+>
+Perfect! The environment can help me :)
+
+
+Thank you, again!
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130520/5134ba32/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/000149.html b/_build/static/archives/extend/2013-May/000149.html new file mode 100644 index 00000000..1fdc9b9e --- /dev/null +++ b/_build/static/archives/extend/2013-May/000149.html @@ -0,0 +1,141 @@ + + + + [99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" for Cowboy + + + + + + + + + + +

[99s-extend] REALLY SOLVED -- Re: SOLVED -- Re: "access.log" for Cowboy

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Mon May 20 20:54:20 CEST 2013 +

+
+ +
Would there be any interest in an access_combined log format?
+
+http://httpd.apache.org/docs/2.2/logs.html
+
+
+
+On 5/15/13 9:47 AM, "Ivan Uemlianin" <ivan at llaisdy.com> wrote:
+
+>Thanks!  That works for me too: it was the "{level, none}" that did it.
+>(I've also spruced up my syntax for lager 2.*)
+>
+>Thanks for your help and patience.
+>
+>Ivan
+>
+>
+>On 15/05/2013 14:33, Adam Rutkowski wrote:
+>>
+>> On 15 May 2013, at 14:43, Ivan Uemlianin wrote:
+>>
+>>> Thanks for this.  I've tried it.  It seems to be adding a trace to an
+>>>already existing log file (which is already handling log messagse of a
+>>>certain level).  e.g., it uses lager:trace not lager:trace_file.
+>>>
+>>> I can't set it up so the trace file receives *only* trace messages.
+>>>I'l revert to the lager:trace_file call.
+>>
+>> The following setup works for me:
+>>
+>> [
+>>
+>> {lager, [
+>>      {colored, true},
+>>      {handlers, [
+>>        {lager_console_backend, info},
+>>        {lager_file_backend, [
+>>                  {file, "log/error.log"}, {level, error}, {size,
+>>10485760}, {date, "$D0"}, {count, 5}]},
+>>        {lager_file_backend, [
+>>                  {file, "log/cdr.log"}, {level, none}, {size, 1000},
+>>{date, "$D0"}, {count, 5}]}
+>>        ]},
+>>      {crash_log, "log/crash.log"},
+>>
+>>
+>> {traces,
+>> [
+>> {{lager_file_backend, "log/cdr.log"}, [{type, cdr}], debug}
+>> ]}
+>>
+>> ]}
+>>
+>>
+>> ].
+>>
+>> Hope it helps, take care.
+>> A.
+>>
+>
+>-- 
+>============================================================
+>Ivan A. Uemlianin PhD
+>Llaisdy
+>Speech Technology Research and Development
+>
+>                     ivan at llaisdy.com
+>                      www.llaisdy.com
+>                          llaisdy.wordpress.com
+>               github.com/llaisdy
+>                      www.linkedin.com/in/ivanuemlianin
+>
+>                         festina lente
+>============================================================
+>_______________________________________________
+>Extend mailing list
+>Extend at lists.ninenines.eu
+>http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-May/author.html b/_build/static/archives/extend/2013-May/author.html new file mode 100644 index 00000000..c42f6f2d --- /dev/null +++ b/_build/static/archives/extend/2013-May/author.html @@ -0,0 +1,157 @@ + + + + The Extend May 2013 Archive by author + + + + + +

May 2013 Archives by author

+ +

Starting: Mon May 6 04:23:00 CEST 2013
+ Ending: Mon May 20 20:54:20 CEST 2013
+ Messages: 22

+

+

+ Last message date: + Mon May 20 20:54:20 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-May/date.html b/_build/static/archives/extend/2013-May/date.html new file mode 100644 index 00000000..4929ec56 --- /dev/null +++ b/_build/static/archives/extend/2013-May/date.html @@ -0,0 +1,157 @@ + + + + The Extend May 2013 Archive by date + + + + + +

May 2013 Archives by date

+ +

Starting: Mon May 6 04:23:00 CEST 2013
+ Ending: Mon May 20 20:54:20 CEST 2013
+ Messages: 22

+

+

+ Last message date: + Mon May 20 20:54:20 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-May/index.html b/_build/static/archives/extend/2013-May/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-May/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-May/subject.html b/_build/static/archives/extend/2013-May/subject.html new file mode 100644 index 00000000..6455fdac --- /dev/null +++ b/_build/static/archives/extend/2013-May/subject.html @@ -0,0 +1,157 @@ + + + + The Extend May 2013 Archive by subject + + + + + +

May 2013 Archives by subject

+ +

Starting: Mon May 6 04:23:00 CEST 2013
+ Ending: Mon May 20 20:54:20 CEST 2013
+ Messages: 22

+

+

+ Last message date: + Mon May 20 20:54:20 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-May/thread.html b/_build/static/archives/extend/2013-May/thread.html new file mode 100644 index 00000000..0fde2465 --- /dev/null +++ b/_build/static/archives/extend/2013-May/thread.html @@ -0,0 +1,201 @@ + + + + The Extend May 2013 Archive by thread + + + + + +

May 2013 Archives by thread

+ +

Starting: Mon May 6 04:23:00 CEST 2013
+ Ending: Mon May 20 20:54:20 CEST 2013
+ Messages: 22

+

+

+ Last message date: + Mon May 20 20:54:20 CEST 2013
+ Archived on: Wed May 28 18:41:44 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-November.txt b/_build/static/archives/extend/2013-November.txt new file mode 100644 index 00000000..22cc30d6 --- /dev/null +++ b/_build/static/archives/extend/2013-November.txt @@ -0,0 +1,619 @@ +From essen at ninenines.eu Thu Nov 14 17:23:36 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 14 Nov 2013 17:23:36 +0100 +Subject: [99s-extend] Cowboy and Ranch 0.9.0 released +Message-ID: <5284F908.9000605@ninenines.eu> + +Hello shiny people, + +Cowboy 0.9.0 has been released. Ranch 0.9.0 has been released too! So +let's start with that. + +Ranch 0.9.0 is just stability improvements, better error reporting and a +couple new SSL options. + +Cowboy 0.9.0 is using it of course, and also has official SPDY support +(documented and everything!), a revamped cowboy_static (built-in +mimetypes support, and also documented), tons of additions to the guide, +tons of user patches and other changes you can find here: + + * https://github.com/extend/cowboy/blob/master/CHANGELOG.md + +Which reminds me, I want to thank all 70 awesome contributors (myself +included) that make the Cowboy project so fun to work on! So, thank you! + +When upgrading, please be aware that: + + * A dependency has been added, cowlib + * Various undocumented functions have been moved to cowlib + * The options for cowboy_static changed a lot, so read the guide + * You need to set ERL_LIBS or equivalent for cowboy_static to find +your private directory now + +You can find the updated guide on http://ninenines.eu BUT do note that +I'm migrating the site so if you do not see "Contribute to this site" in +the bottom left next to "Contact", then you are on the old version and +should probably head to github for your documentation needs, or use the +files in your clone directly. I also have improvements left to make to +the site to make navigating documentation easier, so stay tuned! + +Speaking of the guide, now all the examples, but also the getting +started chapter of the guide, are releases. I am hopeful that this will +make more people use releases by default instead of an awful start.sh +script. + +For details on what's coming up next, see the ROADMAP. Next step (0.10) +is finishing the request body work, fixing some timeout issues and +adding proper multipart support for both requests and responses. This +will be the last significant step before 1.0. I have hopes that all this +will be ready around the time R17 is released. + +So yeah, enjoy! And as always please forward any feedback, especially +related to the user guide as this is my main focus now. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From barcojie at gmail.com Fri Nov 15 02:57:17 2013 +From: barcojie at gmail.com (Barco You) +Date: Fri, 15 Nov 2013 09:57:17 +0800 +Subject: [99s-extend] [erlang-questions] Cowboy and Ranch 0.9.0 released +In-Reply-To: <5284F908.9000605@ninenines.eu> +References: <5284F908.9000605@ninenines.eu> +Message-ID: + +Very excited to hear of this. Cowboy is very good to use. +On Nov 15, 2013 12:23 AM, "Lo?c Hoguin" wrote: + +> Hello shiny people, +> +> Cowboy 0.9.0 has been released. Ranch 0.9.0 has been released too! So +> let's start with that. +> +> Ranch 0.9.0 is just stability improvements, better error reporting and a +> couple new SSL options. +> +> Cowboy 0.9.0 is using it of course, and also has official SPDY support +> (documented and everything!), a revamped cowboy_static (built-in mimetypes +> support, and also documented), tons of additions to the guide, tons of user +> patches and other changes you can find here: +> +> * https://github.com/extend/cowboy/blob/master/CHANGELOG.md +> +> Which reminds me, I want to thank all 70 awesome contributors (myself +> included) that make the Cowboy project so fun to work on! So, thank you! +> +> When upgrading, please be aware that: +> +> * A dependency has been added, cowlib +> * Various undocumented functions have been moved to cowlib +> * The options for cowboy_static changed a lot, so read the guide +> * You need to set ERL_LIBS or equivalent for cowboy_static to find your +> private directory now +> +> You can find the updated guide on http://ninenines.eu BUT do note that +> I'm migrating the site so if you do not see "Contribute to this site" in +> the bottom left next to "Contact", then you are on the old version and +> should probably head to github for your documentation needs, or use the +> files in your clone directly. I also have improvements left to make to the +> site to make navigating documentation easier, so stay tuned! +> +> Speaking of the guide, now all the examples, but also the getting started +> chapter of the guide, are releases. I am hopeful that this will make more +> people use releases by default instead of an awful start.sh script. +> +> For details on what's coming up next, see the ROADMAP. Next step (0.10) is +> finishing the request body work, fixing some timeout issues and adding +> proper multipart support for both requests and responses. This will be the +> last significant step before 1.0. I have hopes that all this will be ready +> around the time R17 is released. +> +> So yeah, enjoy! And as always please forward any feedback, especially +> related to the user guide as this is my main focus now. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From akonsu at gmail.com Sun Nov 17 17:43:56 2013 +From: akonsu at gmail.com (akonsu) +Date: Sun, 17 Nov 2013 11:43:56 -0500 +Subject: [99s-extend] concurrently calling cowboy_req:chunk +Message-ID: + +Hello, + +if I call cowboy_req:chunk on the same Req from several processes that run +simultaneously, I am guaranteed that the chunks that these processes write +to the socket will not interleave with each other? + +thanks +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From Kevin.Brown at turner.com Wed Nov 20 22:30:37 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Wed, 20 Nov 2013 21:30:37 +0000 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock +In-Reply-To: +Message-ID: + +Cowfolk , + + +Just upgraded to cowboy 0.9.0 from 0.8.7. Seeing this cowboy_clock error on all REST requests. Anyone seen it? Investigating now. + +{badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]} + + + +=ERROR REPORT==== 20-Nov-2013::16:24:59 === + +Ranch listener http had connection process started with cowboy_protocol:start_link/4 at <0.326.0> exit with reason: {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]},{cowboy_clock,rfc1123,0,[{file,"src/cowboy_clock.erl"},{line,62}]},{cowboy_req,reply_no_compress,8,[{file,"src/cowboy_req.erl"},{line,1056}]},{cowboy_req,reply,4,[{file,"src/cowboy_req.erl"},{line,1009}]},{cowboy_rest,respond,3,[{file,"src/cowboy_rest.erl"},{line,996}]},{cowboy_rest,set_resp_body,2,[{file,"src/cowboy_rest.erl"},{line,876}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} + + +-kb + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Nov 20 22:55:57 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 20 Nov 2013 22:55:57 +0100 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element + cowboy_clock +In-Reply-To: +References: +Message-ID: <528D2FED.40309@ninenines.eu> + +On 11/20/2013 10:30 PM, Brown, Kevin wrote: +> Cowfolk , +> +> +> Just upgraded to cowboy 0.9.0 from 0.8.7. Seeing +> this cowboy_clock error on all REST requests. Anyone seen it? +> Investigating now. +> +> {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]} +> +> +> =ERROR REPORT==== 20-Nov-2013::16:24:59 === +> +> Ranch listener http had connection process started with +> cowboy_protocol:start_link/4 at <0.326.0> exit with reason: +> {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]},{cowboy_clock,rfc1123,0,[{file,"src/cowboy_clock.erl"},{line,62}]},{cowboy_req,reply_no_compress,8,[{file,"src/cowboy_req.erl"},{line,1056}]},{cowboy_req,reply,4,[{file,"src/cowboy_req.erl"},{line,1009}]},{cowboy_rest,respond,3,[{file,"src/cowboy_rest.erl"},{line,996}]},{cowboy_rest,set_resp_body,2,[{file,"src/cowboy_rest.erl"},{line,876}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} + +That hasn't changed. + +Chances are when you upgraded, somehow, the ets table or the key was +deleted. Table is cowboy_clock and key rfc1123 if you want to check quickly. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Kevin.Brown at turner.com Wed Nov 20 23:11:10 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Wed, 20 Nov 2013 22:11:10 +0000 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element + cowboy_clock +In-Reply-To: +Message-ID: + +cowboy_clock not started. Not sure why that is, but.. + +From: , Kevin > +Date: Wednesday, November 20, 2013 at 4:29 PM +To: "extend at lists.ninenines.eu" > +Subject: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Nov 20 23:21:01 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 20 Nov 2013 23:21:01 +0100 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element + cowboy_clock +In-Reply-To: +References: +Message-ID: <528D35CD.1010300@ninenines.eu> + +On 11/20/2013 11:11 PM, Brown, Kevin wrote: +> cowboy_clock not started. Not sure why that is, but.. + +Sounds like the Cowboy application didn't start then. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Kevin.Brown at turner.com Wed Nov 20 23:32:09 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Wed, 20 Nov 2013 22:32:09 +0000 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element + cowboy_clock +In-Reply-To: +Message-ID: + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From Kevin.Brown at turner.com Wed Nov 20 23:34:27 2013 +From: Kevin.Brown at turner.com (Brown, Kevin) +Date: Wed, 20 Nov 2013 22:34:27 +0000 +Subject: [99s-extend] cowboy 0.9.0: badarg ets:lookup_element + cowboy_clock +In-Reply-To: +Message-ID: + +Because I wasn?t starting cow_lib. Don?t ask. + +From: , Kevin > +Date: Wednesday, November 20, 2013 at 5:11 PM +To: "extend at lists.ninenines.eu" > +Subject: Re: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + +cowboy_clock not started. Not sure why that is, but.. + +From: , Kevin > +Date: Wednesday, November 20, 2013 at 4:29 PM +To: "extend at lists.ninenines.eu" > +Subject: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From janwillem.luiten at gmail.com Thu Nov 21 10:11:43 2013 +From: janwillem.luiten at gmail.com (J.W. Luiten) +Date: Thu, 21 Nov 2013 10:11:43 +0100 +Subject: [99s-extend] Cowboy and stable +Message-ID: <9D6FADA9-0BF9-4E9A-BBC1-8149E154FC6D@gmail.com> + +Hello, + +For a Cowboy-based project I?m trying to use stable (dvv/stable, written by Vladimir Dronnikov). I keep running into problems. I contacted Vladimir and he stated that the current version of stable was compatible with Cowboy 0.8 and that he didn?t have the time to keep up with new cowboy releases. Is any of the list members using stable in a cowboy based project? + +Kind regards, + +Jan Willem Luiten +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ivan at llaisdy.com Thu Nov 21 10:20:09 2013 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Thu, 21 Nov 2013 09:20:09 +0000 +Subject: [99s-extend] Cowboy and stable +In-Reply-To: <9D6FADA9-0BF9-4E9A-BBC1-8149E154FC6D@gmail.com> +References: <9D6FADA9-0BF9-4E9A-BBC1-8149E154FC6D@gmail.com> +Message-ID: <528DD049.7080708@llaisdy.com> + +IIRC There were major changes around 0.8.3-8.4 when parts of the api +changed. I haven't upgraded to 0.9 yet but I imagine there will be +further changes there (e.g., there is a new dependency: cow_lib). + +Ivan + + +On 21/11/2013 09:11, J.W. Luiten wrote: +> Hello, +> +> For a Cowboy-based project I?m trying to use stable (dvv/stable +> , written by Vladimir Dronnikov). I keep +> running into problems. I contacted Vladimir and he stated that the +> current version of stable was compatible with Cowboy 0.8 and that he +> didn?t have the time to keep up with new cowboy releases. Is any of the +> list members using stable in a cowboy based project? +> +> Kind regards, +> +> Jan Willem Luiten +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From samset at wanadoo.fr Thu Nov 21 15:58:09 2013 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 21 Nov 2013 15:58:09 +0100 +Subject: [99s-extend] multiple handler instances +Message-ID: + +Hi, + +I have an issue. + +I'd like to start 2 http handler in the same application +So i did to cowboy:start_http call + different port + dispatch route sets in the supervisor init method. + +When the application starts there is no error but when i look the network tables i only see the binding for the first call. +If i comment out the first call i see the second binding. + +Is there any limitation ? +If yes any workaround to share ? + +Thank you. + + +Samir Sow + +From samset at wanadoo.fr Thu Nov 21 16:23:43 2013 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 21 Nov 2013 16:23:43 +0100 +Subject: [99s-extend] Fwd: multiple handler instances +References: +Message-ID: + + +Solved. +I overlooked to have different refs for each call. + +Samir Sow + +Begin forwarded message: + +> From: Samir Sow +> Date: 21 novembre 2013 15:58:09 HNEC +> To: extend at lists.ninenines.eu +> Subject: multiple handler instances +> +> Hi, +> +> I have an issue. +> +> I'd like to start 2 http handler in the same application +> So i did to cowboy:start_http call + different port + dispatch route sets in the supervisor init method. +> +> When the application starts there is no error but when i look the network tables i only see the binding for the first call. +> If i comment out the first call i see the second binding. +> +> Is there any limitation ? +> If yes any workaround to share ? +> +> Thank you. +> +> +> Samir Sow + + + +From essen at ninenines.eu Fri Nov 22 18:48:50 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 22 Nov 2013 18:48:50 +0100 +Subject: [99s-extend] Server migration +Message-ID: <528F9902.6080704@ninenines.eu> + +Hello, + +I'll be migrating the mailing lists to a new server as of right now. +They should be back whenever the DNS updates for you. + +In the meantime, if you have a really important question, please check +the IRC channel #ninenines on Freenode. Service should be back for +everyone on Monday. + +Thanks for your comprehension. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Sun Nov 24 12:27:09 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 24 Nov 2013 12:27:09 +0100 +Subject: [99s-extend] Checking if new server works properly +Message-ID: <5291E28D.9040206@ninenines.eu> + +Test 1 2 3. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lloyd at writersglen.com Sat Nov 23 04:13:30 2013 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Fri, 22 Nov 2013 22:13:30 -0500 (EST) +Subject: [99s-extend] erlang.mk vs. rebar +Message-ID: <1385176410.168318460@apps.rackspace.com> + + +Hello, + +Does erlang.mk replace rebar? + +Thanks, + +LRP + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Sun Nov 24 14:07:43 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 24 Nov 2013 14:07:43 +0100 +Subject: [99s-extend] erlang.mk vs. rebar +In-Reply-To: <1385176410.168318460@apps.rackspace.com> +References: <1385176410.168318460@apps.rackspace.com> +Message-ID: <5291FA1F.70300@ninenines.eu> + +erlang.mk can replace rebar, yes. + +On 11/23/2013 04:13 AM, lloyd at writersglen.com wrote: +> Hello, +> +> Does erlang.mk replace rebar? +> +> Thanks, + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Fri Nov 22 20:49:20 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 22 Nov 2013 20:49:20 +0100 +Subject: [99s-extend] Server migration +In-Reply-To: <528F9902.6080704@ninenines.eu> +References: <528F9902.6080704@ninenines.eu> +Message-ID: <528FB540.9090307@ninenines.eu> + +On 11/22/2013 06:48 PM, Lo?c Hoguin wrote: +> Hello, +> +> I'll be migrating the mailing lists to a new server as of right now. +> They should be back whenever the DNS updates for you. +> +> In the meantime, if you have a really important question, please check +> the IRC channel #ninenines on Freenode. Service should be back for +> everyone on Monday. +> +> Thanks for your comprehension. + +The migration is a success. Please check http://lists.ninenines.eu to +know if service is back for you before sending an email. The old server +is refusing all emails now. Thanks! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Nov 27 06:35:38 2013 +From: akonsu at gmail.com (akonsu) +Date: Wed, 27 Nov 2013 00:35:38 -0500 +Subject: [99s-extend] error saying that Ranch listener process has terminated +Message-ID: + +Hello, + +I am seeing an error report in my logs: + +=ERROR REPORT==== 27-Nov-2013::00:22:33 === +Ranch listener http had connection process started with +cowboy_protocol:start_link/4 at <0.4803.9> exit with reason: {error,closed} + +looks like this is not worth investigating. can someone please comment on +this error? + +thanks +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From kaveh.shahbazian at gmail.com Wed Nov 27 19:23:09 2013 +From: kaveh.shahbazian at gmail.com (Kaveh Shahbazian) +Date: Wed, 27 Nov 2013 21:53:09 +0330 +Subject: [99s-extend] On a Basic Cowboy Sample +Message-ID: + +Hi; + +A post on this can be found +here(code +on +GitHub ). + +?Are these things this way for a reason? (Because otherwise we I can not +get samples to run.) + +1 - I have to add 'cowboy' to application list in myapp.app.src. +2 - I have to add '{http_port, 9000}' to 'env' in myapp.app.src (where in +the code should I add it?). +3 - I have to explicitly make sure 'cowlib' is started (ok = +application:start(cowlib) and I did not see this anywhere but whitout this, +it won't work). + +Thanks; +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-November/000294.html b/_build/static/archives/extend/2013-November/000294.html new file mode 100644 index 00000000..cc52b5a3 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000294.html @@ -0,0 +1,111 @@ + + + + [99s-extend] Cowboy and Ranch 0.9.0 released + + + + + + + + + + +

[99s-extend] Cowboy and Ranch 0.9.0 released

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Nov 14 17:23:36 CET 2013 +

+
+ +
Hello shiny people,
+
+Cowboy 0.9.0 has been released. Ranch 0.9.0 has been released too! So 
+let's start with that.
+
+Ranch 0.9.0 is just stability improvements, better error reporting and a 
+couple new SSL options.
+
+Cowboy 0.9.0 is using it of course, and also has official SPDY support 
+(documented and everything!), a revamped cowboy_static (built-in 
+mimetypes support, and also documented), tons of additions to the guide, 
+tons of user patches and other changes you can find here:
+
+   *  https://github.com/extend/cowboy/blob/master/CHANGELOG.md
+
+Which reminds me, I want to thank all 70 awesome contributors (myself 
+included) that make the Cowboy project so fun to work on! So, thank you!
+
+When upgrading, please be aware that:
+
+   *  A dependency has been added, cowlib
+   *  Various undocumented functions have been moved to cowlib
+   *  The options for cowboy_static changed a lot, so read the guide
+   *  You need to set ERL_LIBS or equivalent for cowboy_static to find 
+your private directory now
+
+You can find the updated guide on http://ninenines.eu BUT do note that 
+I'm migrating the site so if you do not see "Contribute to this site" in 
+the bottom left next to "Contact", then you are on the old version and 
+should probably head to github for your documentation needs, or use the 
+files in your clone directly. I also have improvements left to make to 
+the site to make navigating documentation easier, so stay tuned!
+
+Speaking of the guide, now all the examples, but also the getting 
+started chapter of the guide, are releases. I am hopeful that this will 
+make more people use releases by default instead of an awful start.sh 
+script.
+
+For details on what's coming up next, see the ROADMAP. Next step (0.10) 
+is finishing the request body work, fixing some timeout issues and 
+adding proper multipart support for both requests and responses. This 
+will be the last significant step before 1.0. I have hopes that all this 
+will be ready around the time R17 is released.
+
+So yeah, enjoy! And as always please forward any feedback, especially 
+related to the user guide as this is my main focus now.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000295.html b/_build/static/archives/extend/2013-November/000295.html new file mode 100644 index 00000000..72359c9f --- /dev/null +++ b/_build/static/archives/extend/2013-November/000295.html @@ -0,0 +1,122 @@ + + + + [99s-extend] [erlang-questions] Cowboy and Ranch 0.9.0 released + + + + + + + + + + +

[99s-extend] [erlang-questions] Cowboy and Ranch 0.9.0 released

+ Barco You + barcojie at gmail.com +
+ Fri Nov 15 02:57:17 CET 2013 +

+
+ +
Very excited to hear of this. Cowboy is very good to use.
+On Nov 15, 2013 12:23 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+> Hello shiny people,
+>
+> Cowboy 0.9.0 has been released. Ranch 0.9.0 has been released too! So
+> let's start with that.
+>
+> Ranch 0.9.0 is just stability improvements, better error reporting and a
+> couple new SSL options.
+>
+> Cowboy 0.9.0 is using it of course, and also has official SPDY support
+> (documented and everything!), a revamped cowboy_static (built-in mimetypes
+> support, and also documented), tons of additions to the guide, tons of user
+> patches and other changes you can find here:
+>
+>   *  https://github.com/extend/cowboy/blob/master/CHANGELOG.md
+>
+> Which reminds me, I want to thank all 70 awesome contributors (myself
+> included) that make the Cowboy project so fun to work on! So, thank you!
+>
+> When upgrading, please be aware that:
+>
+>   *  A dependency has been added, cowlib
+>   *  Various undocumented functions have been moved to cowlib
+>   *  The options for cowboy_static changed a lot, so read the guide
+>   *  You need to set ERL_LIBS or equivalent for cowboy_static to find your
+> private directory now
+>
+> You can find the updated guide on http://ninenines.eu BUT do note that
+> I'm migrating the site so if you do not see "Contribute to this site" in
+> the bottom left next to "Contact", then you are on the old version and
+> should probably head to github for your documentation needs, or use the
+> files in your clone directly. I also have improvements left to make to the
+> site to make navigating documentation easier, so stay tuned!
+>
+> Speaking of the guide, now all the examples, but also the getting started
+> chapter of the guide, are releases. I am hopeful that this will make more
+> people use releases by default instead of an awful start.sh script.
+>
+> For details on what's coming up next, see the ROADMAP. Next step (0.10) is
+> finishing the request body work, fixing some timeout issues and adding
+> proper multipart support for both requests and responses. This will be the
+> last significant step before 1.0. I have hopes that all this will be ready
+> around the time R17 is released.
+>
+> So yeah, enjoy! And as always please forward any feedback, especially
+> related to the user guide as this is my main focus now.
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/listinfo/erlang-questions
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131115/79d7b0ce/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000296.html b/_build/static/archives/extend/2013-November/000296.html new file mode 100644 index 00000000..72ba3c14 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000296.html @@ -0,0 +1,71 @@ + + + + [99s-extend] concurrently calling cowboy_req:chunk + + + + + + + + + + +

[99s-extend] concurrently calling cowboy_req:chunk

+ akonsu + akonsu at gmail.com +
+ Sun Nov 17 17:43:56 CET 2013 +

+
+ +
Hello,
+
+if I call cowboy_req:chunk on the same Req from several processes that run
+simultaneously, I am guaranteed that the chunks that these processes write
+to the socket will not interleave with each other?
+
+thanks
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131117/41119d53/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000297.html b/_build/static/archives/extend/2013-November/000297.html new file mode 100644 index 00000000..69e2c446 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000297.html @@ -0,0 +1,80 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Wed Nov 20 22:30:37 CET 2013 +

+
+ +
Cowfolk ,
+
+
+Just upgraded to cowboy 0.9.0  from 0.8.7.   Seeing this cowboy_clock error on all REST requests.    Anyone seen it?  Investigating now.
+
+{badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]}
+
+
+
+=ERROR REPORT==== 20-Nov-2013::16:24:59 ===
+
+Ranch listener http had connection process started with cowboy_protocol:start_link/4 at <0.326.0> exit with reason: {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]},{cowboy_clock,rfc1123,0,[{file,"src/cowboy_clock.erl"},{line,62}]},{cowboy_req,reply_no_compress,8,[{file,"src/cowboy_req.erl"},{line,1056}]},{cowboy_req,reply,4,[{file,"src/cowboy_req.erl"},{line,1009}]},{cowboy_rest,respond,3,[{file,"src/cowboy_rest.erl"},{line,996}]},{cowboy_rest,set_resp_body,2,[{file,"src/cowboy_rest.erl"},{line,876}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+
+
+-kb
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131120/6c3ab980/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000298.html b/_build/static/archives/extend/2013-November/000298.html new file mode 100644 index 00000000..0eadec5e --- /dev/null +++ b/_build/static/archives/extend/2013-November/000298.html @@ -0,0 +1,88 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Nov 20 22:55:57 CET 2013 +

+
+ +
On 11/20/2013 10:30 PM, Brown, Kevin wrote:
+> Cowfolk ,
+>
+>
+> Just upgraded to cowboy 0.9.0  from 0.8.7.   Seeing
+> this cowboy_clock error on all REST requests.    Anyone seen it?
+>   Investigating now.
+>
+> {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]}
+>
+>
+> =ERROR REPORT==== 20-Nov-2013::16:24:59 ===
+>
+> Ranch listener http had connection process started with
+> cowboy_protocol:start_link/4 at <0.326.0> exit with reason:
+> {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]},{cowboy_clock,rfc1123,0,[{file,"src/cowboy_clock.erl"},{line,62}]},{cowboy_req,reply_no_compress,8,[{file,"src/cowboy_req.erl"},{line,1056}]},{cowboy_req,reply,4,[{file,"src/cowboy_req.erl"},{line,1009}]},{cowboy_rest,respond,3,[{file,"src/cowboy_rest.erl"},{line,996}]},{cowboy_rest,set_resp_body,2,[{file,"src/cowboy_rest.erl"},{line,876}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+
+That hasn't changed.
+
+Chances are when you upgraded, somehow, the ets table or the key was 
+deleted. Table is cowboy_clock and key rfc1123 if you want to check quickly.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000299.html b/_build/static/archives/extend/2013-November/000299.html new file mode 100644 index 00000000..4337d7a2 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000299.html @@ -0,0 +1,71 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Wed Nov 20 23:11:10 CET 2013 +

+
+ +
cowboy_clock not started.    Not sure why that is, but..
+
+From: <Brown>, Kevin <kevin.brown at turner.com<mailto:kevin.brown at turner.com>>
+Date: Wednesday, November 20, 2013 at 4:29 PM
+To: "extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>" <extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>>
+Subject: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131120/82981048/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000300.html b/_build/static/archives/extend/2013-November/000300.html new file mode 100644 index 00000000..3c903af2 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000300.html @@ -0,0 +1,71 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Nov 20 23:21:01 CET 2013 +

+
+ +
On 11/20/2013 11:11 PM, Brown, Kevin wrote:
+> cowboy_clock not started.    Not sure why that is, but..
+
+Sounds like the Cowboy application didn't start then.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000301.html b/_build/static/archives/extend/2013-November/000301.html new file mode 100644 index 00000000..e26597d2 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000301.html @@ -0,0 +1,64 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Wed Nov 20 23:32:09 CET 2013 +

+
+ +
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131120/7808a87a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000302.html b/_build/static/archives/extend/2013-November/000302.html new file mode 100644 index 00000000..f55f8d93 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000302.html @@ -0,0 +1,78 @@ + + + + [99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock + + + + + + + + + + +

[99s-extend] cowboy 0.9.0: badarg ets:lookup_element cowboy_clock

+ Brown, Kevin + Kevin.Brown at turner.com +
+ Wed Nov 20 23:34:27 CET 2013 +

+
+ +
Because I wasn’t starting cow_lib.   Don’t ask.
+
+From: <Brown>, Kevin <kevin.brown at turner.com<mailto:kevin.brown at turner.com>>
+Date: Wednesday, November 20, 2013 at 5:11 PM
+To: "extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>" <extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>>
+Subject: Re: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock
+
+cowboy_clock not started.    Not sure why that is, but..
+
+From: <Brown>, Kevin <kevin.brown at turner.com<mailto:kevin.brown at turner.com>>
+Date: Wednesday, November 20, 2013 at 4:29 PM
+To: "extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>" <extend at lists.ninenines.eu<mailto:extend at lists.ninenines.eu>>
+Subject: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131120/792230f4/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000303.html b/_build/static/archives/extend/2013-November/000303.html new file mode 100644 index 00000000..541aa76b --- /dev/null +++ b/_build/static/archives/extend/2013-November/000303.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Cowboy and stable + + + + + + + + + + +

[99s-extend] Cowboy and stable

+ J.W. Luiten + janwillem.luiten at gmail.com +
+ Thu Nov 21 10:11:43 CET 2013 +

+
+ +
Hello,
+
+For a Cowboy-based project I’m trying to use stable (dvv/stable, written by Vladimir Dronnikov). I keep running into problems. I contacted Vladimir and he stated that the current version of stable was compatible with Cowboy 0.8 and that he didn’t have the time to keep up with new cowboy releases. Is any of the list members using stable in a cowboy based project?
+
+Kind regards,
+
+Jan Willem Luiten
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131121/7d69dbf7/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000304.html b/_build/static/archives/extend/2013-November/000304.html new file mode 100644 index 00000000..3ba3d12a --- /dev/null +++ b/_build/static/archives/extend/2013-November/000304.html @@ -0,0 +1,103 @@ + + + + [99s-extend] Cowboy and stable + + + + + + + + + + +

[99s-extend] Cowboy and stable

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Thu Nov 21 10:20:09 CET 2013 +

+
+ +
IIRC There were major changes around 0.8.3-8.4 when parts of the api 
+changed.  I haven't upgraded to 0.9 yet but I imagine there will be 
+further changes there (e.g., there is a new dependency: cow_lib).
+
+Ivan
+
+
+On 21/11/2013 09:11, J.W. Luiten wrote:
+> Hello,
+>
+> For a Cowboy-based project I’m trying to use stable (dvv/stable
+> <https://github.com/dvv/stable>, written by Vladimir Dronnikov). I keep
+> running into problems. I contacted Vladimir and he stated that the
+> current version of stable was compatible with Cowboy 0.8 and that he
+> didn’t have the time to keep up with new cowboy releases. Is any of the
+> list members using stable in a cowboy based project?
+>
+> Kind regards,
+>
+> Jan Willem Luiten
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000305.html b/_build/static/archives/extend/2013-November/000305.html new file mode 100644 index 00000000..7a5857e7 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000305.html @@ -0,0 +1,77 @@ + + + + [99s-extend] multiple handler instances + + + + + + + + + + +

[99s-extend] multiple handler instances

+ Samir Sow + samset at wanadoo.fr +
+ Thu Nov 21 15:58:09 CET 2013 +

+
+ +
Hi,
+
+I have an issue.
+
+I'd like to start 2 http handler in the same application
+So i did to cowboy:start_http call + different port + dispatch route sets in the supervisor init method.
+
+When the application starts there is no error but when i look the network tables i only see the binding for the first call.
+If i comment out the first call i see the second binding.
+
+Is there any limitation ?
+If yes any workaround to share ?
+
+Thank you.
+
+
+Samir Sow
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000306.html b/_build/static/archives/extend/2013-November/000306.html new file mode 100644 index 00000000..419095ba --- /dev/null +++ b/_build/static/archives/extend/2013-November/000306.html @@ -0,0 +1,92 @@ + + + + [99s-extend] Fwd: multiple handler instances + + + + + + + + + + +

[99s-extend] Fwd: multiple handler instances

+ Samir Sow + samset at wanadoo.fr +
+ Thu Nov 21 16:23:43 CET 2013 +

+
+ +
+Solved.
+I overlooked to have different refs for each call.
+
+Samir Sow
+
+Begin forwarded message:
+
+> From: Samir Sow <samset at wanadoo.fr>
+> Date: 21 novembre 2013 15:58:09 HNEC
+> To: extend at lists.ninenines.eu
+> Subject: multiple handler instances 
+> 
+> Hi,
+> 
+> I have an issue.
+> 
+> I'd like to start 2 http handler in the same application
+> So i did to cowboy:start_http call + different port + dispatch route sets in the supervisor init method.
+> 
+> When the application starts there is no error but when i look the network tables i only see the binding for the first call.
+> If i comment out the first call i see the second binding.
+> 
+> Is there any limitation ?
+> If yes any workaround to share ?
+> 
+> Thank you.
+> 
+> 
+> Samir Sow
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000307.html b/_build/static/archives/extend/2013-November/000307.html new file mode 100644 index 00000000..da1220bc --- /dev/null +++ b/_build/static/archives/extend/2013-November/000307.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Server migration + + + + + + + + + + +

[99s-extend] Server migration

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Nov 22 18:48:50 CET 2013 +

+
+ +
Hello,
+
+I'll be migrating the mailing lists to a new server as of right now. 
+They should be back whenever the DNS updates for you.
+
+In the meantime, if you have a really important question, please check 
+the IRC channel #ninenines on Freenode. Service should be back for 
+everyone on Monday.
+
+Thanks for your comprehension.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000308.html b/_build/static/archives/extend/2013-November/000308.html new file mode 100644 index 00000000..23360416 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000308.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Checking if new server works properly + + + + + + + + + + +

[99s-extend] Checking if new server works properly

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Nov 24 12:27:09 CET 2013 +

+
+ +
Test 1 2 3.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000309.html b/_build/static/archives/extend/2013-November/000309.html new file mode 100644 index 00000000..6be2431c --- /dev/null +++ b/_build/static/archives/extend/2013-November/000309.html @@ -0,0 +1,98 @@ + + + + [99s-extend] erlang.mk vs. rebar + + + + + + + + + + +

[99s-extend] erlang.mk vs. rebar

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Sat Nov 23 04:13:30 CET 2013 +

+
+ +
+Hello,
+ 
+Does erlang.mk replace rebar?
+ 
+Thanks,
+ 
+LRP
+ 
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131122/11ccc1ef/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000310.html b/_build/static/archives/extend/2013-November/000310.html new file mode 100644 index 00000000..4446b901 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000310.html @@ -0,0 +1,75 @@ + + + + [99s-extend] erlang.mk vs. rebar + + + + + + + + + + +

[99s-extend] erlang.mk vs. rebar

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Nov 24 14:07:43 CET 2013 +

+
+ +
erlang.mk can replace rebar, yes.
+
+On 11/23/2013 04:13 AM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> Does erlang.mk replace rebar?
+>
+> Thanks,
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000311.html b/_build/static/archives/extend/2013-November/000311.html new file mode 100644 index 00000000..97347202 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000311.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Server migration + + + + + + + + + + +

[99s-extend] Server migration

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Nov 22 20:49:20 CET 2013 +

+
+ +
On 11/22/2013 06:48 PM, Loïc Hoguin wrote:
+> Hello,
+>
+> I'll be migrating the mailing lists to a new server as of right now.
+> They should be back whenever the DNS updates for you.
+>
+> In the meantime, if you have a really important question, please check
+> the IRC channel #ninenines on Freenode. Service should be back for
+> everyone on Monday.
+>
+> Thanks for your comprehension.
+
+The migration is a success. Please check http://lists.ninenines.eu to 
+know if service is back for you before sending an email. The old server 
+is refusing all emails now. Thanks!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000312.html b/_build/static/archives/extend/2013-November/000312.html new file mode 100644 index 00000000..6a51c677 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000312.html @@ -0,0 +1,76 @@ + + + + [99s-extend] error saying that Ranch listener process has terminated + + + + + + + + + + +

[99s-extend] error saying that Ranch listener process has terminated

+ akonsu + akonsu at gmail.com +
+ Wed Nov 27 06:35:38 CET 2013 +

+
+ +
Hello,
+
+I am seeing an error report in my logs:
+
+=ERROR REPORT==== 27-Nov-2013::00:22:33 ===
+Ranch listener http had connection process started with
+cowboy_protocol:start_link/4 at <0.4803.9> exit with reason: {error,closed}
+
+looks like this is not worth investigating. can someone please comment on
+this error?
+
+thanks
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131127/20905d98/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/000313.html b/_build/static/archives/extend/2013-November/000313.html new file mode 100644 index 00000000..840242b8 --- /dev/null +++ b/_build/static/archives/extend/2013-November/000313.html @@ -0,0 +1,79 @@ + + + + [99s-extend] On a Basic Cowboy Sample + + + + + + + + + + +

[99s-extend] On a Basic Cowboy Sample

+ Kaveh Shahbazian + kaveh.shahbazian at gmail.com +
+ Wed Nov 27 19:23:09 CET 2013 +

+
+ +
Hi;
+
+A post on this can be found
+here<http://dc0d.tumblr.com/post/68278862491/toddling-cowboy-carful-a-windows-on-your-way>(code
+on
+GitHub <https://github.com/dc0d/lucky_luke>).
+
+​Are these things this way for a reason? (Because otherwise we I can not
+get samples to run.)
+
+1 - I have to add 'cowboy' to application list in myapp.app.src.
+2 - I have to add '{http_port, 9000}' to 'env' in myapp.app.src (where in
+the code should I add it?).
+3 - I have to explicitly make sure 'cowlib' is started (ok =
+application:start(cowlib) and I did not see this anywhere but whitout this,
+it won't work).
+
+Thanks;
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131127/11da2202/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-November/author.html b/_build/static/archives/extend/2013-November/author.html new file mode 100644 index 00000000..44497e9a --- /dev/null +++ b/_build/static/archives/extend/2013-November/author.html @@ -0,0 +1,147 @@ + + + + The Extend November 2013 Archive by author + + + + + +

November 2013 Archives by author

+ +

Starting: Thu Nov 14 17:23:36 CET 2013
+ Ending: Wed Nov 27 19:23:09 CET 2013
+ Messages: 20

+

+

+ Last message date: + Wed Nov 27 19:23:09 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-November/date.html b/_build/static/archives/extend/2013-November/date.html new file mode 100644 index 00000000..d4e03dd9 --- /dev/null +++ b/_build/static/archives/extend/2013-November/date.html @@ -0,0 +1,147 @@ + + + + The Extend November 2013 Archive by date + + + + + +

November 2013 Archives by date

+ +

Starting: Thu Nov 14 17:23:36 CET 2013
+ Ending: Wed Nov 27 19:23:09 CET 2013
+ Messages: 20

+

+

+ Last message date: + Wed Nov 27 19:23:09 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-November/index.html b/_build/static/archives/extend/2013-November/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-November/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-November/subject.html b/_build/static/archives/extend/2013-November/subject.html new file mode 100644 index 00000000..471fc527 --- /dev/null +++ b/_build/static/archives/extend/2013-November/subject.html @@ -0,0 +1,147 @@ + + + + The Extend November 2013 Archive by subject + + + + + +

November 2013 Archives by subject

+ +

Starting: Thu Nov 14 17:23:36 CET 2013
+ Ending: Wed Nov 27 19:23:09 CET 2013
+ Messages: 20

+

+

+ Last message date: + Wed Nov 27 19:23:09 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-November/thread.html b/_build/static/archives/extend/2013-November/thread.html new file mode 100644 index 00000000..0d23dbe5 --- /dev/null +++ b/_build/static/archives/extend/2013-November/thread.html @@ -0,0 +1,183 @@ + + + + The Extend November 2013 Archive by thread + + + + + +

November 2013 Archives by thread

+ +

Starting: Thu Nov 14 17:23:36 CET 2013
+ Ending: Wed Nov 27 19:23:09 CET 2013
+ Messages: 20

+

+

+ Last message date: + Wed Nov 27 19:23:09 CET 2013
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-October.txt b/_build/static/archives/extend/2013-October.txt new file mode 100644 index 00000000..4a9176a4 --- /dev/null +++ b/_build/static/archives/extend/2013-October.txt @@ -0,0 +1,2737 @@ +From marcel.meyer at gmail.com Thu Oct 3 07:00:28 2013 +From: marcel.meyer at gmail.com (Marcel Meyer) +Date: Wed, 2 Oct 2013 22:00:28 -0700 +Subject: [99s-extend] websocket_info and RPC +Message-ID: + +Hi there, + +How do I use the websocket infrastructure of cowboy to implement RPC? +It seems like I can talk to the client using websocket_info, but the +response comes in on websocket_handle, all asynchronously. + +Kind regards, +Marcel +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ryankbrown at gmail.com Tue Oct 8 05:55:57 2013 +From: ryankbrown at gmail.com (Ryan Brown) +Date: Mon, 7 Oct 2013 21:55:57 -0600 +Subject: [99s-extend] Problem with cowboy ssl example +Message-ID: + +I was trying to compile and run the ssl_hello_world example in the cowboy +project and am getting the following error at start-up: + +=INFO REPORT==== 7-Oct-2013::21:38:01 === application: ssl_hello_world + exited: {bad_return, {{ssl_hello_world_app,start,[normal,[]]}, + {'EXIT', {{badmatch, {error, + {{shutdown, +{failed_to_start_child,ranch_acceptors_sup, + {{case_clause, {error,{"no such file or +directory","asn1.app"}}}, +[{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]}, + +I can start asn1 from the erl console so I am not sure what I am missing. +Any help is greatly appreciated. + +Best regards. + +-- +-rb +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Oct 8 06:13:04 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 08 Oct 2013 06:13:04 +0200 +Subject: [99s-extend] Problem with cowboy ssl example +In-Reply-To: +References: +Message-ID: <52538650.6030804@ninenines.eu> + +I'm guessing you run an older Erlang which had that issue. Either +upgrade Erlang or add asn1 to the list of apps to include in the release +(and open a ticket for it please so it can be made to work with older +versions). + +On 10/08/2013 05:55 AM, Ryan Brown wrote: +> I was trying to compile and run the ssl_hello_world example in the +> cowboy project and am getting the following error at start-up: +> +> +> =INFO REPORT==== 7-Oct-2013::21:38:01 === +> +> +> application: ssl_hello_world +> +> +> exited: {bad_return, +> +> +> {{ssl_hello_world_app,start,[normal,[]]}, +> +> +> {'EXIT', +> +> +> {{badmatch, +> +> +> {error, +> +> +> {{shutdown, +> +> +> {failed_to_start_child,ranch_acceptors_sup, +> +> +> {{case_clause, +> +> +> {error,{"no such file or directory","asn1.app"}}}, +> +> +> +> [{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]}, +> +> +> I can start asn1 from the erl console so I am not sure what I am +> missing. Any help is greatly appreciated. +> +> Best regards. +> +> -- +> -rb +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From ryankbrown at gmail.com Tue Oct 8 06:24:54 2013 +From: ryankbrown at gmail.com (Ryan Brown) +Date: Mon, 7 Oct 2013 22:24:54 -0600 +Subject: [99s-extend] Problem with cowboy ssl example +In-Reply-To: <52538650.6030804@ninenines.eu> +References: + <52538650.6030804@ninenines.eu> +Message-ID: + +Thanks Lo?c. I am actually running R16B on a macbook OS X 10.8. (I'm +wondering if the Od could have any effect?) + +Best, + +Ryan + + +On Mon, Oct 7, 2013 at 10:13 PM, Lo?c Hoguin wrote: + +> I'm guessing you run an older Erlang which had that issue. Either upgrade +> Erlang or add asn1 to the list of apps to include in the release (and open +> a ticket for it please so it can be made to work with older versions). +> +> +> On 10/08/2013 05:55 AM, Ryan Brown wrote: +> +>> I was trying to compile and run the ssl_hello_world example in the +>> cowboy project and am getting the following error at start-up: +>> +>> +>> =INFO REPORT==== 7-Oct-2013::21:38:01 === +>> +>> +>> application: ssl_hello_world +>> +>> +>> exited: {bad_return, +>> +>> +>> {{ssl_hello_world_app,start,[**normal,[]]}, +>> +>> +>> {'EXIT', +>> +>> +>> {{badmatch, +>> +>> +>> {error, +>> +>> +>> {{shutdown, +>> +>> +>> {failed_to_start_child,ranch_**acceptors_sup, +>> +>> +>> {{case_clause, +>> +>> +>> {error,{"no such file or +>> directory","asn1.app"}}}, +>> +>> +>> +>> [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]}, +>> +>> +>> I can start asn1 from the erl console so I am not sure what I am +>> missing. Any help is greatly appreciated. +>> +>> Best regards. +>> +>> -- +>> -rb +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> + + + +-- +-rb +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ryankbrown at gmail.com Tue Oct 8 17:33:36 2013 +From: ryankbrown at gmail.com (Ryan Brown) +Date: Tue, 8 Oct 2013 09:33:36 -0600 +Subject: [99s-extend] Problem with cowboy ssl example +In-Reply-To: +References: + <52538650.6030804@ninenines.eu> + +Message-ID: + +Just to complete the loop. As would be expected, adding asn1 to the app.src +applications fixes the issue. + +Thank you, + +Ryan + + +On Mon, Oct 7, 2013 at 10:24 PM, Ryan Brown wrote: + +> Thanks Lo?c. I am actually running R16B on a macbook OS X 10.8. (I'm +> wondering if the Od could have any effect?) +> +> Best, +> +> Ryan +> +> +> On Mon, Oct 7, 2013 at 10:13 PM, Lo?c Hoguin wrote: +> +>> I'm guessing you run an older Erlang which had that issue. Either upgrade +>> Erlang or add asn1 to the list of apps to include in the release (and open +>> a ticket for it please so it can be made to work with older versions). +>> +>> +>> On 10/08/2013 05:55 AM, Ryan Brown wrote: +>> +>>> I was trying to compile and run the ssl_hello_world example in the +>>> cowboy project and am getting the following error at start-up: +>>> +>>> +>>> =INFO REPORT==== 7-Oct-2013::21:38:01 === +>>> +>>> +>>> application: ssl_hello_world +>>> +>>> +>>> exited: {bad_return, +>>> +>>> +>>> {{ssl_hello_world_app,start,[**normal,[]]}, +>>> +>>> +>>> {'EXIT', +>>> +>>> +>>> {{badmatch, +>>> +>>> +>>> {error, +>>> +>>> +>>> {{shutdown, +>>> +>>> +>>> {failed_to_start_child,ranch_**acceptors_sup, +>>> +>>> +>>> {{case_clause, +>>> +>>> +>>> {error,{"no such file or +>>> directory","asn1.app"}}}, +>>> +>>> +>>> +>>> [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]}, +>>> +>>> +>>> I can start asn1 from the erl console so I am not sure what I am +>>> missing. Any help is greatly appreciated. +>>> +>>> Best regards. +>>> +>>> -- +>>> -rb +>>> +>>> +>>> ______________________________**_________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/**listinfo/extend +>>> +>>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> +> +> +> +> -- +> -rb +> + + + +-- +-rb +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lee.sylvester at gmail.com Wed Oct 9 15:27:25 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 9 Oct 2013 14:27:25 +0100 +Subject: [99s-extend] Cowboy Calling Hostname +Message-ID: + +Hi, + +When receiving a Cowboy request, is there a way to find out which hostname the user made the request from? I'm using CORS in my REST and Bullet app, where each call can be made through a given account. However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage. + +Thanks, +Lee + + + +From essen at ninenines.eu Wed Oct 9 15:31:04 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 09 Oct 2013 15:31:04 +0200 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: +References: +Message-ID: <52555A98.8090901@ninenines.eu> + +cowboy_req:host/1? + +Please use the nice manual we have now. + + http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req + +On 10/09/2013 03:27 PM, Lee Sylvester wrote: +> Hi, +> +> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from? I'm using CORS in my REST and Bullet app, where each call can be made through a given account. However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage. +> +> Thanks, +> Lee +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From lee.sylvester at gmail.com Wed Oct 9 17:30:21 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 9 Oct 2013 16:30:21 +0100 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: <52555A98.8090901@ninenines.eu> +References: + <52555A98.8090901@ninenines.eu> +Message-ID: <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> + +Thank you. I couldn't work out if that's the host being called from or the host name in the request. For example, a store called things.com makes a request to my service on widgets.net. I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this? + +Thanks, +Lee + +Sent from my iPhone + +> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +> +> cowboy_req:host/1? +> +> Please use the nice manual we have now. +> +> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req +> +>> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +>> Hi, +>> +>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from? I'm using CORS in my REST and Bullet app, where each call can be made through a given account. However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage. +>> +>> Thanks, +>> Lee +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu + + +From essen at ninenines.eu Wed Oct 9 17:32:54 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 09 Oct 2013 17:32:54 +0200 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> +References: + <52555A98.8090901@ninenines.eu> + <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> +Message-ID: <52557726.2060908@ninenines.eu> + +In short: you can't. + +Browsers may send origin/referer/.. headers depending on the type of +request, but you can't rely on them to be real or even just there. + +On 10/09/2013 05:30 PM, Lee Sylvester wrote: +> Thank you. I couldn't work out if that's the host being called from or the host name in the request. For example, a store called things.com makes a request to my service on widgets.net. I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this? +> +> Thanks, +> Lee +> +> Sent from my iPhone +> +>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +>> +>> cowboy_req:host/1? +>> +>> Please use the nice manual we have now. +>> +>> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req +>> +>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +>>> Hi, +>>> +>>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from? I'm using CORS in my REST and Bullet app, where each call can be made through a given account. However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage. +>>> +>>> Thanks, +>>> Lee +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From nathan at nmichaels.org Wed Oct 9 17:51:14 2013 +From: nathan at nmichaels.org (Nathan Michaels) +Date: Wed, 9 Oct 2013 11:51:14 -0400 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: <52557726.2060908@ninenines.eu> +References: + <52555A98.8090901@ninenines.eu> + <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> + <52557726.2060908@ninenines.eu> +Message-ID: + +Is the client making the request to your service on widgets.net because +things.com sent them there, or is things.com making the request directly on +behalf of the client? The first is what Lo?c is talking about. The second +is the source IP of the request, which you can definitely get. + + +On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin wrote: + +> In short: you can't. +> +> Browsers may send origin/referer/.. headers depending on the type of +> request, but you can't rely on them to be real or even just there. +> +> +> On 10/09/2013 05:30 PM, Lee Sylvester wrote: +> +>> Thank you. I couldn't work out if that's the host being called from or +>> the host name in the request. For example, a store called things.commakes a request to my service on +>> widgets.net. I need to see that the request is made FROM things.com for +>> validation purposes. Is it correct that host will provide this? +>> +>> Thanks, +>> Lee +>> +>> Sent from my iPhone +>> +>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +>>> +>>> cowboy_req:host/1? +>>> +>>> Please use the nice manual we have now. +>>> +>>> http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_req +>>> +>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +>>>> Hi, +>>>> +>>>> When receiving a Cowboy request, is there a way to find out which +>>>> hostname the user made the request from? I'm using CORS in my REST and +>>>> Bullet app, where each call can be made through a given account. However, +>>>> I'd like to be able to lock requests for each account to a designated +>>>> hostname to protect that users account usage. +>>>> +>>>> Thanks, +>>>> Lee +>>>> +>>>> ______________________________**_________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> http://lists.ninenines.eu:81/**listinfo/extend +>>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> ______________________________**_________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/**listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lee.sylvester at gmail.com Wed Oct 9 19:28:40 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Wed, 9 Oct 2013 18:28:40 +0100 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: +References: + <52555A98.8090901@ninenines.eu> + <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> + <52557726.2060908@ninenines.eu> + +Message-ID: + +Essentially, the REST service endpoint would be on widgets.net while the clients website, in this case things.com, has a JavaScript that makes an AJAX call to widgets.net. The account on widgets.net for things.com will have the things.com domain registered to its account, so that widgets.net can check to see if the request is coming from an expected domain. + +Thanks, +Lee + + +On 9 Oct 2013, at 16:51, Nathan Michaels wrote: + +> Is the client making the request to your service on widgets.net because things.com sent them there, or is things.com making the request directly on behalf of the client? The first is what Lo?c is talking about. The second is the source IP of the request, which you can definitely get. +> +> +> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin wrote: +> In short: you can't. +> +> Browsers may send origin/referer/.. headers depending on the type of request, but you can't rely on them to be real or even just there. +> +> +> On 10/09/2013 05:30 PM, Lee Sylvester wrote: +> Thank you. I couldn't work out if that's the host being called from or the host name in the request. For example, a store called things.com makes a request to my service on widgets.net. I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this? +> +> Thanks, +> Lee +> +> Sent from my iPhone +> +> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +> +> cowboy_req:host/1? +> +> Please use the nice manual we have now. +> +> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req +> +> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +> Hi, +> +> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from? I'm using CORS in my REST and Bullet app, where each call can be made through a given account. However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage. +> +> Thanks, +> Lee +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From daniel at whitehouse.id.au Thu Oct 10 01:03:08 2013 +From: daniel at whitehouse.id.au (Daniel White) +Date: Thu, 10 Oct 2013 10:03:08 +1100 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: +References: + <52555A98.8090901@ninenines.eu> + <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> + <52557726.2060908@ninenines.eu> + + +Message-ID: + +Depending on your requirements, there is a high likelihood that you +need to support pre-flight requests. Especially if you're intending +on providing credentials in the requests. Many of the interesting +headers are not simple headers (for CORS) and require a handshake +first between browser and server to ensure the headers in question are +allowed to be sent. + +This obviously limits the amount of information you can determine +about the caller. One alternative here, is the use of OAuth2 with the +'access_token' query parameter. This can be sent along with the +pre-flight request. + +On the other hand, some providers (Github, IIRC) will simply validate +a CORS request by comparing the 'Origin' against their entire list of +registered origins. This opens up some opportunity for abuse by other +clients in the system, but can be further mitigated by enforcing the +'Origin' more strictly at the authorization step of the request. + +As an aside, I have a cowboy middleware project to do the heavy +lifting for CORS at https://github.com/danielwhite/cowboy_cors. +Business policies can be implemented by means of a callback module. + +Cheers, + + +On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester wrote: +> Essentially, the REST service endpoint would be on widgets.net while the +> clients website, in this case things.com, has a JavaScript that makes an +> AJAX call to widgets.net. The account on widgets.net for things.com will +> have the things.com domain registered to its account, so that widgets.net +> can check to see if the request is coming from an expected domain. +> +> Thanks, +> Lee +> +> +> On 9 Oct 2013, at 16:51, Nathan Michaels wrote: +> +> Is the client making the request to your service on widgets.net because +> things.com sent them there, or is things.com making the request directly on +> behalf of the client? The first is what Lo?c is talking about. The second is +> the source IP of the request, which you can definitely get. +> +> +> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin wrote: +>> +>> In short: you can't. +>> +>> Browsers may send origin/referer/.. headers depending on the type of +>> request, but you can't rely on them to be real or even just there. +>> +>> +>> On 10/09/2013 05:30 PM, Lee Sylvester wrote: +>>> +>>> Thank you. I couldn't work out if that's the host being called from or +>>> the host name in the request. For example, a store called things.com makes +>>> a request to my service on widgets.net. I need to see that the request is +>>> made FROM things.com for validation purposes. Is it correct that host will +>>> provide this? +>>> +>>> Thanks, +>>> Lee +>>> +>>> Sent from my iPhone +>>> +>>>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +>>>> +>>>> cowboy_req:host/1? +>>>> +>>>> Please use the nice manual we have now. +>>>> +>>>> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req +>>>> +>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +>>>>> Hi, +>>>>> +>>>>> When receiving a Cowboy request, is there a way to find out which +>>>>> hostname the user made the request from? I'm using CORS in my REST and +>>>>> Bullet app, where each call can be made through a given account. However, +>>>>> I'd like to be able to lock requests for each account to a designated +>>>>> hostname to protect that users account usage. +>>>>> +>>>>> Thanks, +>>>>> Lee +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>> +>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> Erlang Cowboy +>>>> Nine Nines +>>>> http://ninenines.eu +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + + +-- +Daniel White + + +From lee.sylvester at gmail.com Thu Oct 10 08:05:23 2013 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Thu, 10 Oct 2013 07:05:23 +0100 +Subject: [99s-extend] Cowboy Calling Hostname +In-Reply-To: +References: + <52555A98.8090901@ninenines.eu> + <6B317ED7-A80B-4866-A347-CA9FE489D522@gmail.com> + <52557726.2060908@ninenines.eu> + + + +Message-ID: <9CEDE09F-E3AF-47FB-95B4-6550000B4CE7@gmail.com> + +Thank you, Daniel. The project looks very useful. At this stage, I don't need to strictly require calls to come from a set domain but would like this to be a hurdle for hackers. I may set up an IP restriction instead. + +Thanks, +Lee + +Sent from my iPhone + +> On Oct 10, 2013, at 12:03 AM, Daniel White wrote: +> +> Depending on your requirements, there is a high likelihood that you +> need to support pre-flight requests. Especially if you're intending +> on providing credentials in the requests. Many of the interesting +> headers are not simple headers (for CORS) and require a handshake +> first between browser and server to ensure the headers in question are +> allowed to be sent. +> +> This obviously limits the amount of information you can determine +> about the caller. One alternative here, is the use of OAuth2 with the +> 'access_token' query parameter. This can be sent along with the +> pre-flight request. +> +> On the other hand, some providers (Github, IIRC) will simply validate +> a CORS request by comparing the 'Origin' against their entire list of +> registered origins. This opens up some opportunity for abuse by other +> clients in the system, but can be further mitigated by enforcing the +> 'Origin' more strictly at the authorization step of the request. +> +> As an aside, I have a cowboy middleware project to do the heavy +> lifting for CORS at https://github.com/danielwhite/cowboy_cors. +> Business policies can be implemented by means of a callback module. +> +> Cheers, +> +> +>> On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester wrote: +>> Essentially, the REST service endpoint would be on widgets.net while the +>> clients website, in this case things.com, has a JavaScript that makes an +>> AJAX call to widgets.net. The account on widgets.net for things.com will +>> have the things.com domain registered to its account, so that widgets.net +>> can check to see if the request is coming from an expected domain. +>> +>> Thanks, +>> Lee +>> +>> +>> On 9 Oct 2013, at 16:51, Nathan Michaels wrote: +>> +>> Is the client making the request to your service on widgets.net because +>> things.com sent them there, or is things.com making the request directly on +>> behalf of the client? The first is what Lo?c is talking about. The second is +>> the source IP of the request, which you can definitely get. +>> +>> +>>> On Wed, Oct 9, 2013 at 11:32 AM, Lo?c Hoguin wrote: +>>> +>>> In short: you can't. +>>> +>>> Browsers may send origin/referer/.. headers depending on the type of +>>> request, but you can't rely on them to be real or even just there. +>>> +>>> +>>>> On 10/09/2013 05:30 PM, Lee Sylvester wrote: +>>>> +>>>> Thank you. I couldn't work out if that's the host being called from or +>>>> the host name in the request. For example, a store called things.com makes +>>>> a request to my service on widgets.net. I need to see that the request is +>>>> made FROM things.com for validation purposes. Is it correct that host will +>>>> provide this? +>>>> +>>>> Thanks, +>>>> Lee +>>>> +>>>> Sent from my iPhone +>>>> +>>>>> On Oct 9, 2013, at 2:31 PM, Lo?c Hoguin wrote: +>>>>> +>>>>> cowboy_req:host/1? +>>>>> +>>>>> Please use the nice manual we have now. +>>>>> +>>>>> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req +>>>>> +>>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote: +>>>>>> Hi, +>>>>>> +>>>>>> When receiving a Cowboy request, is there a way to find out which +>>>>>> hostname the user made the request from? I'm using CORS in my REST and +>>>>>> Bullet app, where each call can be made through a given account. However, +>>>>>> I'd like to be able to lock requests for each account to a designated +>>>>>> hostname to protect that users account usage. +>>>>>> +>>>>>> Thanks, +>>>>>> Lee +>>>>>> +>>>>>> _______________________________________________ +>>>>>> Extend mailing list +>>>>>> Extend at lists.ninenines.eu +>>>>>> http://lists.ninenines.eu:81/listinfo/extend +>>>>> +>>>>> +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> Erlang Cowboy +>>>>> Nine Nines +>>>>> http://ninenines.eu +>>> +>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> Erlang Cowboy +>>> Nine Nines +>>> http://ninenines.eu +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> +> +> -- +> Daniel White + + +From prinbit at gmail.com Tue Oct 15 03:53:05 2013 +From: prinbit at gmail.com (=?GB2312?B?scjB2rHIzNhQcmluYml0?=) +Date: Tue, 15 Oct 2013 09:53:05 +0800 +Subject: [99s-extend] SSL Example +In-Reply-To: +References: +Message-ID: + +Hi Essen, + +Any suggestion on the question? + +I can't receive any email from the lists. + +Thanks in advance + +2013/10/13 ????Prinbit : +> Hi essen +> +> In your ssl example, three files are needed in ssl folder, they are +> cowboy-ca.crt, server.crt and server.key. +> +> I am applying for a free ssl in startssl, and found there are only +> server.crt and server.key generated. +> +> What is cowboy-ca.crt used for? +> +> I want to add ssl certificate in http://prinbit.com, my question is +> that is cowboy-ca.crt is needed for me? +> +> Thanks in advance +> +> -- +> Thanks & Regards, +> +> PrinBit, Video Chatting and Collaborative Coding, Together +> +> http://prinbit.com + + + +-- +Thanks & Regards, + +PrinBit, Video Chatting and Collaborative Coding, Together + +http://prinbit.com + + +From akonsu at gmail.com Wed Oct 16 04:55:28 2013 +From: akonsu at gmail.com (akonsu) +Date: Tue, 15 Oct 2013 22:55:28 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +Message-ID: + +Hello, + +the documentation for `init` at +http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says: + +The receive loop will run for a duration of up to Timeout milliseconds +after it last received data from the socket, at which point it will stop +and send a 204 No Content reply. + +What socket does it refer to? I had an impression that the loop handles +erlang messages. Do these messages come through a socket (sorry about a +trivial question, but I am new to erlang), and this is the socket that the +docs talk about? + +The reason why I am asking is because I used to have a Timeout of 60000, +and even though messages kept coming non stop, it still kept disconnecting +after a minute, until I set Timeout to infinity. + +thanks +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 05:01:38 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 16 Oct 2013 05:01:38 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: +Message-ID: <525E0192.7020706@ninenines.eu> + +The socket connected to the client. + +TCP isn't perfect, there is no way to be 100% sure the client is still +connected, hence the timeout. If the client is still up you should make +it reconnect. + +On 10/16/2013 04:55 AM, akonsu wrote: +> Hello, +> +> the documentation for `init` at +> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says: +> +> The receive loop will run for a duration of up to Timeout milliseconds +> after it last received data from the socket, at which point it will stop +> and send a 204 No Content reply. +> +> What socket does it refer to? I had an impression that the loop handles +> erlang messages. Do these messages come through a socket (sorry about a +> trivial question, but I am new to erlang), and this is the socket that +> the docs talk about? +> +> The reason why I am asking is because I used to have a Timeout of 60000, +> and even though messages kept coming non stop, it still kept +> disconnecting after a minute, until I set Timeout to infinity. +> +> thanks +> Konstantin +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Oct 16 05:03:53 2013 +From: akonsu at gmail.com (akonsu) +Date: Tue, 15 Oct 2013 23:03:53 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: <525E0192.7020706@ninenines.eu> +References: + <525E0192.7020706@ninenines.eu> +Message-ID: + +so it will disconnect if the client only listens and sends nothing to the +socket, correct? + + +2013/10/15 Lo?c Hoguin + +> The socket connected to the client. +> +> TCP isn't perfect, there is no way to be 100% sure the client is still +> connected, hence the timeout. If the client is still up you should make it +> reconnect. +> +> +> On 10/16/2013 04:55 AM, akonsu wrote: +> +>> Hello, +>> +>> the documentation for `init` at +>> http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_**loop_handlersays: +>> +>> The receive loop will run for a duration of up to Timeout milliseconds +>> after it last received data from the socket, at which point it will stop +>> and send a 204 No Content reply. +>> +>> What socket does it refer to? I had an impression that the loop handles +>> erlang messages. Do these messages come through a socket (sorry about a +>> trivial question, but I am new to erlang), and this is the socket that +>> the docs talk about? +>> +>> The reason why I am asking is because I used to have a Timeout of 60000, +>> and even though messages kept coming non stop, it still kept +>> disconnecting after a minute, until I set Timeout to infinity. +>> +>> thanks +>> Konstantin +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 05:11:30 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 16 Oct 2013 05:11:30 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: + <525E0192.7020706@ninenines.eu> + +Message-ID: <525E03E2.5040201@ninenines.eu> + +Yep. And it will also disconnect if the client sends too much. It has to +disconnect and reconnect eventually, there's no way around it. + +On 10/16/2013 05:03 AM, akonsu wrote: +> so it will disconnect if the client only listens and sends nothing to +> the socket, correct? +> +> +> 2013/10/15 Lo?c Hoguin > +> +> The socket connected to the client. +> +> TCP isn't perfect, there is no way to be 100% sure the client is +> still connected, hence the timeout. If the client is still up you +> should make it reconnect. +> +> +> On 10/16/2013 04:55 AM, akonsu wrote: +> +> Hello, +> +> the documentation for `init` at +> http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler +> +> says: +> +> The receive loop will run for a duration of up to Timeout +> milliseconds +> after it last received data from the socket, at which point it +> will stop +> and send a 204 No Content reply. +> +> What socket does it refer to? I had an impression that the loop +> handles +> erlang messages. Do these messages come through a socket (sorry +> about a +> trivial question, but I am new to erlang), and this is the +> socket that +> the docs talk about? +> +> The reason why I am asking is because I used to have a Timeout +> of 60000, +> and even though messages kept coming non stop, it still kept +> disconnecting after a minute, until I set Timeout to infinity. +> +> thanks +> Konstantin +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/__listinfo/extend +> +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Oct 16 05:31:46 2013 +From: akonsu at gmail.com (akonsu) +Date: Tue, 15 Oct 2013 23:31:46 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: <525E03E2.5040201@ninenines.eu> +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> +Message-ID: + +thanks for your help. suppose that I want to stream live audio. I do not +know how long my audio program will be, and as I stream it, if I have a +timeout, the server will just disconnect the user that listens to the audio +in the browser. and the browser won't reconnect. Would you suggest the +"right" way to implement something like that? Would infinite timeout +suffice? or is it a bad practice? another type of handler maybe? + + +2013/10/15 Lo?c Hoguin + +> Yep. And it will also disconnect if the client sends too much. It has to +> disconnect and reconnect eventually, there's no way around it. +> +> +> On 10/16/2013 05:03 AM, akonsu wrote: +> +>> so it will disconnect if the client only listens and sends nothing to +>> the socket, correct? +>> +>> +>> 2013/10/15 Lo?c Hoguin > +>> +>> +>> The socket connected to the client. +>> +>> TCP isn't perfect, there is no way to be 100% sure the client is +>> still connected, hence the timeout. If the client is still up you +>> should make it reconnect. +>> +>> +>> On 10/16/2013 04:55 AM, akonsu wrote: +>> +>> Hello, +>> +>> the documentation for `init` at +>> http://ninenines.eu/docs/en/__**cowboy/HEAD/manual/cowboy___** +>> loop_handler +>> +>> > loop_handler +>> > +>> says: +>> +>> The receive loop will run for a duration of up to Timeout +>> milliseconds +>> after it last received data from the socket, at which point it +>> will stop +>> and send a 204 No Content reply. +>> +>> What socket does it refer to? I had an impression that the loop +>> handles +>> erlang messages. Do these messages come through a socket (sorry +>> about a +>> trivial question, but I am new to erlang), and this is the +>> socket that +>> the docs talk about? +>> +>> The reason why I am asking is because I used to have a Timeout +>> of 60000, +>> and even though messages kept coming non stop, it still kept +>> disconnecting after a minute, until I set Timeout to infinity. +>> +>> thanks +>> Konstantin +>> +>> +>> ______________________________**___________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> > +>> http://lists.ninenines.eu:81/_**_listinfo/extend +>> +>> +>> > +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> +>> +>> +> +> -- +> Lo?c Hoguin +> +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 05:40:31 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 16 Oct 2013 05:40:31 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + +Message-ID: <525E0AAF.3070203@ninenines.eu> + +Infinite is bad practice, yes. Infinite means some connections will +*never* be closed, eating FDs and memory for nothing. + +I'm not sure why you want to receive messages, you could just use a +normal handler that asks for more data, sends it, ask for more data, +sends it, etc. + +On 10/16/2013 05:31 AM, akonsu wrote: +> thanks for your help. suppose that I want to stream live audio. I do not +> know how long my audio program will be, and as I stream it, if I have a +> timeout, the server will just disconnect the user that listens to the +> audio in the browser. and the browser won't reconnect. Would you suggest +> the "right" way to implement something like that? Would infinite timeout +> suffice? or is it a bad practice? another type of handler maybe? +> +> +> 2013/10/15 Lo?c Hoguin > +> +> Yep. And it will also disconnect if the client sends too much. It +> has to disconnect and reconnect eventually, there's no way around it. +> +> +> On 10/16/2013 05:03 AM, akonsu wrote: +> +> so it will disconnect if the client only listens and sends +> nothing to +> the socket, correct? +> +> +> 2013/10/15 Lo?c Hoguin >> +> +> +> The socket connected to the client. +> +> TCP isn't perfect, there is no way to be 100% sure the +> client is +> still connected, hence the timeout. If the client is still +> up you +> should make it reconnect. +> +> +> On 10/16/2013 04:55 AM, akonsu wrote: +> +> Hello, +> +> the documentation for `init` at +> http://ninenines.eu/docs/en/____cowboy/HEAD/manual/cowboy_____loop_handler +> +> +> +> > +> says: +> +> The receive loop will run for a duration of up to Timeout +> milliseconds +> after it last received data from the socket, at which +> point it +> will stop +> and send a 204 No Content reply. +> +> What socket does it refer to? I had an impression that +> the loop +> handles +> erlang messages. Do these messages come through a +> socket (sorry +> about a +> trivial question, but I am new to erlang), and this is the +> socket that +> the docs talk about? +> +> The reason why I am asking is because I used to have a +> Timeout +> of 60000, +> and even though messages kept coming non stop, it still +> kept +> disconnecting after a minute, until I set Timeout to +> infinity. +> +> thanks +> Konstantin +> +> +> ___________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> > +> http://lists.ninenines.eu:81/____listinfo/extend +> +> +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +> +> +> -- +> Lo?c Hoguin +> +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Oct 16 05:48:42 2013 +From: akonsu at gmail.com (akonsu) +Date: Tue, 15 Oct 2013 23:48:42 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: <525E0AAF.3070203@ninenines.eu> +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> +Message-ID: + +1. do you mean that there is no way on the server side to tell if the +client has disconnected? + +2. if I use a normal handler, I will still run into the same problem, it +does not matter which handler I use, from the standpoint of deciding +whether the client is still there, right? + +I am confused as to how I can implement my streaming and not drop the +connection on each client and yet make sure I do close the connections when +the clients disconnect... + + +2013/10/15 Lo?c Hoguin + +> Infinite is bad practice, yes. Infinite means some connections will +> *never* be closed, eating FDs and memory for nothing. +> +> I'm not sure why you want to receive messages, you could just use a normal +> handler that asks for more data, sends it, ask for more data, sends it, etc. +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 06:07:26 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 16 Oct 2013 06:07:26 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> + +Message-ID: <525E10FE.2020107@ninenines.eu> + +On 10/16/2013 05:48 AM, akonsu wrote: +> 1. do you mean that there is no way on the server side to tell if the +> client has disconnected? + +There are ways, and Cowboy will happily detect them. There's also the +problem that a side may be closed without the other side knowing about +it, which is why you need timeouts. + +> 2. if I use a normal handler, I will still run into the same problem, it +> does not matter which handler I use, from the standpoint of deciding +> whether the client is still there, right? + +If the client is gone, the send will fail. Normal handlers are pretty +much the same except they don't have a timeout, because your code has an +explicit end. + +> I am confused as to how I can implement my streaming and not drop the +> connection on each client and yet make sure I do close the connections +> when the clients disconnect... +> +> +> 2013/10/15 Lo?c Hoguin > +> +> Infinite is bad practice, yes. Infinite means some connections will +> *never* be closed, eating FDs and memory for nothing. +> +> I'm not sure why you want to receive messages, you could just use a +> normal handler that asks for more data, sends it, ask for more data, +> sends it, etc. +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Oct 16 06:12:29 2013 +From: akonsu at gmail.com (akonsu) +Date: Wed, 16 Oct 2013 00:12:29 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: <525E10FE.2020107@ninenines.eu> +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> + + <525E10FE.2020107@ninenines.eu> +Message-ID: + +thanks. one more question if you do not mind. you say that we need timeouts +when the client does not notify us when it dies. but then you say that if +the client dies then the socket write will fail. to me this sounds like a +contradiction. would you please clarify? + +(I assume that this is the problem that we are discussing: +http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect, +right?) + + +2013/10/16 Lo?c Hoguin + +> On 10/16/2013 05:48 AM, akonsu wrote: +> +>> 1. do you mean that there is no way on the server side to tell if the +>> client has disconnected? +>> +> +> There are ways, and Cowboy will happily detect them. There's also the +> problem that a side may be closed without the other side knowing about it, +> which is why you need timeouts. +> +> +> 2. if I use a normal handler, I will still run into the same problem, it +>> does not matter which handler I use, from the standpoint of deciding +>> whether the client is still there, right? +>> +> +> If the client is gone, the send will fail. Normal handlers are pretty much +> the same except they don't have a timeout, because your code has an +> explicit end. +> +> I am confused as to how I can implement my streaming and not drop the +>> connection on each client and yet make sure I do close the connections +>> when the clients disconnect... +>> +>> +>> 2013/10/15 Lo?c Hoguin > +>> +>> +>> Infinite is bad practice, yes. Infinite means some connections will +>> *never* be closed, eating FDs and memory for nothing. +>> +>> I'm not sure why you want to receive messages, you could just use a +>> normal handler that asks for more data, sends it, ask for more data, +>> sends it, etc. +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 06:35:43 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 16 Oct 2013 06:35:43 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> + + <525E10FE.2020107@ninenines.eu> + +Message-ID: <525E179F.2010200@ninenines.eu> + +Loop handlers are designed to wait for a long time with the socket +*idle* and then eventually send one response then close the socket. +Things like long-polling. + +What you are doing is just streaming, for which you do not need a +timeout because the socket isn't idle. You are just sending a large +response, and normal handlers are perfectly capable of doing that. + +On 10/16/2013 06:12 AM, akonsu wrote: +> thanks. one more question if you do not mind. you say that we need +> timeouts when the client does not notify us when it dies. but then you +> say that if the client dies then the socket write will fail. to me this +> sounds like a contradiction. would you please clarify? +> +> (I assume that this is the problem that we are discussing: +> http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect, +> right?) +> +> +> 2013/10/16 Lo?c Hoguin > +> +> On 10/16/2013 05:48 AM, akonsu wrote: +> +> 1. do you mean that there is no way on the server side to tell +> if the +> client has disconnected? +> +> +> There are ways, and Cowboy will happily detect them. There's also +> the problem that a side may be closed without the other side knowing +> about it, which is why you need timeouts. +> +> +> 2. if I use a normal handler, I will still run into the same +> problem, it +> does not matter which handler I use, from the standpoint of deciding +> whether the client is still there, right? +> +> +> If the client is gone, the send will fail. Normal handlers are +> pretty much the same except they don't have a timeout, because your +> code has an explicit end. +> +> I am confused as to how I can implement my streaming and not +> drop the +> connection on each client and yet make sure I do close the +> connections +> when the clients disconnect... +> +> +> 2013/10/15 Lo?c Hoguin >> +> +> +> Infinite is bad practice, yes. Infinite means some +> connections will +> *never* be closed, eating FDs and memory for nothing. +> +> I'm not sure why you want to receive messages, you could +> just use a +> normal handler that asks for more data, sends it, ask for +> more data, +> sends it, etc. +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Wed Oct 16 06:42:02 2013 +From: akonsu at gmail.com (akonsu) +Date: Wed, 16 Oct 2013 00:42:02 -0400 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: <525E179F.2010200@ninenines.eu> +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> + + <525E10FE.2020107@ninenines.eu> + + <525E179F.2010200@ninenines.eu> +Message-ID: + +ok. the data that I need to send are coming as erlang messages to the +process that runs my handler. so it sounds like if I want to use the +"normal" cowboy_http_handler, then I need a receive loop inside handle(Req, +State) callback, right? Basically, my response stream will potentially +never end, I do not know how to handle this properly in cowboy... + + +2013/10/16 Lo?c Hoguin + +> Loop handlers are designed to wait for a long time with the socket *idle* +> and then eventually send one response then close the socket. Things like +> long-polling. +> +> What you are doing is just streaming, for which you do not need a timeout +> because the socket isn't idle. You are just sending a large response, and +> normal handlers are perfectly capable of doing that. +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Oct 16 06:48:05 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 16 Oct 2013 06:48:05 +0200 +Subject: [99s-extend] timeout in cowboy loop handler +In-Reply-To: +References: + <525E0192.7020706@ninenines.eu> + + <525E03E2.5040201@ninenines.eu> + + <525E0AAF.3070203@ninenines.eu> + + <525E10FE.2020107@ninenines.eu> + + <525E179F.2010200@ninenines.eu> + +Message-ID: <525E1A85.3070706@ninenines.eu> + +Then use a loop handler, set its timeout to infinity *but* create a new +timeout that checks regularly if the handler is active or not to be able +to kill it off in case something happens. + +On 10/16/2013 06:42 AM, akonsu wrote: +> ok. the data that I need to send are coming as erlang messages to the +> process that runs my handler. so it sounds like if I want to use the +> "normal" cowboy_http_handler, then I need a receive loop +> inside handle(Req, State) callback, right? Basically, my response stream +> will potentially never end, I do not know how to handle this properly in +> cowboy... +> +> +> 2013/10/16 Lo?c Hoguin > +> +> Loop handlers are designed to wait for a long time with the socket +> *idle* and then eventually send one response then close the socket. +> Things like long-polling. +> +> What you are doing is just streaming, for which you do not need a +> timeout because the socket isn't idle. You are just sending a large +> response, and normal handlers are perfectly capable of doing that. +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Fri Oct 18 15:15:37 2013 +From: akonsu at gmail.com (akonsu) +Date: Fri, 18 Oct 2013 09:15:37 -0400 +Subject: [99s-extend] handler and a linked process +Message-ID: + +Hi, + +I have a handler that spawns a process and links to this process. the new +process does not trap exit signals. + +When I open the URL that is handled by this handler in the browser, and +stop the browser before the handler finishes the request, the handler is +terminated and my terminate function is called with the Reason set to +{error,closed} or something similar. + +When this happens, the linked process does not get killed, so I have to +call exit on it from the terminate function. + +is this by design? I suppose when I cancel the browser request, the handler +is exited with normal exit code, correct? could you point me to the source +code for that part? it is perhaps in the "ranch" repo, no? + +thanks in advance + +konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Oct 21 15:07:34 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 21 Oct 2013 15:07:34 +0200 +Subject: [99s-extend] handler and a linked process +In-Reply-To: +References: +Message-ID: <52652716.4010806@ninenines.eu> + +Hey, + +I'm guessing you use loop handler or websocket handler? The browser +closing the connection in these cases is perfectly normal, that's part +of the deal. What you can do is monitor the connection process from the +other process if you need to go down in all cases. Links are only useful +for crashing on errors. + +On 10/18/2013 03:15 PM, akonsu wrote: +> Hi, +> +> I have a handler that spawns a process and links to this process. the +> new process does not trap exit signals. +> +> When I open the URL that is handled by this handler in the browser, and +> stop the browser before the handler finishes the request, the handler is +> terminated and my terminate function is called with the Reason set to +> {error,closed} or something similar. +> +> When this happens, the linked process does not get killed, so I have to +> call exit on it from the terminate function. +> +> is this by design? I suppose when I cancel the browser request, the +> handler is exited with normal exit code, correct? could you point me to +> the source code for that part? it is perhaps in the "ranch" repo, no? +> +> thanks in advance +> +> konstantin +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From antonio.valente at statpro.com Tue Oct 22 10:51:14 2013 +From: antonio.valente at statpro.com (Antonio Valente) +Date: Tue, 22 Oct 2013 10:51:14 +0200 +Subject: [99s-extend] Generate url in cowboy +Message-ID: <52663C82.80702@statpro.com> + +Hi all, +I need to automatically generate urls from the dispatcher configuration: +I'm looking for some kind of function that, given the dispatcher +configuration, a module and a list of bindings, returns an url. + +For example, if I have the following dispatch configuration: + + [ + {'_', [ + + {"/api/v1/container/:resource/something", a_module, []}, + ]} + ]. + +I'd like to do something like: + +<<"/api/v1/container/replaced/something">> = generate_url(Dispatch, +a_module, [{resource, "replaced"}]). + +Is there such a function? If not, can you give me some advice to write one? + +Thanks +Antonio + + +This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Any views or opinions presented in this email are solely those of the author and might not represent those of StatPro. Warning: Although StatPro has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. + + +From Rolph.deRuiter at spilgames.com Tue Oct 29 10:00:53 2013 +From: Rolph.deRuiter at spilgames.com (Rolph de Ruiter) +Date: Tue, 29 Oct 2013 09:00:53 +0000 +Subject: [99s-extend] cowboy_rest, POST and redirect +Message-ID: + +Hi, + +I'm using cowboy_rest for a part of our api to handle POST requests. Under certain conditions, I would like to redirect to a new location (based on availability of the redirect qs parameter). +I was unable to get the moved_temporarily/2 callback to work (was not invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. This works, however, every time it produces an error in the emulator process: + [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26 bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7 bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,... + +Can you point me out how to (ideally) make use of moved_temporarily/2 or how I can prevent cowboy_rest from wanting to reply with 204 in this case? + +Cheers, +Rolph +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Oct 29 10:09:20 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Tue, 29 Oct 2013 10:09:20 +0100 +Subject: [99s-extend] cowboy_rest, POST and redirect +In-Reply-To: +References: +Message-ID: <526F7B40.4060408@ninenines.eu> + +On 10/29/2013 10:00 AM, Rolph de Ruiter wrote: +> Hi, +> +> I'm using cowboy_rest for a part of our api to handle POST requests. +> Under certain conditions, I would like to redirect to a new location +> (based on availability of the redirect qs parameter). +> I was unable to get the moved_temporarily/2 callback to work (was not +> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. +> This works, however, every time it produces an error in the emulator +> process: +> [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with +> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 +> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 +> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26 +> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 +> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 +> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 +> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7 +> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 +> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 +> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 +> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,... +> +> Can you point me out how to (ideally) make use of moved_temporarily/2 or +> how I can prevent cowboy_rest from wanting to reply with 204 in this case? + +moved_temporarily is only called if the resource previously existed. + +As for calling reply yourself, you just need to return {halt, NewReq, +State} afterwards. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From Rolph.deRuiter at spilgames.com Tue Oct 29 10:16:15 2013 +From: Rolph.deRuiter at spilgames.com (Rolph de Ruiter) +Date: Tue, 29 Oct 2013 09:16:15 +0000 +Subject: [99s-extend] cowboy_rest, POST and redirect +In-Reply-To: +Message-ID: + +(forgot to include the list) + +On 10/29/13 10:14 AM, "Rolph de Ruiter" +wrote: + +>Thanks! +> +>{halt, NewReq, State} worked like a charm :) +> +>Cheers, +>Rolph +> +>On 10/29/13 10:09 AM, "Lo?c Hoguin" wrote: +> +>>On 10/29/2013 10:00 AM, Rolph de Ruiter wrote: +>>> Hi, +>>> +>>> I'm using cowboy_rest for a part of our api to handle POST requests. +>>> Under certain conditions, I would like to redirect to a new location +>>> (based on availability of the redirect qs parameter). +>>> I was unable to get the moved_temporarily/2 callback to work (was not +>>> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. +>>> This works, however, every time it produces an error in the emulator +>>> process: +>>> [error] emulator Error in process <0.509.0> on node 'api at dev.loc' +>>>with +>>> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 +>>> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 +>>> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 +>>>bytes>>,undefined,8000,<<26 +>>> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 +>>> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 +>>> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 +>>> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7 +>>> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 +>>> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 +>>> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 +>>> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,... +>>> +>>> Can you point me out how to (ideally) make use of moved_temporarily/2 +>>>or +>>> how I can prevent cowboy_rest from wanting to reply with 204 in this +>>>case? +>> +>>moved_temporarily is only called if the resource previously existed. +>> +>>As for calling reply yourself, you just need to return {halt, NewReq, +>>State} afterwards. +>> +>>-- +>>Lo?c Hoguin +>>Erlang Cowboy +>>Nine Nines +>>http://ninenines.eu +> + + + +From daniel.goertzen at gmail.com Tue Oct 29 21:25:54 2013 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Tue, 29 Oct 2013 15:25:54 -0500 +Subject: [99s-extend] REST handler failure +Message-ID: + +My situation is that I have a rest handler that may fail due to invalid url +segments. Example situation: + + +init(_Transport, _Req, _Opts) -> + {upgrade, protocol, cowboy_rest}. + +content_types_provided(Req, State) -> + {[{<<"application/json">>, get_json}], Req, State}. + +get_json(Req0, State) -> + {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, +[param1, param2, param3, ....]), + + case catch other_module:request(Params) of + {'EXIT', {badarg, _}} -> + hmmm, Params were bad and I would like to return a 404 code now. + Result -> + {jiffy:encode(Result), Req1, State} + end. + + + +So I would like to return a 404 code when my underlying request function +fails, but it appears my choices are: + +- return a 200 (ok) response with data. +- crash and cause a 500 (Internal Server Error) response to be returned. +Not exactly the sentiment I want. + + +Is there some other way to cause a 404 response? + +I realize I could add path constraint functions, but I will be replicating +logic from my underlying request function. Furthermore, the constraint +functions consider parameters in isolation, so that won't work if the +validity of parameters is coupled. + +Thanks, +Dan. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ivan at llaisdy.com Tue Oct 29 22:01:30 2013 +From: ivan at llaisdy.com (Ivan uemlianin) +Date: Tue, 29 Oct 2013 22:01:30 +0100 +Subject: [99s-extend] REST handler failure +In-Reply-To: +References: +Message-ID: <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> + +Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ... + +Ivan + +-- +festina lente + + +On 29 Oct 2013, at 21:25, Daniel Goertzen wrote: + +> My situation is that I have a rest handler that may fail due to invalid url segments. Example situation: +> +> +> init(_Transport, _Req, _Opts) -> +> {upgrade, protocol, cowboy_rest}. +> +> content_types_provided(Req, State) -> +> {[{<<"application/json">>, get_json}], Req, State}. +> +> get_json(Req0, State) -> +> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]), +> +> case catch other_module:request(Params) of +> {'EXIT', {badarg, _}} -> +> hmmm, Params were bad and I would like to return a 404 code now. +> Result -> +> {jiffy:encode(Result), Req1, State} +> end. +> +> +> +> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are: +> +> - return a 200 (ok) response with data. +> - crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want. +> +> +> Is there some other way to cause a 404 response? +> +> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled. +> +> Thanks, +> Dan. +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From daniel.goertzen at gmail.com Wed Oct 30 15:58:41 2013 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Wed, 30 Oct 2013 09:58:41 -0500 +Subject: [99s-extend] REST handler failure +In-Reply-To: <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> +References: + <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> +Message-ID: + +Well, this sort of works. I tried this in the response handler: + + {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body +that gets used">>, Req1), + {<<"this body gets ignored">>, Req2, State}; + + + +The client receives a 404 response, but cowboy crashes: + +=ERROR REPORT==== 8-Sep-2013::22:22:03 === +Error in process <0.131.0> with exit value: +{function_clause,[{cowboy_req,reply,[200,[],<<31 +bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 +bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 +bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 +bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 +bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 +bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... + + + +The issue is that the REST wrapper wants to do the cowboy_req:reply(), and +when we do the call we cause the wrapper's call to fail. + +Dan. + + + +On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin wrote: + +> Sorry for terse but I only have a phone. Why can't you return a 404 here? +> Using something like cowboy:reply(404, ... +> +> Ivan +> +> -- +> festina lente +> +> +> On 29 Oct 2013, at 21:25, Daniel Goertzen +> wrote: +> +> My situation is that I have a rest handler that may fail due to invalid +> url segments. Example situation: +> +> +> init(_Transport, _Req, _Opts) -> +> {upgrade, protocol, cowboy_rest}. +> +> content_types_provided(Req, State) -> +> {[{<<"application/json">>, get_json}], Req, State}. +> +> get_json(Req0, State) -> +> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, +> [param1, param2, param3, ....]), +> +> case catch other_module:request(Params) of +> {'EXIT', {badarg, _}} -> +> hmmm, Params were bad and I would like to return a 404 code +> now. +> Result -> +> {jiffy:encode(Result), Req1, State} +> end. +> +> +> +> So I would like to return a 404 code when my underlying request function +> fails, but it appears my choices are: +> +> - return a 200 (ok) response with data. +> - crash and cause a 500 (Internal Server Error) response to be returned. +> Not exactly the sentiment I want. +> +> +> Is there some other way to cause a 404 response? +> +> I realize I could add path constraint functions, but I will be replicating +> logic from my underlying request function. Furthermore, the constraint +> functions consider parameters in isolation, so that won't work if the +> validity of parameters is coupled. +> +> Thanks, +> Dan. +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From tilman.holschuh at gmail.com Wed Oct 30 16:25:02 2013 +From: tilman.holschuh at gmail.com (Tilman Holschuh) +Date: Wed, 30 Oct 2013 08:25:02 -0700 +Subject: [99s-extend] REST handler failure +In-Reply-To: +References: + <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> + +Message-ID: + +Why not let resource_exists/2 return false when your resource does not exist? You will get 404 on false. This way you separate the implementation for turning your data to json from checking if the request went to the correct resource. + +- Tilman + +On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote: + +> Well, this sort of works. I tried this in the response handler: +> +> {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1), +> {<<"this body gets ignored">>, Req2, State}; +> +> +> +> The client receives a 404 response, but cowboy crashes: +> +> =ERROR REPORT==== 8-Sep-2013::22:22:03 === +> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... +> +> +> +> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail. +> +> Dan. +> +> +> +> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin wrote: +> Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ... +> +> Ivan +> +> -- +> festina lente +> +> +> On 29 Oct 2013, at 21:25, Daniel Goertzen wrote: +> +>> My situation is that I have a rest handler that may fail due to invalid url segments. Example situation: +>> +>> +>> init(_Transport, _Req, _Opts) -> +>> {upgrade, protocol, cowboy_rest}. +>> +>> content_types_provided(Req, State) -> +>> {[{<<"application/json">>, get_json}], Req, State}. +>> +>> get_json(Req0, State) -> +>> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]), +>> +>> case catch other_module:request(Params) of +>> {'EXIT', {badarg, _}} -> +>> hmmm, Params were bad and I would like to return a 404 code now. +>> Result -> +>> {jiffy:encode(Result), Req1, State} +>> end. +>> +>> +>> +>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are: +>> +>> - return a 200 (ok) response with data. +>> - crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want. +>> +>> +>> Is there some other way to cause a 404 response? +>> +>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled. +>> +>> Thanks, +>> Dan. +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + + +From ivan at llaisdy.com Wed Oct 30 16:27:15 2013 +From: ivan at llaisdy.com (Ivan uemlianin) +Date: Wed, 30 Oct 2013 16:27:15 +0100 +Subject: [99s-extend] REST handler failure +In-Reply-To: +References: + <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> + +Message-ID: <215FA968-210F-474B-A3C2-0627D8FFFC74@llaisdy.com> + +Instead of <<"this body ignored">> can you return the atom halt? + +#dontevenhaveanyofmycodewithme:( + +Ivan + +-- +festina lente + + +On 30 Oct 2013, at 15:58, Daniel Goertzen wrote: + +> Well, this sort of works. I tried this in the response handler: +> +> {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1), +> {<<"this body gets ignored">>, Req2, State}; +> +> +> +> The client receives a 404 response, but cowboy crashes: +> +> =ERROR REPORT==== 8-Sep-2013::22:22:03 === +> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... +> +> +> +> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail. +> +> Dan. +> +> +> +> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin wrote: +>> Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ... +>> +>> Ivan +>> +>> -- +>> festina lente +>> +>> +>> On 29 Oct 2013, at 21:25, Daniel Goertzen wrote: +>> +>>> My situation is that I have a rest handler that may fail due to invalid url segments. Example situation: +>>> +>>> +>>> init(_Transport, _Req, _Opts) -> +>>> {upgrade, protocol, cowboy_rest}. +>>> +>>> content_types_provided(Req, State) -> +>>> {[{<<"application/json">>, get_json}], Req, State}. +>>> +>>> get_json(Req0, State) -> +>>> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]), +>>> +>>> case catch other_module:request(Params) of +>>> {'EXIT', {badarg, _}} -> +>>> hmmm, Params were bad and I would like to return a 404 code now. +>>> Result -> +>>> {jiffy:encode(Result), Req1, State} +>>> end. +>>> +>>> +>>> +>>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are: +>>> +>>> - return a 200 (ok) response with data. +>>> - crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want. +>>> +>>> +>>> Is there some other way to cause a 404 response? +>>> +>>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled. +>>> +>>> Thanks, +>>> Dan. +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> http://lists.ninenines.eu:81/listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From daniel.goertzen at gmail.com Wed Oct 30 16:32:47 2013 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Wed, 30 Oct 2013 10:32:47 -0500 +Subject: [99s-extend] REST handler failure +In-Reply-To: <215FA968-210F-474B-A3C2-0627D8FFFC74@llaisdy.com> +References: + <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> + + <215FA968-210F-474B-A3C2-0627D8FFFC74@llaisdy.com> +Message-ID: + +Returning 'halt' caused a status code of 204. + +Dan. + + +On Wed, Oct 30, 2013 at 10:27 AM, Ivan uemlianin wrote: + +> Instead of <<"this body ignored">> can you return the atom halt? +> +> #dontevenhaveanyofmycodewithme:( +> +> Ivan +> +> -- +> festina lente +> +> +> On 30 Oct 2013, at 15:58, Daniel Goertzen +> wrote: +> +> Well, this sort of works. I tried this in the response handler: +> +> {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body +> that gets used">>, Req1), +> {<<"this body gets ignored">>, Req2, State}; +> +> +> +> The client receives a 404 response, but cowboy crashes: +> +> =ERROR REPORT==== 8-Sep-2013::22:22:03 === +> Error in process <0.131.0> with exit value: +> {function_clause,[{cowboy_req,reply,[200,[],<<31 +> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 +> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 +> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 +> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 +> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 +> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... +> +> +> +> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and +> when we do the call we cause the wrapper's call to fail. +> +> Dan. +> +> +> +> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin wrote: +> +>> Sorry for terse but I only have a phone. Why can't you return a 404 here? +>> Using something like cowboy:reply(404, ... +>> +>> Ivan +>> +>> -- +>> festina lente +>> +>> +>> On 29 Oct 2013, at 21:25, Daniel Goertzen +>> wrote: +>> +>> My situation is that I have a rest handler that may fail due to invalid +>> url segments. Example situation: +>> +>> +>> init(_Transport, _Req, _Opts) -> +>> {upgrade, protocol, cowboy_rest}. +>> +>> content_types_provided(Req, State) -> +>> {[{<<"application/json">>, get_json}], Req, State}. +>> +>> get_json(Req0, State) -> +>> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, +>> [param1, param2, param3, ....]), +>> +>> case catch other_module:request(Params) of +>> {'EXIT', {badarg, _}} -> +>> hmmm, Params were bad and I would like to return a 404 code +>> now. +>> Result -> +>> {jiffy:encode(Result), Req1, State} +>> end. +>> +>> +>> +>> So I would like to return a 404 code when my underlying request function +>> fails, but it appears my choices are: +>> +>> - return a 200 (ok) response with data. +>> - crash and cause a 500 (Internal Server Error) response to be returned. +>> Not exactly the sentiment I want. +>> +>> +>> Is there some other way to cause a 404 response? +>> +>> I realize I could add path constraint functions, but I will be +>> replicating logic from my underlying request function. Furthermore, the +>> constraint functions consider parameters in isolation, so that won't work +>> if the validity of parameters is coupled. +>> +>> Thanks, +>> Dan. +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +>> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From daniel.goertzen at gmail.com Wed Oct 30 16:46:37 2013 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Wed, 30 Oct 2013 10:46:37 -0500 +Subject: [99s-extend] REST handler failure +In-Reply-To: +References: + <0F1D01F5-A4B3-4135-8F4C-FCC2E9F79DFA@llaisdy.com> + + +Message-ID: + +That's what I was looking for, thanks! + +Dan. + + +On Wed, Oct 30, 2013 at 10:25 AM, Tilman Holschuh wrote: + +> Why not let resource_exists/2 return false when your resource does not +> exist? You will get 404 on false. This way you separate the implementation +> for turning your data to json from checking if the request went to the +> correct resource. +> +> - Tilman +> +> On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote: +> +> > Well, this sort of works. I tried this in the response handler: +> > +> > {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body +> that gets used">>, Req1), +> > {<<"this body gets ignored">>, Req2, State}; +> > +> > +> > +> > The client receives a 404 response, but cowboy crashes: +> > +> > =ERROR REPORT==== 8-Sep-2013::22:22:03 === +> > Error in process <0.131.0> with exit value: +> {function_clause,[{cowboy_req,reply,[200,[],<<31 +> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 +> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 +> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 +> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 +> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 +> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... +> > +> > +> > +> > The issue is that the REST wrapper wants to do the cowboy_req:reply(), +> and when we do the call we cause the wrapper's call to fail. +> > +> > Dan. +> > +> > +> > +> > On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin +> wrote: +> > Sorry for terse but I only have a phone. Why can't you return a 404 +> here? Using something like cowboy:reply(404, ... +> > +> > Ivan +> > +> > -- +> > festina lente +> > +> > +> > On 29 Oct 2013, at 21:25, Daniel Goertzen +> wrote: +> > +> >> My situation is that I have a rest handler that may fail due to invalid +> url segments. Example situation: +> >> +> >> +> >> init(_Transport, _Req, _Opts) -> +> >> {upgrade, protocol, cowboy_rest}. +> >> +> >> content_types_provided(Req, State) -> +> >> {[{<<"application/json">>, get_json}], Req, State}. +> >> +> >> get_json(Req0, State) -> +> >> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, +> [param1, param2, param3, ....]), +> >> +> >> case catch other_module:request(Params) of +> >> {'EXIT', {badarg, _}} -> +> >> hmmm, Params were bad and I would like to return a 404 code +> now. +> >> Result -> +> >> {jiffy:encode(Result), Req1, State} +> >> end. +> >> +> >> +> >> +> >> So I would like to return a 404 code when my underlying request +> function fails, but it appears my choices are: +> >> +> >> - return a 200 (ok) response with data. +> >> - crash and cause a 500 (Internal Server Error) response to be +> returned. Not exactly the sentiment I want. +> >> +> >> +> >> Is there some other way to cause a 404 response? +> >> +> >> I realize I could add path constraint functions, but I will be +> replicating logic from my underlying request function. Furthermore, the +> constraint functions consider parameters in isolation, so that won't work +> if the validity of parameters is coupled. +> >> +> >> Thanks, +> >> Dan. +> >> _______________________________________________ +> >> Extend mailing list +> >> Extend at lists.ninenines.eu +> >> http://lists.ninenines.eu:81/listinfo/extend +> > +> > _______________________________________________ +> > Extend mailing list +> > Extend at lists.ninenines.eu +> > http://lists.ninenines.eu:81/listinfo/extend +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-October/000255.html b/_build/static/archives/extend/2013-October/000255.html new file mode 100644 index 00000000..4cc731e8 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000255.html @@ -0,0 +1,69 @@ + + + + [99s-extend] websocket_info and RPC + + + + + + + + + + +

[99s-extend] websocket_info and RPC

+ Marcel Meyer + marcel.meyer at gmail.com +
+ Thu Oct 3 07:00:28 CEST 2013 +

+
+ +
Hi there,
+
+How do I use the websocket infrastructure of cowboy to implement RPC?
+It seems like I can talk to the client using websocket_info, but the
+response comes in on websocket_handle, all asynchronously.
+
+Kind regards,
+Marcel
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131002/4463e3fa/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000256.html b/_build/static/archives/extend/2013-October/000256.html new file mode 100644 index 00000000..0425c86e --- /dev/null +++ b/_build/static/archives/extend/2013-October/000256.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Problem with cowboy ssl example + + + + + + + + + + +

[99s-extend] Problem with cowboy ssl example

+ Ryan Brown + ryankbrown at gmail.com +
+ Tue Oct 8 05:55:57 CEST 2013 +

+
+ +
I was trying to compile and run the ssl_hello_world example in the cowboy
+project and am getting the following error at start-up:
+
+=INFO REPORT==== 7-Oct-2013::21:38:01 ===    application: ssl_hello_world
+  exited: {bad_return,             {{ssl_hello_world_app,start,[normal,[]]},
+            {'EXIT',               {{badmatch,                 {error,
+            {{shutdown,
+{failed_to_start_child,ranch_acceptors_sup,
+ {{case_clause,                       {error,{"no such file or
+directory","asn1.app"}}},
+[{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]},
+
+I can start asn1 from the erl console so I am not sure what I am missing.
+Any help is greatly appreciated.
+
+Best regards.
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131007/fdef2170/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000257.html b/_build/static/archives/extend/2013-October/000257.html new file mode 100644 index 00000000..ceba1eaa --- /dev/null +++ b/_build/static/archives/extend/2013-October/000257.html @@ -0,0 +1,129 @@ + + + + [99s-extend] Problem with cowboy ssl example + + + + + + + + + + +

[99s-extend] Problem with cowboy ssl example

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Oct 8 06:13:04 CEST 2013 +

+
+ +
I'm guessing you run an older Erlang which had that issue. Either 
+upgrade Erlang or add asn1 to the list of apps to include in the release 
+(and open a ticket for it please so it can be made to work with older 
+versions).
+
+On 10/08/2013 05:55 AM, Ryan Brown wrote:
+> I was trying to compile and run the ssl_hello_world example in the
+> cowboy project and am getting the following error at start-up:
+>
+>
+>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>
+>
+>        application: ssl_hello_world
+>
+>
+>        exited: {bad_return,
+>
+>
+>                 {{ssl_hello_world_app,start,[normal,[]]},
+>
+>
+>                  {'EXIT',
+>
+>
+>                   {{badmatch,
+>
+>
+>                     {error,
+>
+>
+>                      {{shutdown,
+>
+>
+>                        {failed_to_start_child,ranch_acceptors_sup,
+>
+>
+>                         {{case_clause,
+>
+>
+>                           {error,{"no such file or directory","asn1.app"}}},
+>
+>
+>
+>   [{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]},
+>
+>
+> I can start asn1 from the erl console so I am not sure what I am
+> missing. Any help is greatly appreciated.
+>
+> Best regards.
+>
+> --
+> -rb
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000258.html b/_build/static/archives/extend/2013-October/000258.html new file mode 100644 index 00000000..19f86aba --- /dev/null +++ b/_build/static/archives/extend/2013-October/000258.html @@ -0,0 +1,149 @@ + + + + [99s-extend] Problem with cowboy ssl example + + + + + + + + + + +

[99s-extend] Problem with cowboy ssl example

+ Ryan Brown + ryankbrown at gmail.com +
+ Tue Oct 8 06:24:54 CEST 2013 +

+
+ +
Thanks Loïc. I am actually running R16B on a macbook OS X 10.8. (I'm
+wondering if the Od could have any effect?)
+
+Best,
+
+Ryan
+
+
+On Mon, Oct 7, 2013 at 10:13 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> I'm guessing you run an older Erlang which had that issue. Either upgrade
+> Erlang or add asn1 to the list of apps to include in the release (and open
+> a ticket for it please so it can be made to work with older versions).
+>
+>
+> On 10/08/2013 05:55 AM, Ryan Brown wrote:
+>
+>> I was trying to compile and run the ssl_hello_world example in the
+>> cowboy project and am getting the following error at start-up:
+>>
+>>
+>>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>>
+>>
+>>        application: ssl_hello_world
+>>
+>>
+>>        exited: {bad_return,
+>>
+>>
+>>                 {{ssl_hello_world_app,start,[**normal,[]]},
+>>
+>>
+>>                  {'EXIT',
+>>
+>>
+>>                   {{badmatch,
+>>
+>>
+>>                     {error,
+>>
+>>
+>>                      {{shutdown,
+>>
+>>
+>>                        {failed_to_start_child,ranch_**acceptors_sup,
+>>
+>>
+>>                         {{case_clause,
+>>
+>>
+>>                           {error,{"no such file or
+>> directory","asn1.app"}}},
+>>
+>>
+>>
+>>   [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]},
+>>
+>>
+>> I can start asn1 from the erl console so I am not sure what I am
+>> missing. Any help is greatly appreciated.
+>>
+>> Best regards.
+>>
+>> --
+>> -rb
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+
+
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131007/863e7358/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000259.html b/_build/static/archives/extend/2013-October/000259.html new file mode 100644 index 00000000..2b966a2a --- /dev/null +++ b/_build/static/archives/extend/2013-October/000259.html @@ -0,0 +1,165 @@ + + + + [99s-extend] Problem with cowboy ssl example + + + + + + + + + + +

[99s-extend] Problem with cowboy ssl example

+ Ryan Brown + ryankbrown at gmail.com +
+ Tue Oct 8 17:33:36 CEST 2013 +

+
+ +
Just to complete the loop. As would be expected, adding asn1 to the app.src
+applications fixes the issue.
+
+Thank you,
+
+Ryan
+
+
+On Mon, Oct 7, 2013 at 10:24 PM, Ryan Brown <ryankbrown at gmail.com> wrote:
+
+> Thanks Loïc. I am actually running R16B on a macbook OS X 10.8. (I'm
+> wondering if the Od could have any effect?)
+>
+> Best,
+>
+> Ryan
+>
+>
+> On Mon, Oct 7, 2013 at 10:13 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> I'm guessing you run an older Erlang which had that issue. Either upgrade
+>> Erlang or add asn1 to the list of apps to include in the release (and open
+>> a ticket for it please so it can be made to work with older versions).
+>>
+>>
+>> On 10/08/2013 05:55 AM, Ryan Brown wrote:
+>>
+>>> I was trying to compile and run the ssl_hello_world example in the
+>>> cowboy project and am getting the following error at start-up:
+>>>
+>>>
+>>>   =INFO REPORT==== 7-Oct-2013::21:38:01 ===
+>>>
+>>>
+>>>        application: ssl_hello_world
+>>>
+>>>
+>>>        exited: {bad_return,
+>>>
+>>>
+>>>                 {{ssl_hello_world_app,start,[**normal,[]]},
+>>>
+>>>
+>>>                  {'EXIT',
+>>>
+>>>
+>>>                   {{badmatch,
+>>>
+>>>
+>>>                     {error,
+>>>
+>>>
+>>>                      {{shutdown,
+>>>
+>>>
+>>>                        {failed_to_start_child,ranch_**acceptors_sup,
+>>>
+>>>
+>>>                         {{case_clause,
+>>>
+>>>
+>>>                           {error,{"no such file or
+>>> directory","asn1.app"}}},
+>>>
+>>>
+>>>
+>>>   [{ranch,require,1,[{file,"src/**ranch.erl"},{line,207}]},
+>>>
+>>>
+>>> I can start asn1 from the erl console so I am not sure what I am
+>>> missing. Any help is greatly appreciated.
+>>>
+>>> Best regards.
+>>>
+>>> --
+>>> -rb
+>>>
+>>>
+>>> ______________________________**_________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>>
+>>>
+>>
+>> --
+>> Loďc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>>
+>
+>
+>
+> --
+> -rb
+>
+
+
+
+-- 
+-rb
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131008/8752fdd7/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000260.html b/_build/static/archives/extend/2013-October/000260.html new file mode 100644 index 00000000..9b301502 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000260.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Oct 9 15:27:25 CEST 2013 +

+
+ +
Hi,
+
+When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+
+Thanks,
+Lee
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000261.html b/_build/static/archives/extend/2013-October/000261.html new file mode 100644 index 00000000..50e3e58e --- /dev/null +++ b/_build/static/archives/extend/2013-October/000261.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 9 15:31:04 CEST 2013 +

+
+ +
cowboy_req:host/1?
+
+Please use the nice manual we have now.
+
+   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+
+On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+> Hi,
+>
+> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>
+> Thanks,
+> Lee
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000262.html b/_build/static/archives/extend/2013-October/000262.html new file mode 100644 index 00000000..1484f57d --- /dev/null +++ b/_build/static/archives/extend/2013-October/000262.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Oct 9 17:30:21 CEST 2013 +

+
+ +
Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+
+Thanks,
+Lee
+
+Sent from my iPhone
+
+> On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> cowboy_req:host/1?
+> 
+> Please use the nice manual we have now.
+> 
+>  http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+> 
+>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>> Hi,
+>> 
+>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000263.html b/_build/static/archives/extend/2013-October/000263.html new file mode 100644 index 00000000..d4e0dd90 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000263.html @@ -0,0 +1,108 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 9 17:32:54 CEST 2013 +

+
+ +
In short: you can't.
+
+Browsers may send origin/referer/.. headers depending on the type of 
+request, but you can't rely on them to be real or even just there.
+
+On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+> Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+>
+> Thanks,
+> Lee
+>
+> Sent from my iPhone
+>
+>> On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> cowboy_req:host/1?
+>>
+>> Please use the nice manual we have now.
+>>
+>>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>
+>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>> Hi,
+>>>
+>>> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000264.html b/_build/static/archives/extend/2013-October/000264.html new file mode 100644 index 00000000..7b28dcfe --- /dev/null +++ b/_build/static/archives/extend/2013-October/000264.html @@ -0,0 +1,134 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Nathan Michaels + nathan at nmichaels.org +
+ Wed Oct 9 17:51:14 CEST 2013 +

+
+ +
Is the client making the request to your service on widgets.net because
+things.com sent them there, or is things.com making the request directly on
+behalf of the client? The first is what Loïc is talking about. The second
+is the source IP of the request, which you can definitely get.
+
+
+On Wed, Oct 9, 2013 at 11:32 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> In short: you can't.
+>
+> Browsers may send origin/referer/.. headers depending on the type of
+> request, but you can't rely on them to be real or even just there.
+>
+>
+> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>
+>> Thank you.  I couldn't work out if that's the host being called from or
+>> the host name in the request.  For example, a store called things.commakes a request to my service on
+>> widgets.net.  I need to see that the request is made FROM things.com for
+>> validation purposes. Is it correct that host will provide this?
+>>
+>> Thanks,
+>> Lee
+>>
+>> Sent from my iPhone
+>>
+>>  On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>> cowboy_req:host/1?
+>>>
+>>> Please use the nice manual we have now.
+>>>
+>>>   http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_req<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req>
+>>>
+>>>  On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>> Hi,
+>>>>
+>>>> When receiving a Cowboy request, is there a way to find out which
+>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>> Bullet app, where each call can be made through a given account.  However,
+>>>> I'd like to be able to lock requests for each account to a designated
+>>>> hostname to protect that users account usage.
+>>>>
+>>>> Thanks,
+>>>> Lee
+>>>>
+>>>> ______________________________**_________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>>>
+>>>
+>>>
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>>>
+>>
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> ______________________________**_________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131009/cc05d6f5/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000265.html b/_build/static/archives/extend/2013-October/000265.html new file mode 100644 index 00000000..173b2a44 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000265.html @@ -0,0 +1,132 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Wed Oct 9 19:28:40 CEST 2013 +

+
+ +
Essentially, the REST service endpoint would be on widgets.net while the clients website, in this case things.com, has a JavaScript that makes an AJAX call to widgets.net.  The account on widgets.net for things.com will have the things.com domain registered to its account, so that widgets.net can check to see if the request is coming from an expected domain.
+
+Thanks,
+Lee
+
+
+On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+
+> Is the client making the request to your service on widgets.net because things.com sent them there, or is things.com making the request directly on behalf of the client? The first is what Loïc is talking about. The second is the source IP of the request, which you can definitely get.
+> 
+> 
+> On Wed, Oct 9, 2013 at 11:32 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> In short: you can't.
+> 
+> Browsers may send origin/referer/.. headers depending on the type of request, but you can't rely on them to be real or even just there.
+> 
+> 
+> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+> Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called things.com makes a request to my service on widgets.net.  I need to see that the request is made FROM things.com for validation purposes. Is it correct that host will provide this?
+> 
+> Thanks,
+> Lee
+> 
+> Sent from my iPhone
+> 
+> On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> cowboy_req:host/1?
+> 
+> Please use the nice manual we have now.
+> 
+>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+> 
+> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+> Hi,
+> 
+> When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.
+> 
+> Thanks,
+> Lee
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131009/7c03cefc/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000266.html b/_build/static/archives/extend/2013-October/000266.html new file mode 100644 index 00000000..32c5a245 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000266.html @@ -0,0 +1,189 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Daniel White + daniel at whitehouse.id.au +
+ Thu Oct 10 01:03:08 CEST 2013 +

+
+ +
Depending on your requirements, there is a high likelihood that you
+need to support pre-flight requests.  Especially if you're intending
+on providing credentials in the requests.  Many of the interesting
+headers are not simple headers (for CORS) and require a handshake
+first between browser and server to ensure the headers in question are
+allowed to be sent.
+
+This obviously limits the amount of information you can determine
+about the caller.  One alternative here, is the use of OAuth2 with the
+'access_token' query parameter.  This can be sent along with the
+pre-flight request.
+
+On the other hand, some providers (Github, IIRC) will simply validate
+a CORS request by comparing the 'Origin' against their entire list of
+registered origins.  This opens up some opportunity for abuse by other
+clients in the system, but can be further mitigated by enforcing the
+'Origin' more strictly at the authorization step of the request.
+
+As an aside, I have a cowboy middleware project to do the heavy
+lifting for CORS at https://github.com/danielwhite/cowboy_cors.
+Business policies can be implemented by means of a callback module.
+
+Cheers,
+
+
+On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+> Essentially, the REST service endpoint would be on widgets.net while the
+> clients website, in this case things.com, has a JavaScript that makes an
+> AJAX call to widgets.net.  The account on widgets.net for things.com will
+> have the things.com domain registered to its account, so that widgets.net
+> can check to see if the request is coming from an expected domain.
+>
+> Thanks,
+> Lee
+>
+>
+> On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+>
+> Is the client making the request to your service on widgets.net because
+> things.com sent them there, or is things.com making the request directly on
+> behalf of the client? The first is what Loïc is talking about. The second is
+> the source IP of the request, which you can definitely get.
+>
+>
+> On Wed, Oct 9, 2013 at 11:32 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> In short: you can't.
+>>
+>> Browsers may send origin/referer/.. headers depending on the type of
+>> request, but you can't rely on them to be real or even just there.
+>>
+>>
+>> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>>>
+>>> Thank you.  I couldn't work out if that's the host being called from or
+>>> the host name in the request.  For example, a store called things.com makes
+>>> a request to my service on widgets.net.  I need to see that the request is
+>>> made FROM things.com for validation purposes. Is it correct that host will
+>>> provide this?
+>>>
+>>> Thanks,
+>>> Lee
+>>>
+>>> Sent from my iPhone
+>>>
+>>>> On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>
+>>>> cowboy_req:host/1?
+>>>>
+>>>> Please use the nice manual we have now.
+>>>>
+>>>>   http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>>>
+>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>>> Hi,
+>>>>>
+>>>>> When receiving a Cowboy request, is there a way to find out which
+>>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>>> Bullet app, where each call can be made through a given account.  However,
+>>>>> I'd like to be able to lock requests for each account to a designated
+>>>>> hostname to protect that users account usage.
+>>>>>
+>>>>> Thanks,
+>>>>> Lee
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>
+>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> Erlang Cowboy
+>>>> Nine Nines
+>>>> http://ninenines.eu
+>>
+>>
+>>
+>> --
+>> Loïc Hoguin
+>> Erlang Cowboy
+>> Nine Nines
+>> http://ninenines.eu
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+
+-- 
+Daniel White
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000267.html b/_build/static/archives/extend/2013-October/000267.html new file mode 100644 index 00000000..b403cab5 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000267.html @@ -0,0 +1,197 @@ + + + + [99s-extend] Cowboy Calling Hostname + + + + + + + + + + +

[99s-extend] Cowboy Calling Hostname

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Thu Oct 10 08:05:23 CEST 2013 +

+
+ +
Thank you, Daniel.  The project looks very useful.  At this stage, I don't need to strictly require calls to come from a set domain but would like this to be a hurdle for hackers.  I may set up an IP restriction instead.
+
+Thanks,
+Lee
+
+Sent from my iPhone
+
+> On Oct 10, 2013, at 12:03 AM, Daniel White <daniel at whitehouse.id.au> wrote:
+> 
+> Depending on your requirements, there is a high likelihood that you
+> need to support pre-flight requests.  Especially if you're intending
+> on providing credentials in the requests.  Many of the interesting
+> headers are not simple headers (for CORS) and require a handshake
+> first between browser and server to ensure the headers in question are
+> allowed to be sent.
+> 
+> This obviously limits the amount of information you can determine
+> about the caller.  One alternative here, is the use of OAuth2 with the
+> 'access_token' query parameter.  This can be sent along with the
+> pre-flight request.
+> 
+> On the other hand, some providers (Github, IIRC) will simply validate
+> a CORS request by comparing the 'Origin' against their entire list of
+> registered origins.  This opens up some opportunity for abuse by other
+> clients in the system, but can be further mitigated by enforcing the
+> 'Origin' more strictly at the authorization step of the request.
+> 
+> As an aside, I have a cowboy middleware project to do the heavy
+> lifting for CORS at https://github.com/danielwhite/cowboy_cors.
+> Business policies can be implemented by means of a callback module.
+> 
+> Cheers,
+> 
+> 
+>> On Thu, Oct 10, 2013 at 4:28 AM, Lee Sylvester <lee.sylvester at gmail.com> wrote:
+>> Essentially, the REST service endpoint would be on widgets.net while the
+>> clients website, in this case things.com, has a JavaScript that makes an
+>> AJAX call to widgets.net.  The account on widgets.net for things.com will
+>> have the things.com domain registered to its account, so that widgets.net
+>> can check to see if the request is coming from an expected domain.
+>> 
+>> Thanks,
+>> Lee
+>> 
+>> 
+>> On 9 Oct 2013, at 16:51, Nathan Michaels <nathan at nmichaels.org> wrote:
+>> 
+>> Is the client making the request to your service on widgets.net because
+>> things.com sent them there, or is things.com making the request directly on
+>> behalf of the client? The first is what Loïc is talking about. The second is
+>> the source IP of the request, which you can definitely get.
+>> 
+>> 
+>>> On Wed, Oct 9, 2013 at 11:32 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>> In short: you can't.
+>>> 
+>>> Browsers may send origin/referer/.. headers depending on the type of
+>>> request, but you can't rely on them to be real or even just there.
+>>> 
+>>> 
+>>>> On 10/09/2013 05:30 PM, Lee Sylvester wrote:
+>>>> 
+>>>> Thank you.  I couldn't work out if that's the host being called from or
+>>>> the host name in the request.  For example, a store called things.com makes
+>>>> a request to my service on widgets.net.  I need to see that the request is
+>>>> made FROM things.com for validation purposes. Is it correct that host will
+>>>> provide this?
+>>>> 
+>>>> Thanks,
+>>>> Lee
+>>>> 
+>>>> Sent from my iPhone
+>>>> 
+>>>>> On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>> 
+>>>>> cowboy_req:host/1?
+>>>>> 
+>>>>> Please use the nice manual we have now.
+>>>>> 
+>>>>>  http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req
+>>>>> 
+>>>>>> On 10/09/2013 03:27 PM, Lee Sylvester wrote:
+>>>>>> Hi,
+>>>>>> 
+>>>>>> When receiving a Cowboy request, is there a way to find out which
+>>>>>> hostname the user made the request from?  I'm using CORS in my REST and
+>>>>>> Bullet app, where each call can be made through a given account.  However,
+>>>>>> I'd like to be able to lock requests for each account to a designated
+>>>>>> hostname to protect that users account usage.
+>>>>>> 
+>>>>>> Thanks,
+>>>>>> Lee
+>>>>>> 
+>>>>>> _______________________________________________
+>>>>>> Extend mailing list
+>>>>>> Extend at lists.ninenines.eu
+>>>>>> http://lists.ninenines.eu:81/listinfo/extend
+>>>>> 
+>>>>> 
+>>>>> 
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> Erlang Cowboy
+>>>>> Nine Nines
+>>>>> http://ninenines.eu
+>>> 
+>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> Erlang Cowboy
+>>> Nine Nines
+>>> http://ninenines.eu
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>> 
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> 
+> 
+> -- 
+> Daniel White
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000268.html b/_build/static/archives/extend/2013-October/000268.html new file mode 100644 index 00000000..95734509 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000268.html @@ -0,0 +1,100 @@ + + + + [99s-extend] SSL Example + + + + + + + + + + +

[99s-extend] SSL Example

+ 比邻比特Prinbit + prinbit at gmail.com +
+ Tue Oct 15 03:53:05 CEST 2013 +

+
+ +
Hi Essen,
+
+Any suggestion on the question?
+
+I can't receive any email from the lists.
+
+Thanks in advance
+
+2013/10/13 比邻比特Prinbit <prinbit at gmail.com>:
+> Hi essen
+>
+> In your ssl example, three files are needed in ssl folder, they are
+> cowboy-ca.crt, server.crt and server.key.
+>
+> I am applying for a free ssl in startssl, and found there are only
+> server.crt and server.key generated.
+>
+> What is cowboy-ca.crt used for?
+>
+> I want to add ssl certificate in http://prinbit.com, my question is
+> that is cowboy-ca.crt is needed for me?
+>
+> Thanks in advance
+>
+> --
+> Thanks & Regards,
+>
+> PrinBit, Video Chatting and Collaborative Coding, Together
+>
+> http://prinbit.com
+
+
+
+-- 
+Thanks & Regards,
+
+PrinBit, Video Chatting and Collaborative Coding, Together
+
+http://prinbit.com
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000269.html b/_build/static/archives/extend/2013-October/000269.html new file mode 100644 index 00000000..5c7ddf49 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000269.html @@ -0,0 +1,83 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 04:55:28 CEST 2013 +

+
+ +
Hello,
+
+the documentation for `init` at
+http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says:
+
+The receive loop will run for a duration of up to Timeout milliseconds
+after it last received data from the socket, at which point it will stop
+and send a 204 No Content reply.
+
+What socket does it refer to? I had an impression that the loop handles
+erlang messages. Do these messages come through a socket (sorry about a
+trivial question, but I am new to erlang), and this is the socket that the
+docs talk about?
+
+The reason why I am asking is because I used to have a Timeout of 60000,
+and even though messages kept coming non stop, it still kept disconnecting
+after a minute, until I set Timeout to infinity.
+
+thanks
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/94506752/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000270.html b/_build/static/archives/extend/2013-October/000270.html new file mode 100644 index 00000000..74979150 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000270.html @@ -0,0 +1,102 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 05:01:38 CEST 2013 +

+
+ +
The socket connected to the client.
+
+TCP isn't perfect, there is no way to be 100% sure the client is still 
+connected, hence the timeout. If the client is still up you should make 
+it reconnect.
+
+On 10/16/2013 04:55 AM, akonsu wrote:
+> Hello,
+>
+> the documentation for `init` at
+> http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler says:
+>
+> The receive loop will run for a duration of up to Timeout milliseconds
+> after it last received data from the socket, at which point it will stop
+> and send a 204 No Content reply.
+>
+> What socket does it refer to? I had an impression that the loop handles
+> erlang messages. Do these messages come through a socket (sorry about a
+> trivial question, but I am new to erlang), and this is the socket that
+> the docs talk about?
+>
+> The reason why I am asking is because I used to have a Timeout of 60000,
+> and even though messages kept coming non stop, it still kept
+> disconnecting after a minute, until I set Timeout to infinity.
+>
+> thanks
+> Konstantin
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000271.html b/_build/static/archives/extend/2013-October/000271.html new file mode 100644 index 00000000..a71e5ae4 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000271.html @@ -0,0 +1,113 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 05:03:53 CEST 2013 +

+
+ +
so it will disconnect if the client only listens and sends nothing to the
+socket, correct?
+
+
+2013/10/15 Loïc Hoguin <essen at ninenines.eu>
+
+> The socket connected to the client.
+>
+> TCP isn't perfect, there is no way to be 100% sure the client is still
+> connected, hence the timeout. If the client is still up you should make it
+> reconnect.
+>
+>
+> On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>> Hello,
+>>
+>> the documentation for `init` at
+>> http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_**loop_handler<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>says:
+>>
+>> The receive loop will run for a duration of up to Timeout milliseconds
+>> after it last received data from the socket, at which point it will stop
+>> and send a 204 No Content reply.
+>>
+>> What socket does it refer to? I had an impression that the loop handles
+>> erlang messages. Do these messages come through a socket (sorry about a
+>> trivial question, but I am new to erlang), and this is the socket that
+>> the docs talk about?
+>>
+>> The reason why I am asking is because I used to have a Timeout of 60000,
+>> and even though messages kept coming non stop, it still kept
+>> disconnecting after a minute, until I set Timeout to infinity.
+>>
+>> thanks
+>> Konstantin
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/591e8649/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000272.html b/_build/static/archives/extend/2013-October/000272.html new file mode 100644 index 00000000..7a3052d4 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000272.html @@ -0,0 +1,132 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 05:11:30 CEST 2013 +

+
+ +
Yep. And it will also disconnect if the client sends too much. It has to 
+disconnect and reconnect eventually, there's no way around it.
+
+On 10/16/2013 05:03 AM, akonsu wrote:
+> so it will disconnect if the client only listens and sends nothing to
+> the socket, correct?
+>
+>
+> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     The socket connected to the client.
+>
+>     TCP isn't perfect, there is no way to be 100% sure the client is
+>     still connected, hence the timeout. If the client is still up you
+>     should make it reconnect.
+>
+>
+>     On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>         Hello,
+>
+>         the documentation for `init` at
+>         http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler
+>         <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>
+>         says:
+>
+>         The receive loop will run for a duration of up to Timeout
+>         milliseconds
+>         after it last received data from the socket, at which point it
+>         will stop
+>         and send a 204 No Content reply.
+>
+>         What socket does it refer to? I had an impression that the loop
+>         handles
+>         erlang messages. Do these messages come through a socket (sorry
+>         about a
+>         trivial question, but I am new to erlang), and this is the
+>         socket that
+>         the docs talk about?
+>
+>         The reason why I am asking is because I used to have a Timeout
+>         of 60000,
+>         and even though messages kept coming non stop, it still kept
+>         disconnecting after a minute, until I set Timeout to infinity.
+>
+>         thanks
+>         Konstantin
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>
+>
+>
+>
+>     --
+>     Loďc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000273.html b/_build/static/archives/extend/2013-October/000273.html new file mode 100644 index 00000000..2639fffd --- /dev/null +++ b/_build/static/archives/extend/2013-October/000273.html @@ -0,0 +1,156 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 05:31:46 CEST 2013 +

+
+ +
thanks for your help. suppose that I want to stream live audio. I do not
+know how long my audio program will be, and as I stream it, if I have a
+timeout, the server will just disconnect the user that listens to the audio
+in the browser. and the browser won't reconnect. Would you suggest the
+"right" way to implement something like that? Would infinite timeout
+suffice? or is it a bad practice? another type of handler maybe?
+
+
+2013/10/15 Loïc Hoguin <essen at ninenines.eu>
+
+> Yep. And it will also disconnect if the client sends too much. It has to
+> disconnect and reconnect eventually, there's no way around it.
+>
+>
+> On 10/16/2013 05:03 AM, akonsu wrote:
+>
+>> so it will disconnect if the client only listens and sends nothing to
+>> the socket, correct?
+>>
+>>
+>> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>>
+>>
+>>     The socket connected to the client.
+>>
+>>     TCP isn't perfect, there is no way to be 100% sure the client is
+>>     still connected, hence the timeout. If the client is still up you
+>>     should make it reconnect.
+>>
+>>
+>>     On 10/16/2013 04:55 AM, akonsu wrote:
+>>
+>>         Hello,
+>>
+>>         the documentation for `init` at
+>>         http://ninenines.eu/docs/en/__**cowboy/HEAD/manual/cowboy___**
+>> loop_handler<http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler>
+>>
+>>         <http://ninenines.eu/docs/en/**cowboy/HEAD/manual/cowboy_**
+>> loop_handler<http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>
+>> >
+>>         says:
+>>
+>>         The receive loop will run for a duration of up to Timeout
+>>         milliseconds
+>>         after it last received data from the socket, at which point it
+>>         will stop
+>>         and send a 204 No Content reply.
+>>
+>>         What socket does it refer to? I had an impression that the loop
+>>         handles
+>>         erlang messages. Do these messages come through a socket (sorry
+>>         about a
+>>         trivial question, but I am new to erlang), and this is the
+>>         socket that
+>>         the docs talk about?
+>>
+>>         The reason why I am asking is because I used to have a Timeout
+>>         of 60000,
+>>         and even though messages kept coming non stop, it still kept
+>>         disconnecting after a minute, until I set Timeout to infinity.
+>>
+>>         thanks
+>>         Konstantin
+>>
+>>
+>>         ______________________________**___________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.**ninenines.eu<Extend at lists.ninenines.eu>
+>> >
+>>         http://lists.ninenines.eu:81/_**_listinfo/extend<http://lists.ninenines.eu:81/__listinfo/extend>
+>>
+>>         <http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>> >
+>>
+>>
+>>
+>>     --
+>>     Loďc Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>
+>>
+>>
+>
+> --
+> Loïc Hoguin
+>
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/203060cc/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000274.html b/_build/static/archives/extend/2013-October/000274.html new file mode 100644 index 00000000..98d9d064 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000274.html @@ -0,0 +1,183 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 05:40:31 CEST 2013 +

+
+ +
Infinite is bad practice, yes. Infinite means some connections will 
+*never* be closed, eating FDs and memory for nothing.
+
+I'm not sure why you want to receive messages, you could just use a 
+normal handler that asks for more data, sends it, ask for more data, 
+sends it, etc.
+
+On 10/16/2013 05:31 AM, akonsu wrote:
+> thanks for your help. suppose that I want to stream live audio. I do not
+> know how long my audio program will be, and as I stream it, if I have a
+> timeout, the server will just disconnect the user that listens to the
+> audio in the browser. and the browser won't reconnect. Would you suggest
+> the "right" way to implement something like that? Would infinite timeout
+> suffice? or is it a bad practice? another type of handler maybe?
+>
+>
+> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Yep. And it will also disconnect if the client sends too much. It
+>     has to disconnect and reconnect eventually, there's no way around it.
+>
+>
+>     On 10/16/2013 05:03 AM, akonsu wrote:
+>
+>         so it will disconnect if the client only listens and sends
+>         nothing to
+>         the socket, correct?
+>
+>
+>         2013/10/15 Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu> <mailto:essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>>>
+>
+>
+>              The socket connected to the client.
+>
+>              TCP isn't perfect, there is no way to be 100% sure the
+>         client is
+>              still connected, hence the timeout. If the client is still
+>         up you
+>              should make it reconnect.
+>
+>
+>              On 10/16/2013 04:55 AM, akonsu wrote:
+>
+>                  Hello,
+>
+>                  the documentation for `init` at
+>         http://ninenines.eu/docs/en/____cowboy/HEAD/manual/cowboy_____loop_handler
+>         <http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler>
+>
+>
+>         <http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler
+>         <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler>>
+>                  says:
+>
+>                  The receive loop will run for a duration of up to Timeout
+>                  milliseconds
+>                  after it last received data from the socket, at which
+>         point it
+>                  will stop
+>                  and send a 204 No Content reply.
+>
+>                  What socket does it refer to? I had an impression that
+>         the loop
+>                  handles
+>                  erlang messages. Do these messages come through a
+>         socket (sorry
+>                  about a
+>                  trivial question, but I am new to erlang), and this is the
+>                  socket that
+>                  the docs talk about?
+>
+>                  The reason why I am asking is because I used to have a
+>         Timeout
+>                  of 60000,
+>                  and even though messages kept coming non stop, it still
+>         kept
+>                  disconnecting after a minute, until I set Timeout to
+>         infinity.
+>
+>                  thanks
+>                  Konstantin
+>
+>
+>                  ___________________________________________________
+>                  Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.__ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         http://lists.ninenines.eu:81/____listinfo/extend
+>         <http://lists.ninenines.eu:81/__listinfo/extend>
+>
+>                  <http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>>
+>
+>
+>
+>              --
+>              Loďc Hoguin
+>              Erlang Cowboy
+>              Nine Nines
+>         http://ninenines.eu
+>
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000275.html b/_build/static/archives/extend/2013-October/000275.html new file mode 100644 index 00000000..946261ed --- /dev/null +++ b/_build/static/archives/extend/2013-October/000275.html @@ -0,0 +1,84 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 05:48:42 CEST 2013 +

+
+ +
1. do you mean that there is no way on the server side to tell if the
+client has disconnected?
+
+2. if I use a normal handler, I will still run into the same problem, it
+does not matter which handler I use, from the standpoint of deciding
+whether the client is still there, right?
+
+I am confused as to how I can implement my streaming and not drop the
+connection on each client and yet make sure I do close the connections when
+the clients disconnect...
+
+
+2013/10/15 Loïc Hoguin <essen at ninenines.eu>
+
+> Infinite is bad practice, yes. Infinite means some connections will
+> *never* be closed, eating FDs and memory for nothing.
+>
+> I'm not sure why you want to receive messages, you could just use a normal
+> handler that asks for more data, sends it, ask for more data, sends it, etc.
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131015/bac10460/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000276.html b/_build/static/archives/extend/2013-October/000276.html new file mode 100644 index 00000000..4445393d --- /dev/null +++ b/_build/static/archives/extend/2013-October/000276.html @@ -0,0 +1,98 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 06:07:26 CEST 2013 +

+
+ +
On 10/16/2013 05:48 AM, akonsu wrote:
+> 1. do you mean that there is no way on the server side to tell if the
+> client has disconnected?
+
+There are ways, and Cowboy will happily detect them. There's also the 
+problem that a side may be closed without the other side knowing about 
+it, which is why you need timeouts.
+
+> 2. if I use a normal handler, I will still run into the same problem, it
+> does not matter which handler I use, from the standpoint of deciding
+> whether the client is still there, right?
+
+If the client is gone, the send will fail. Normal handlers are pretty 
+much the same except they don't have a timeout, because your code has an 
+explicit end.
+
+> I am confused as to how I can implement my streaming and not drop the
+> connection on each client and yet make sure I do close the connections
+> when the clients disconnect...
+>
+>
+> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Infinite is bad practice, yes. Infinite means some connections will
+>     *never* be closed, eating FDs and memory for nothing.
+>
+>     I'm not sure why you want to receive messages, you could just use a
+>     normal handler that asks for more data, sends it, ask for more data,
+>     sends it, etc.
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000277.html b/_build/static/archives/extend/2013-October/000277.html new file mode 100644 index 00000000..ae9bd3ff --- /dev/null +++ b/_build/static/archives/extend/2013-October/000277.html @@ -0,0 +1,118 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 06:12:29 CEST 2013 +

+
+ +
thanks. one more question if you do not mind. you say that we need timeouts
+when the client does not notify us when it dies. but then you say that if
+the client dies then the socket write will fail. to me this sounds like a
+contradiction. would you please clarify?
+
+(I assume that this is the problem that we are discussing:
+http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect,
+right?)
+
+
+2013/10/16 Loïc Hoguin <essen at ninenines.eu>
+
+> On 10/16/2013 05:48 AM, akonsu wrote:
+>
+>> 1. do you mean that there is no way on the server side to tell if the
+>> client has disconnected?
+>>
+>
+> There are ways, and Cowboy will happily detect them. There's also the
+> problem that a side may be closed without the other side knowing about it,
+> which is why you need timeouts.
+>
+>
+>  2. if I use a normal handler, I will still run into the same problem, it
+>> does not matter which handler I use, from the standpoint of deciding
+>> whether the client is still there, right?
+>>
+>
+> If the client is gone, the send will fail. Normal handlers are pretty much
+> the same except they don't have a timeout, because your code has an
+> explicit end.
+>
+>  I am confused as to how I can implement my streaming and not drop the
+>> connection on each client and yet make sure I do close the connections
+>> when the clients disconnect...
+>>
+>>
+>> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>>
+>>
+>>     Infinite is bad practice, yes. Infinite means some connections will
+>>     *never* be closed, eating FDs and memory for nothing.
+>>
+>>     I'm not sure why you want to receive messages, you could just use a
+>>     normal handler that asks for more data, sends it, ask for more data,
+>>     sends it, etc.
+>>
+>>
+>
+> --
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131016/edbc349c/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000278.html b/_build/static/archives/extend/2013-October/000278.html new file mode 100644 index 00000000..0bded9f4 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000278.html @@ -0,0 +1,142 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 06:35:43 CEST 2013 +

+
+ +
Loop handlers are designed to wait for a long time with the socket 
+*idle* and then eventually send one response then close the socket. 
+Things like long-polling.
+
+What you are doing is just streaming, for which you do not need a 
+timeout because the socket isn't idle. You are just sending a large 
+response, and normal handlers are perfectly capable of doing that.
+
+On 10/16/2013 06:12 AM, akonsu wrote:
+> thanks. one more question if you do not mind. you say that we need
+> timeouts when the client does not notify us when it dies. but then you
+> say that if the client dies then the socket write will fail. to me this
+> sounds like a contradiction. would you please clarify?
+>
+> (I assume that this is the problem that we are discussing:
+> http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect,
+> right?)
+>
+>
+> 2013/10/16 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     On 10/16/2013 05:48 AM, akonsu wrote:
+>
+>         1. do you mean that there is no way on the server side to tell
+>         if the
+>         client has disconnected?
+>
+>
+>     There are ways, and Cowboy will happily detect them. There's also
+>     the problem that a side may be closed without the other side knowing
+>     about it, which is why you need timeouts.
+>
+>
+>         2. if I use a normal handler, I will still run into the same
+>         problem, it
+>         does not matter which handler I use, from the standpoint of deciding
+>         whether the client is still there, right?
+>
+>
+>     If the client is gone, the send will fail. Normal handlers are
+>     pretty much the same except they don't have a timeout, because your
+>     code has an explicit end.
+>
+>         I am confused as to how I can implement my streaming and not
+>         drop the
+>         connection on each client and yet make sure I do close the
+>         connections
+>         when the clients disconnect...
+>
+>
+>         2013/10/15 Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu> <mailto:essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>>>
+>
+>
+>              Infinite is bad practice, yes. Infinite means some
+>         connections will
+>              *never* be closed, eating FDs and memory for nothing.
+>
+>              I'm not sure why you want to receive messages, you could
+>         just use a
+>              normal handler that asks for more data, sends it, ask for
+>         more data,
+>              sends it, etc.
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000279.html b/_build/static/archives/extend/2013-October/000279.html new file mode 100644 index 00000000..8d3af11e --- /dev/null +++ b/_build/static/archives/extend/2013-October/000279.html @@ -0,0 +1,81 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Wed Oct 16 06:42:02 CEST 2013 +

+
+ +
ok. the data that I need to send are coming as erlang messages to the
+process that runs my handler. so it sounds like if I want to use the
+"normal" cowboy_http_handler, then I need a receive loop inside handle(Req,
+State) callback, right? Basically, my response stream will potentially
+never end, I do not know how to handle this properly in cowboy...
+
+
+2013/10/16 Loïc Hoguin <essen at ninenines.eu>
+
+> Loop handlers are designed to wait for a long time with the socket *idle*
+> and then eventually send one response then close the socket. Things like
+> long-polling.
+>
+> What you are doing is just streaming, for which you do not need a timeout
+> because the socket isn't idle. You are just sending a large response, and
+> normal handlers are perfectly capable of doing that.
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131016/abe38a1a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000280.html b/_build/static/archives/extend/2013-October/000280.html new file mode 100644 index 00000000..24d9e1e3 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000280.html @@ -0,0 +1,91 @@ + + + + [99s-extend] timeout in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeout in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Oct 16 06:48:05 CEST 2013 +

+
+ +
Then use a loop handler, set its timeout to infinity *but* create a new 
+timeout that checks regularly if the handler is active or not to be able 
+to kill it off in case something happens.
+
+On 10/16/2013 06:42 AM, akonsu wrote:
+> ok. the data that I need to send are coming as erlang messages to the
+> process that runs my handler. so it sounds like if I want to use the
+> "normal" cowboy_http_handler, then I need a receive loop
+> inside handle(Req, State) callback, right? Basically, my response stream
+> will potentially never end, I do not know how to handle this properly in
+> cowboy...
+>
+>
+> 2013/10/16 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Loop handlers are designed to wait for a long time with the socket
+>     *idle* and then eventually send one response then close the socket.
+>     Things like long-polling.
+>
+>     What you are doing is just streaming, for which you do not need a
+>     timeout because the socket isn't idle. You are just sending a large
+>     response, and normal handlers are perfectly capable of doing that.
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000281.html b/_build/static/archives/extend/2013-October/000281.html new file mode 100644 index 00000000..621c5af7 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000281.html @@ -0,0 +1,83 @@ + + + + [99s-extend] handler and a linked process + + + + + + + + + + +

[99s-extend] handler and a linked process

+ akonsu + akonsu at gmail.com +
+ Fri Oct 18 15:15:37 CEST 2013 +

+
+ +
Hi,
+
+I have a handler that spawns a process and links to this process. the new
+process does not trap exit signals.
+
+When I open the URL that is handled by this handler in the browser, and
+stop the browser before the handler finishes the request, the handler is
+terminated and my terminate function is called with the Reason set to
+{error,closed} or something similar.
+
+When this happens, the linked process does not get killed, so I have to
+call exit on it from the terminate function.
+
+is this by design? I suppose when I cancel the browser request, the handler
+is exited with normal exit code, correct? could you point me to the source
+code for that part? it is perhaps in the "ranch" repo, no?
+
+thanks in advance
+
+konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131018/00d4df12/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000282.html b/_build/static/archives/extend/2013-October/000282.html new file mode 100644 index 00000000..a3ec5417 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000282.html @@ -0,0 +1,105 @@ + + + + [99s-extend] handler and a linked process + + + + + + + + + + +

[99s-extend] handler and a linked process

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Oct 21 15:07:34 CEST 2013 +

+
+ +
Hey,
+
+I'm guessing you use loop handler or websocket handler? The browser 
+closing the connection in these cases is perfectly normal, that's part 
+of the deal. What you can do is monitor the connection process from the 
+other process if you need to go down in all cases. Links are only useful 
+for crashing on errors.
+
+On 10/18/2013 03:15 PM, akonsu wrote:
+> Hi,
+>
+> I have a handler that spawns a process and links to this process. the
+> new process does not trap exit signals.
+>
+> When I open the URL that is handled by this handler in the browser, and
+> stop the browser before the handler finishes the request, the handler is
+> terminated and my terminate function is called with the Reason set to
+> {error,closed} or something similar.
+>
+> When this happens, the linked process does not get killed, so I have to
+> call exit on it from the terminate function.
+>
+> is this by design? I suppose when I cancel the browser request, the
+> handler is exited with normal exit code, correct? could you point me to
+> the source code for that part? it is perhaps in the "ranch" repo, no?
+>
+> thanks in advance
+>
+> konstantin
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000283.html b/_build/static/archives/extend/2013-October/000283.html new file mode 100644 index 00000000..7205f1a7 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000283.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Generate url in cowboy + + + + + + + + + + +

[99s-extend] Generate url in cowboy

+ Antonio Valente + antonio.valente at statpro.com +
+ Tue Oct 22 10:51:14 CEST 2013 +

+
+ +
Hi all,
+I need to automatically generate urls from the dispatcher configuration: 
+I'm looking for some kind of function that, given the dispatcher 
+configuration, a module and a list of bindings, returns an url.
+
+For example, if I have the following dispatch configuration:
+
+     [
+     {'_', [
+
+     {"/api/v1/container/:resource/something", a_module, []},
+     ]}
+     ].
+
+I'd like to do something like:
+
+<<"/api/v1/container/replaced/something">> = generate_url(Dispatch, 
+a_module, [{resource, "replaced"}]).
+
+Is there such a function? If not, can you give me some advice to write one?
+
+Thanks
+Antonio
+
+
+This message is private and confidential. If you have received this message in error, please notify us and remove it from your system. Any views or opinions presented in this email are solely those of the author and might not represent those of StatPro. Warning: Although StatPro has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000284.html b/_build/static/archives/extend/2013-October/000284.html new file mode 100644 index 00000000..89cdd668 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000284.html @@ -0,0 +1,73 @@ + + + + [99s-extend] cowboy_rest, POST and redirect + + + + + + + + + + +

[99s-extend] cowboy_rest, POST and redirect

+ Rolph de Ruiter + Rolph.deRuiter at spilgames.com +
+ Tue Oct 29 10:00:53 CET 2013 +

+
+ +
Hi,
+
+I'm using cowboy_rest for a part of our api to handle POST requests. Under certain conditions, I would like to redirect to a new location (based on availability of the redirect qs parameter).
+I was unable to get the moved_temporarily/2 callback to work (was not invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. This works, however, every time it produces an error in the emulator process:
+ [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26 bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7 bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+
+Can you point me out how to (ideally) make use of moved_temporarily/2 or how I can prevent cowboy_rest from wanting to reply with 204 in this case?
+
+Cheers,
+Rolph
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/5fc5da75/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000285.html b/_build/static/archives/extend/2013-October/000285.html new file mode 100644 index 00000000..0976552b --- /dev/null +++ b/_build/static/archives/extend/2013-October/000285.html @@ -0,0 +1,97 @@ + + + + [99s-extend] cowboy_rest, POST and redirect + + + + + + + + + + +

[99s-extend] cowboy_rest, POST and redirect

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Oct 29 10:09:20 CET 2013 +

+
+ +
On 10/29/2013 10:00 AM, Rolph de Ruiter wrote:
+> Hi,
+>
+> I'm using cowboy_rest for a part of our api to handle POST requests.
+> Under certain conditions, I would like to redirect to a new location
+> (based on availability of the redirect qs parameter).
+> I was unable to get the moved_temporarily/2 callback to work (was not
+> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4.
+> This works, however, every time it produces an error in the emulator
+> process:
+>   [error] emulator Error in process <0.509.0> on node 'api at dev.loc' with
+> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0
+> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4
+> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26
+> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5
+> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14
+> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27
+> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7
+> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14
+> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6
+> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21
+> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+>
+> Can you point me out how to (ideally) make use of moved_temporarily/2 or
+> how I can prevent cowboy_rest from wanting to reply with 204 in this case?
+
+moved_temporarily is only called if the resource previously existed.
+
+As for calling reply yourself, you just need to return {halt, NewReq, 
+State} afterwards.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000286.html b/_build/static/archives/extend/2013-October/000286.html new file mode 100644 index 00000000..bc94b505 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000286.html @@ -0,0 +1,117 @@ + + + + [99s-extend] cowboy_rest, POST and redirect + + + + + + + + + + +

[99s-extend] cowboy_rest, POST and redirect

+ Rolph de Ruiter + Rolph.deRuiter at spilgames.com +
+ Tue Oct 29 10:16:15 CET 2013 +

+
+ +
(forgot to include the list)
+
+On 10/29/13 10:14 AM, "Rolph de Ruiter" <Rolph.deRuiter at spilgames.com>
+wrote:
+
+>Thanks!
+>
+>{halt, NewReq, State} worked like a charm :)
+>
+>Cheers,
+>Rolph
+>
+>On 10/29/13 10:09 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+>
+>>On 10/29/2013 10:00 AM, Rolph de Ruiter wrote:
+>>> Hi,
+>>>
+>>> I'm using cowboy_rest for a part of our api to handle POST requests.
+>>> Under certain conditions, I would like to redirect to a new location
+>>> (based on availability of the redirect qs parameter).
+>>> I was unable to get the moved_temporarily/2 callback to work (was not
+>>> invoked at al). So I just do the 302 myself, using cowboy_req:reply/4.
+>>> This works, however, every time it produces an error in the emulator
+>>> process:
+>>>   [error] emulator Error in process <0.509.0> on node 'api at dev.loc'
+>>>with
+>>> exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0
+>>> bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4
+>>> bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15
+>>>bytes>>,undefined,8000,<<26
+>>> bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5
+>>> bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14
+>>> bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27
+>>> bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33 bytes>>},{<<7
+>>> bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14
+>>> bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6
+>>> bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21
+>>> bytes>>,[]}},{<<17 bytes>>,undefined},{<<13 bytes>>,...
+>>>
+>>> Can you point me out how to (ideally) make use of moved_temporarily/2
+>>>or
+>>> how I can prevent cowboy_rest from wanting to reply with 204 in this
+>>>case?
+>>
+>>moved_temporarily is only called if the resource previously existed.
+>>
+>>As for calling reply yourself, you just need to return {halt, NewReq,
+>>State} afterwards.
+>>
+>>-- 
+>>Loïc Hoguin
+>>Erlang Cowboy
+>>Nine Nines
+>>http://ninenines.eu
+>
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000287.html b/_build/static/archives/extend/2013-October/000287.html new file mode 100644 index 00000000..a4a09c33 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000287.html @@ -0,0 +1,103 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Tue Oct 29 21:25:54 CET 2013 +

+
+ +
My situation is that I have a rest handler that may fail due to invalid url
+segments.  Example situation:
+
+
+init(_Transport, _Req, _Opts) ->
+        {upgrade, protocol, cowboy_rest}.
+
+content_types_provided(Req, State) ->
+    {[{<<"application/json">>, get_json}], Req, State}.
+
+get_json(Req0, State) ->
+    {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+[param1, param2, param3, ....]),
+
+    case catch other_module:request(Params) of
+        {'EXIT', {badarg, _}} ->
+            hmmm, Params were bad and I would like to return a 404 code now.
+        Result ->
+            {jiffy:encode(Result), Req1, State}
+    end.
+
+
+
+So I would like to return a 404 code when my underlying request function
+fails, but it appears my choices are:
+
+- return a 200 (ok) response with data.
+- crash and cause a 500 (Internal Server Error) response to be returned.
+Not exactly the sentiment I want.
+
+
+Is there some other way to cause a 404 response?
+
+I realize I could add path constraint functions, but I will be replicating
+logic from my underlying request function.  Furthermore, the constraint
+functions consider parameters in isolation, so that won't work if the
+validity of parameters is coupled.
+
+Thanks,
+Dan.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/a9204600/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000288.html b/_build/static/archives/extend/2013-October/000288.html new file mode 100644 index 00000000..50c515f5 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000288.html @@ -0,0 +1,110 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Ivan uemlianin + ivan at llaisdy.com +
+ Tue Oct 29 22:01:30 CET 2013 +

+
+ +
Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+
+Ivan
+
+--
+festina lente
+
+
+On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+
+> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+> 
+> 
+> init(_Transport, _Req, _Opts) ->
+>         {upgrade, protocol, cowboy_rest}.
+> 
+> content_types_provided(Req, State) ->
+>     {[{<<"application/json">>, get_json}], Req, State}.
+> 
+> get_json(Req0, State) ->
+>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+> 
+>     case catch other_module:request(Params) of
+>         {'EXIT', {badarg, _}} ->
+>             hmmm, Params were bad and I would like to return a 404 code now.
+>         Result ->
+>             {jiffy:encode(Result), Req1, State}
+>     end.
+> 
+> 
+> 
+> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+> 
+> - return a 200 (ok) response with data.
+> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+> 
+> 
+> Is there some other way to cause a 404 response?
+> 
+> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+> 
+> Thanks,
+> Dan.
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131029/3df30c1d/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000289.html b/_build/static/archives/extend/2013-October/000289.html new file mode 100644 index 00000000..35391c10 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000289.html @@ -0,0 +1,154 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Wed Oct 30 15:58:41 CET 2013 +

+
+ +
Well, this sort of works.  I tried this in the response handler:
+
+            {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+that gets used">>, Req1),
+            {<<"this body gets ignored">>, Req2, State};
+
+
+
+The client receives a 404 response, but cowboy crashes:
+
+=ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+Error in process <0.131.0> with exit value:
+{function_clause,[{cowboy_req,reply,[200,[],<<31
+bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+
+
+
+The issue is that the REST wrapper wants to do the cowboy_req:reply(), and
+when we do the call we cause the wrapper's call to fail.
+
+Dan.
+
+
+
+On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+
+> Sorry for terse but I only have a phone. Why can't you return a 404 here?
+>  Using something like cowboy:reply(404, ...
+>
+> Ivan
+>
+> --
+> festina lente
+>
+>
+> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+>
+> My situation is that I have a rest handler that may fail due to invalid
+> url segments.  Example situation:
+>
+>
+> init(_Transport, _Req, _Opts) ->
+>         {upgrade, protocol, cowboy_rest}.
+>
+> content_types_provided(Req, State) ->
+>     {[{<<"application/json">>, get_json}], Req, State}.
+>
+> get_json(Req0, State) ->
+>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+> [param1, param2, param3, ....]),
+>
+>     case catch other_module:request(Params) of
+>         {'EXIT', {badarg, _}} ->
+>             hmmm, Params were bad and I would like to return a 404 code
+> now.
+>         Result ->
+>             {jiffy:encode(Result), Req1, State}
+>     end.
+>
+>
+>
+> So I would like to return a 404 code when my underlying request function
+> fails, but it appears my choices are:
+>
+> - return a 200 (ok) response with data.
+> - crash and cause a 500 (Internal Server Error) response to be returned.
+> Not exactly the sentiment I want.
+>
+>
+> Is there some other way to cause a 404 response?
+>
+> I realize I could add path constraint functions, but I will be replicating
+> logic from my underlying request function.  Furthermore, the constraint
+> functions consider parameters in isolation, so that won't work if the
+> validity of parameters is coupled.
+>
+> Thanks,
+> Dan.
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/460453c8/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000290.html b/_build/static/archives/extend/2013-October/000290.html new file mode 100644 index 00000000..fef7ff9f --- /dev/null +++ b/_build/static/archives/extend/2013-October/000290.html @@ -0,0 +1,141 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Tilman Holschuh + tilman.holschuh at gmail.com +
+ Wed Oct 30 16:25:02 CET 2013 +

+
+ +
Why not let resource_exists/2 return false when your resource does not exist? You will get 404 on false. This way you separate the implementation for turning your data to json from checking if the request went to the correct resource. 
+
+- Tilman
+
+On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote:
+
+> Well, this sort of works.  I tried this in the response handler:
+> 
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+> 
+> 
+> 
+> The client receives a 404 response, but cowboy crashes:
+> 
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... 
+> 
+> 
+> 
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail.
+> 
+> Dan.
+> 
+> 
+> 
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+> Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+> 
+> Ivan
+> 
+> --
+> festina lente
+> 
+> 
+> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+> 
+>> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+>> 
+>> 
+>> init(_Transport, _Req, _Opts) ->
+>>         {upgrade, protocol, cowboy_rest}.
+>> 
+>> content_types_provided(Req, State) ->
+>>     {[{<<"application/json">>, get_json}], Req, State}.
+>> 
+>> get_json(Req0, State) ->
+>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+>> 
+>>     case catch other_module:request(Params) of
+>>         {'EXIT', {badarg, _}} ->
+>>             hmmm, Params were bad and I would like to return a 404 code now.
+>>         Result ->
+>>             {jiffy:encode(Result), Req1, State}
+>>     end.
+>> 
+>> 
+>> 
+>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+>> 
+>> - return a 200 (ok) response with data.
+>> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+>> 
+>> 
+>> Is there some other way to cause a 404 response?
+>> 
+>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+>> 
+>> Thanks,
+>> Dan.
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000291.html b/_build/static/archives/extend/2013-October/000291.html new file mode 100644 index 00000000..12b20628 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000291.html @@ -0,0 +1,144 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Ivan uemlianin + ivan at llaisdy.com +
+ Wed Oct 30 16:27:15 CET 2013 +

+
+ +
Instead of <<"this body ignored">> can you return the atom halt?
+
+#dontevenhaveanyofmycodewithme:(
+
+Ivan
+
+--
+festina lente
+
+
+On 30 Oct 2013, at 15:58, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+
+> Well, this sort of works.  I tried this in the response handler:
+> 
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+> 
+> 
+> 
+> The client receives a 404 response, but cowboy crashes:
+> 
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... 
+> 
+> 
+> 
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail.
+> 
+> Dan.
+> 
+> 
+> 
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+>> Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...
+>> 
+>> Ivan
+>> 
+>> --
+>> festina lente
+>> 
+>> 
+>> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com> wrote:
+>> 
+>>> My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:
+>>> 
+>>> 
+>>> init(_Transport, _Req, _Opts) ->
+>>>         {upgrade, protocol, cowboy_rest}.
+>>> 
+>>> content_types_provided(Req, State) ->
+>>>     {[{<<"application/json">>, get_json}], Req, State}.
+>>> 
+>>> get_json(Req0, State) ->
+>>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),
+>>> 
+>>>     case catch other_module:request(Params) of
+>>>         {'EXIT', {badarg, _}} ->
+>>>             hmmm, Params were bad and I would like to return a 404 code now.
+>>>         Result ->
+>>>             {jiffy:encode(Result), Req1, State}
+>>>     end.
+>>> 
+>>> 
+>>> 
+>>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:
+>>> 
+>>> - return a 200 (ok) response with data.
+>>> - crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.
+>>> 
+>>> 
+>>> Is there some other way to cause a 404 response?
+>>> 
+>>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.
+>>> 
+>>> Thanks,
+>>> Dan.
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> http://lists.ninenines.eu:81/listinfo/extend
+> 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/6e8ec2f0/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000292.html b/_build/static/archives/extend/2013-October/000292.html new file mode 100644 index 00000000..373e8147 --- /dev/null +++ b/_build/static/archives/extend/2013-October/000292.html @@ -0,0 +1,173 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Wed Oct 30 16:32:47 CET 2013 +

+
+ +
Returning 'halt' caused a status code of 204.
+
+Dan.
+
+
+On Wed, Oct 30, 2013 at 10:27 AM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+
+> Instead of <<"this body ignored">> can you return the atom halt?
+>
+> #dontevenhaveanyofmycodewithme:(
+>
+> Ivan
+>
+> --
+> festina lente
+>
+>
+> On 30 Oct 2013, at 15:58, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+>
+> Well, this sort of works.  I tried this in the response handler:
+>
+>             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+> that gets used">>, Req1),
+>             {<<"this body gets ignored">>, Req2, State};
+>
+>
+>
+> The client receives a 404 response, but cowboy crashes:
+>
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> Error in process <0.131.0> with exit value:
+> {function_clause,[{cowboy_req,reply,[200,[],<<31
+> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+>
+>
+>
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and
+> when we do the call we cause the wrapper's call to fail.
+>
+> Dan.
+>
+>
+>
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com> wrote:
+>
+>> Sorry for terse but I only have a phone. Why can't you return a 404 here?
+>>  Using something like cowboy:reply(404, ...
+>>
+>> Ivan
+>>
+>> --
+>> festina lente
+>>
+>>
+>> On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+>> wrote:
+>>
+>> My situation is that I have a rest handler that may fail due to invalid
+>> url segments.  Example situation:
+>>
+>>
+>> init(_Transport, _Req, _Opts) ->
+>>         {upgrade, protocol, cowboy_rest}.
+>>
+>> content_types_provided(Req, State) ->
+>>     {[{<<"application/json">>, get_json}], Req, State}.
+>>
+>> get_json(Req0, State) ->
+>>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+>> [param1, param2, param3, ....]),
+>>
+>>     case catch other_module:request(Params) of
+>>         {'EXIT', {badarg, _}} ->
+>>             hmmm, Params were bad and I would like to return a 404 code
+>> now.
+>>         Result ->
+>>             {jiffy:encode(Result), Req1, State}
+>>     end.
+>>
+>>
+>>
+>> So I would like to return a 404 code when my underlying request function
+>> fails, but it appears my choices are:
+>>
+>> - return a 200 (ok) response with data.
+>> - crash and cause a 500 (Internal Server Error) response to be returned.
+>> Not exactly the sentiment I want.
+>>
+>>
+>> Is there some other way to cause a 404 response?
+>>
+>> I realize I could add path constraint functions, but I will be
+>> replicating logic from my underlying request function.  Furthermore, the
+>> constraint functions consider parameters in isolation, so that won't work
+>> if the validity of parameters is coupled.
+>>
+>> Thanks,
+>> Dan.
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/0ab7c8ee/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/000293.html b/_build/static/archives/extend/2013-October/000293.html new file mode 100644 index 00000000..548908dd --- /dev/null +++ b/_build/static/archives/extend/2013-October/000293.html @@ -0,0 +1,175 @@ + + + + [99s-extend] REST handler failure + + + + + + + + + + +

[99s-extend] REST handler failure

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Wed Oct 30 16:46:37 CET 2013 +

+
+ +
That's what I was looking for, thanks!
+
+Dan.
+
+
+On Wed, Oct 30, 2013 at 10:25 AM, Tilman Holschuh <tilman.holschuh at gmail.com
+> wrote:
+
+> Why not let resource_exists/2 return false when your resource does not
+> exist? You will get 404 on false. This way you separate the implementation
+> for turning your data to json from checking if the request went to the
+> correct resource.
+>
+> - Tilman
+>
+> On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote:
+>
+> > Well, this sort of works.  I tried this in the response handler:
+> >
+> >             {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body
+> that gets used">>, Req1),
+> >             {<<"this body gets ignored">>, Req2, State};
+> >
+> >
+> >
+> > The client receives a 404 response, but cowboy crashes:
+> >
+> > =ERROR REPORT==== 8-Sep-2013::22:22:03 ===
+> > Error in process <0.131.0> with exit value:
+> {function_clause,[{cowboy_req,reply,[200,[],<<31
+> bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3
+> bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24
+> bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10
+> bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3
+> bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19
+> bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...
+> >
+> >
+> >
+> > The issue is that the REST wrapper wants to do the cowboy_req:reply(),
+> and when we do the call we cause the wrapper's call to fail.
+> >
+> > Dan.
+> >
+> >
+> >
+> > On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <ivan at llaisdy.com>
+> wrote:
+> > Sorry for terse but I only have a phone. Why can't you return a 404
+> here?  Using something like cowboy:reply(404, ...
+> >
+> > Ivan
+> >
+> > --
+> > festina lente
+> >
+> >
+> > On 29 Oct 2013, at 21:25, Daniel Goertzen <daniel.goertzen at gmail.com>
+> wrote:
+> >
+> >> My situation is that I have a rest handler that may fail due to invalid
+> url segments.  Example situation:
+> >>
+> >>
+> >> init(_Transport, _Req, _Opts) ->
+> >>         {upgrade, protocol, cowboy_rest}.
+> >>
+> >> content_types_provided(Req, State) ->
+> >>     {[{<<"application/json">>, get_json}], Req, State}.
+> >>
+> >> get_json(Req0, State) ->
+> >>     {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0,
+> [param1, param2, param3, ....]),
+> >>
+> >>     case catch other_module:request(Params) of
+> >>         {'EXIT', {badarg, _}} ->
+> >>             hmmm, Params were bad and I would like to return a 404 code
+> now.
+> >>         Result ->
+> >>             {jiffy:encode(Result), Req1, State}
+> >>     end.
+> >>
+> >>
+> >>
+> >> So I would like to return a 404 code when my underlying request
+> function fails, but it appears my choices are:
+> >>
+> >> - return a 200 (ok) response with data.
+> >> - crash and cause a 500 (Internal Server Error) response to be
+> returned.  Not exactly the sentiment I want.
+> >>
+> >>
+> >> Is there some other way to cause a 404 response?
+> >>
+> >> I realize I could add path constraint functions, but I will be
+> replicating logic from my underlying request function.  Furthermore, the
+> constraint functions consider parameters in isolation, so that won't work
+> if the validity of parameters is coupled.
+> >>
+> >> Thanks,
+> >> Dan.
+> >> _______________________________________________
+> >> Extend mailing list
+> >> Extend at lists.ninenines.eu
+> >> http://lists.ninenines.eu:81/listinfo/extend
+> >
+> > _______________________________________________
+> > Extend mailing list
+> > Extend at lists.ninenines.eu
+> > http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20131030/3ea4ac64/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-October/author.html b/_build/static/archives/extend/2013-October/author.html new file mode 100644 index 00000000..f2461560 --- /dev/null +++ b/_build/static/archives/extend/2013-October/author.html @@ -0,0 +1,242 @@ + + + + The Extend October 2013 Archive by author + + + + + +

October 2013 Archives by author

+ +

Starting: Thu Oct 3 07:00:28 CEST 2013
+ Ending: Wed Oct 30 16:46:37 CET 2013
+ Messages: 39

+

+

+ Last message date: + Wed Oct 30 16:46:37 CET 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-October/date.html b/_build/static/archives/extend/2013-October/date.html new file mode 100644 index 00000000..dc7c46ef --- /dev/null +++ b/_build/static/archives/extend/2013-October/date.html @@ -0,0 +1,242 @@ + + + + The Extend October 2013 Archive by date + + + + + +

October 2013 Archives by date

+ +

Starting: Thu Oct 3 07:00:28 CEST 2013
+ Ending: Wed Oct 30 16:46:37 CET 2013
+ Messages: 39

+

+

+ Last message date: + Wed Oct 30 16:46:37 CET 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-October/index.html b/_build/static/archives/extend/2013-October/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-October/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-October/subject.html b/_build/static/archives/extend/2013-October/subject.html new file mode 100644 index 00000000..5d57cab3 --- /dev/null +++ b/_build/static/archives/extend/2013-October/subject.html @@ -0,0 +1,242 @@ + + + + The Extend October 2013 Archive by subject + + + + + +

October 2013 Archives by subject

+ +

Starting: Thu Oct 3 07:00:28 CEST 2013
+ Ending: Wed Oct 30 16:46:37 CET 2013
+ Messages: 39

+

+

+ Last message date: + Wed Oct 30 16:46:37 CET 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-October/thread.html b/_build/static/archives/extend/2013-October/thread.html new file mode 100644 index 00000000..96277f8f --- /dev/null +++ b/_build/static/archives/extend/2013-October/thread.html @@ -0,0 +1,309 @@ + + + + The Extend October 2013 Archive by thread + + + + + +

October 2013 Archives by thread

+ +

Starting: Thu Oct 3 07:00:28 CEST 2013
+ Ending: Wed Oct 30 16:46:37 CET 2013
+ Messages: 39

+

+

+ Last message date: + Wed Oct 30 16:46:37 CET 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-September.txt b/_build/static/archives/extend/2013-September.txt new file mode 100644 index 00000000..a79d3857 --- /dev/null +++ b/_build/static/archives/extend/2013-September.txt @@ -0,0 +1,2240 @@ +From joe.freeman at bitroot.com Sun Sep 15 19:01:30 2013 +From: joe.freeman at bitroot.com (Joe Freeman) +Date: Sun, 15 Sep 2013 18:01:30 +0100 +Subject: [99s-extend] Cowboy load test +Message-ID: + +Hi, + +I've started work on a project using Clojure, but I was wondering whether +(and secretly hoping that) Erlang would be a better fit, so I've been load +testing a few web server frameworks. I'm particularly interested in how the +server can handle a large number of concurrent WebSocket connections, and +the test I've been running is similar to Eric Moritz's [1]. + +I've setup a simple Cowboy 'echo' server running on an EC2 instance +(m1.medium, as in Eric's test) which could comfortably handle 10k +concurrent WebSocket requests (as in Eric's results), while echoing about +200 messages/second. The CPU usage of the VM at this point is about 99%, +but the server continues to handle up to 40k concurrent connections with a +consistent average response time (<30ms). Pushing the test beyond this +number results in a spike in response times and lots of connection timeouts. + +40k connections seems pretty good, but when comparing this to the same test +against a couple of Clojure/JVM-based frameworks (specifically Aleph/Netty +and http-kit) I find I can get higher numbers of concurrent connections +with slightly better average response times (100k connections, <10ms +response time) using much less CPU (~20%). In fact, memory seems to be the +limiting factor. + +So I have two questions: + +1) Should I be concerned about the CPU usage in the Erlang/Cowboy test? I +have limited experience with Erlang so far, but 100% CPU feels like a bad +thing. + +2) Is there any way to increase the performance of the cowboy server? Are +there any Erlang VM parameters I can change? The fact that the Clojure/JVM +tests (on the same machine) have managed to get to 100k connections +suggests that the limitation isn't being imposed by the operating system +(I've applied changes various changes to sysctl and ulimit). + +(Perhaps an echo server isn't the best way to compare HTTP servers, but it +feels like a good starting point.) + +Thanks for any help. + +[1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md - the +GitHub repo actually contains code for an Aleph server, but results from +this aren't included in the summary here. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Sun Sep 15 21:02:35 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 15 Sep 2013 21:02:35 +0200 +Subject: [99s-extend] Cowboy load test +In-Reply-To: +References: +Message-ID: <5236044B.5040905@ninenines.eu> + +This sounds like you have too many timers, or something else is using +the CPU. 40k connections is literally nothing. Also make sure the +clients are on a separate VM/machine. + +Either way 99% CPU for 10k sounds high, I've had that with 0 CPU (though +on real hardware). + +Someone a couple years back got above 1 million after fixing 'too many +timers issues' but I don't think it was on a medium instance. + +On 09/15/2013 07:01 PM, Joe Freeman wrote: +> Hi, +> +> I've started work on a project using Clojure, but I was wondering +> whether (and secretly hoping that) Erlang would be a better fit, so I've +> been load testing a few web server frameworks. I'm particularly +> interested in how the server can handle a large number of concurrent +> WebSocket connections, and the test I've been running is similar to Eric +> Moritz's [1]. +> +> I've setup a simple Cowboy 'echo' server running on an EC2 instance +> (m1.medium, as in Eric's test) which could comfortably handle 10k +> concurrent WebSocket requests (as in Eric's results), while echoing +> about 200 messages/second. The CPU usage of the VM at this point is +> about 99%, but the server continues to handle up to 40k concurrent +> connections with a consistent average response time (<30ms). Pushing the +> test beyond this number results in a spike in response times and lots of +> connection timeouts. +> +> 40k connections seems pretty good, but when comparing this to the same +> test against a couple of Clojure/JVM-based frameworks (specifically +> Aleph/Netty and http-kit) I find I can get higher numbers of concurrent +> connections with slightly better average response times (100k +> connections, <10ms response time) using much less CPU (~20%). In fact, +> memory seems to be the limiting factor. +> +> So I have two questions: +> +> 1) Should I be concerned about the CPU usage in the Erlang/Cowboy test? +> I have limited experience with Erlang so far, but 100% CPU feels like a +> bad thing. +> +> 2) Is there any way to increase the performance of the cowboy server? +> Are there any Erlang VM parameters I can change? The fact that the +> Clojure/JVM tests (on the same machine) have managed to get to 100k +> connections suggests that the limitation isn't being imposed by the +> operating system (I've applied changes various changes to sysctl and +> ulimit). +> +> (Perhaps an echo server isn't the best way to compare HTTP servers, but +> it feels like a good starting point.) +> +> Thanks for any help. +> +> [1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md - +> the GitHub repo actually contains code for an Aleph server, but results +> from this aren't included in the summary here. +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Sun Sep 15 21:05:02 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Sun, 15 Sep 2013 21:05:02 +0200 +Subject: [99s-extend] Cowboy load test +In-Reply-To: <5236044B.5040905@ninenines.eu> +References: + <5236044B.5040905@ninenines.eu> +Message-ID: <523604DE.6050600@ninenines.eu> + +This just hit me after hitting send. + +Another possibility is that you are using text frames which are required +to be valid UTF-8. Cowboy checks that (as required by the RFC), and it's +fairly expensive, while most other servers don't. Try with binary frames +instead. + +On 09/15/2013 09:02 PM, Lo?c Hoguin wrote: +> This sounds like you have too many timers, or something else is using +> the CPU. 40k connections is literally nothing. Also make sure the +> clients are on a separate VM/machine. +> +> Either way 99% CPU for 10k sounds high, I've had that with 0 CPU (though +> on real hardware). +> +> Someone a couple years back got above 1 million after fixing 'too many +> timers issues' but I don't think it was on a medium instance. +> +> On 09/15/2013 07:01 PM, Joe Freeman wrote: +>> Hi, +>> +>> I've started work on a project using Clojure, but I was wondering +>> whether (and secretly hoping that) Erlang would be a better fit, so I've +>> been load testing a few web server frameworks. I'm particularly +>> interested in how the server can handle a large number of concurrent +>> WebSocket connections, and the test I've been running is similar to Eric +>> Moritz's [1]. +>> +>> I've setup a simple Cowboy 'echo' server running on an EC2 instance +>> (m1.medium, as in Eric's test) which could comfortably handle 10k +>> concurrent WebSocket requests (as in Eric's results), while echoing +>> about 200 messages/second. The CPU usage of the VM at this point is +>> about 99%, but the server continues to handle up to 40k concurrent +>> connections with a consistent average response time (<30ms). Pushing the +>> test beyond this number results in a spike in response times and lots of +>> connection timeouts. +>> +>> 40k connections seems pretty good, but when comparing this to the same +>> test against a couple of Clojure/JVM-based frameworks (specifically +>> Aleph/Netty and http-kit) I find I can get higher numbers of concurrent +>> connections with slightly better average response times (100k +>> connections, <10ms response time) using much less CPU (~20%). In fact, +>> memory seems to be the limiting factor. +>> +>> So I have two questions: +>> +>> 1) Should I be concerned about the CPU usage in the Erlang/Cowboy test? +>> I have limited experience with Erlang so far, but 100% CPU feels like a +>> bad thing. +>> +>> 2) Is there any way to increase the performance of the cowboy server? +>> Are there any Erlang VM parameters I can change? The fact that the +>> Clojure/JVM tests (on the same machine) have managed to get to 100k +>> connections suggests that the limitation isn't being imposed by the +>> operating system (I've applied changes various changes to sysctl and +>> ulimit). +>> +>> (Perhaps an echo server isn't the best way to compare HTTP servers, but +>> it feels like a good starting point.) +>> +>> Thanks for any help. +>> +>> [1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md - +>> the GitHub repo actually contains code for an Aleph server, but results +>> from this aren't included in the summary here. +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/listinfo/extend +>> +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Mon Sep 16 15:50:22 2013 +From: akonsu at gmail.com (akonsu) +Date: Mon, 16 Sep 2013 09:50:22 -0400 +Subject: [99s-extend] how to send a message to all connections in cowboy +Message-ID: + +Hello, + +this is somewhat similar to what someone else has asked: +http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html + +I am new to cowboy, I have a process that runs alongside a cowboy server +and this process needs to periodically send text to all http clients +connected to the cowboy server. My goal is to have a streaming connection +for each http client so that I could stream text to them from my process. +how is this done? + +Thanks! +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Sep 16 19:06:32 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Mon, 16 Sep 2013 19:06:32 +0200 +Subject: [99s-extend] how to send a message to all connections in cowboy +In-Reply-To: +References: +Message-ID: <52373A98.4080406@ninenines.eu> + +On 09/16/2013 03:50 PM, akonsu wrote: +> Hello, +> +> this is somewhat similar to what someone else has asked: +> http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html +> +> I am new to cowboy, I have a process that runs alongside a cowboy server +> and this process needs to periodically send text to all http clients +> connected to the cowboy server. My goal is to have a streaming +> connection for each http client so that I could stream text to them from +> my process. how is this done? + +Same answer really. You need some kind of process registry, like gproc +properties for example, that will store all Pids and allow you to send a +message to all of them. + +On init, register the process, and then handle the incoming message when +it arrives. + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Mon Sep 16 19:14:24 2013 +From: akonsu at gmail.com (akonsu) +Date: Mon, 16 Sep 2013 13:14:24 -0400 +Subject: [99s-extend] how to send a message to all connections in cowboy +In-Reply-To: <52373A98.4080406@ninenines.eu> +References: + <52373A98.4080406@ninenines.eu> +Message-ID: + +thanks. Suppose my external process is registered and has a name, so I can +discover it by name from my cowboy request handler. when my cowboy handler +is invoked, can I just send the handler's process ID to the external +process? the question is then how does the external process know that the +http client has disconnected so that it can stop sending data to it. + + +2013/9/16 Lo?c Hoguin + +> On 09/16/2013 03:50 PM, akonsu wrote: +> +>> Hello, +>> +>> this is somewhat similar to what someone else has asked: +>> http://lists.ninenines.eu:81/**archives/extend/2013-August/**000224.html +>> +>> I am new to cowboy, I have a process that runs alongside a cowboy server +>> and this process needs to periodically send text to all http clients +>> connected to the cowboy server. My goal is to have a streaming +>> connection for each http client so that I could stream text to them from +>> my process. how is this done? +>> +> +> Same answer really. You need some kind of process registry, like gproc +> properties for example, that will store all Pids and allow you to send a +> message to all of them. +> +> On init, register the process, and then handle the incoming message when +> it arrives. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Sep 16 19:19:59 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 16 Sep 2013 19:19:59 +0200 +Subject: [99s-extend] how to send a message to all connections in cowboy +In-Reply-To: +References: + <52373A98.4080406@ninenines.eu> + +Message-ID: <52373DBF.3080503@ninenines.eu> + +Monitors. + +But really gproc does all that for you and is already well tested. + +https://github.com/esl/gproc + +On 09/16/2013 07:14 PM, akonsu wrote: +> thanks. Suppose my external process is registered and has a name, so I +> can discover it by name from my cowboy request handler. when my cowboy +> handler is invoked, can I just send the handler's process ID to the +> external process? the question is then how does the external process +> know that the http client has disconnected so that it can stop sending +> data to it. +> +> +> 2013/9/16 Lo?c Hoguin > +> +> On 09/16/2013 03:50 PM, akonsu wrote: +> +> Hello, +> +> this is somewhat similar to what someone else has asked: +> http://lists.ninenines.eu:81/__archives/extend/2013-August/__000224.html +> +> +> I am new to cowboy, I have a process that runs alongside a +> cowboy server +> and this process needs to periodically send text to all http clients +> connected to the cowboy server. My goal is to have a streaming +> connection for each http client so that I could stream text to +> them from +> my process. how is this done? +> +> +> Same answer really. You need some kind of process registry, like +> gproc properties for example, that will store all Pids and allow you +> to send a message to all of them. +> +> On init, register the process, and then handle the incoming message +> when it arrives. +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Thu Sep 19 06:30:57 2013 +From: akonsu at gmail.com (akonsu) +Date: Thu, 19 Sep 2013 00:30:57 -0400 +Subject: [99s-extend] cowboy_loop_handler +Message-ID: + +Hello, + +from the documentation: + +info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State} | {loop, +Req, State, hibernate} + + +in case my handler receives a lot of messages, and they come very often, +does a response of the latter form {loop, Req, State, hibernate} save +anything? Can hibernating in this case actually hinder performance? + +thanks +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Sep 19 11:03:02 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Thu, 19 Sep 2013 11:03:02 +0200 +Subject: [99s-extend] cowboy_loop_handler +In-Reply-To: +References: +Message-ID: <523ABDC6.1050204@ninenines.eu> + +How much is a lot of messages? + +Hibernating is a bit more expensive on the CPU but better for saving +memory. It's generally fine to use except when you have a really busy +system. Do note that it also means your responses will be slightly +slower (though that is generally not noticeable). + +On 09/19/2013 06:30 AM, akonsu wrote: +> Hello, +> +> from the documentation: +> +> info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}| {loop, +> Req, State, hibernate} +> +> +> in case my handler receives a lot of messages, and they come very often, +> does a response of the latter form {loop, Req, State, hibernate} save +> anything? Can hibernating in this case actually hinder performance? +> +> thanks +> Konstantin +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Thu Sep 19 13:37:58 2013 +From: akonsu at gmail.com (akonsu) +Date: Thu, 19 Sep 2013 07:37:58 -0400 +Subject: [99s-extend] cowboy_loop_handler +In-Reply-To: <523ABDC6.1050204@ninenines.eu> +References: + <523ABDC6.1050204@ninenines.eu> +Message-ID: + +my http handler receives messages carrying json parts obtained from a +twitter stream by a separate process. the twitter stream is the stream of +all public tweets, (they call it "firehose") so there are a lot. + + +2013/9/19 Lo?c Hoguin + +> How much is a lot of messages? +> +> Hibernating is a bit more expensive on the CPU but better for saving +> memory. It's generally fine to use except when you have a really busy +> system. Do note that it also means your responses will be slightly slower +> (though that is generally not noticeable). +> +> +> On 09/19/2013 06:30 AM, akonsu wrote: +> +>> Hello, +>> +>> from the documentation: +>> +>> info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}| {loop, +>> Req, State, hibernate} +>> +>> +>> in case my handler receives a lot of messages, and they come very often, +>> does a response of the latter form {loop, Req, State, hibernate} save +>> anything? Can hibernating in this case actually hinder performance? +>> +>> thanks +>> Konstantin +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From akonsu at gmail.com Fri Sep 20 20:47:54 2013 +From: akonsu at gmail.com (akonsu) +Date: Fri, 20 Sep 2013 14:47:54 -0400 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +Message-ID: + +Hi, + +I am using loop handler and I stream from it: + +info({stream, Part}, Req, S) -> + ok = cowboy_req:chunk(Part, Req), + {loop, Req, S, hibernate}; + +I have two questions: + +1. on timeouts cowboy sends 204 No Content. In my case it is not the right +response because I may have already sent some data. Is there a way to send +a custom response? + +2. how to check if the client is too slow and is not reading the response +stream fast enough? If this happens, then I need to disconnect. + +I can live without 1. but I need to figure out 2. Please help. + +thank you! +Konstantin +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Sep 20 20:50:57 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 20 Sep 2013 20:50:57 +0200 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +In-Reply-To: +References: +Message-ID: <523C9911.8070908@ninenines.eu> + +Loop handlers close after a while regardless of what you send, it only +checks what the client sends. The best way for you would be to disable +that timeout and handle it manually. + +As for the second question, I'm still reading the thread on +erlang-questions but I've seen some good ideas about timestamps so far. + +On 09/20/2013 08:47 PM, akonsu wrote: +> Hi, +> +> I am using loop handler and I stream from it: +> +> info({stream, Part}, Req, S) -> +> ok = cowboy_req:chunk(Part, Req), +> {loop, Req, S, hibernate}; +> +> I have two questions: +> +> 1. on timeouts cowboy sends 204 No Content. In my case it is not the +> right response because I may have already sent some data. Is there a way +> to send a custom response? +> +> 2. how to check if the client is too slow and is not reading the +> response stream fast enough? If this happens, then I need to disconnect. +> +> I can live without 1. but I need to figure out 2. Please help. +> +> thank you! +> Konstantin +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Fri Sep 20 20:54:56 2013 +From: akonsu at gmail.com (akonsu) +Date: Fri, 20 Sep 2013 14:54:56 -0400 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +In-Reply-To: <523C9911.8070908@ninenines.eu> +References: + <523C9911.8070908@ninenines.eu> +Message-ID: + +thanks! + +how to implement timeout callback manually? if I had receive then I would +just use timeout clause there, but with the handler I do not know... + +I have doubts about validity of my question on the erlang list. I later +realised that there is no problem receiving messages in my handler from my +upstream process, I can do it fast enough and shove everything to the +response. my real problem is to determine if the http client is reading +fast enough from the response... + + +2013/9/20 Lo?c Hoguin + +> Loop handlers close after a while regardless of what you send, it only +> checks what the client sends. The best way for you would be to disable that +> timeout and handle it manually. +> +> As for the second question, I'm still reading the thread on +> erlang-questions but I've seen some good ideas about timestamps so far. +> +> +> On 09/20/2013 08:47 PM, akonsu wrote: +> +>> Hi, +>> +>> I am using loop handler and I stream from it: +>> +>> info({stream, Part}, Req, S) -> +>> ok = cowboy_req:chunk(Part, Req), +>> {loop, Req, S, hibernate}; +>> +>> I have two questions: +>> +>> 1. on timeouts cowboy sends 204 No Content. In my case it is not the +>> right response because I may have already sent some data. Is there a way +>> to send a custom response? +>> +>> 2. how to check if the client is too slow and is not reading the +>> response stream fast enough? If this happens, then I need to disconnect. +>> +>> I can live without 1. but I need to figure out 2. Please help. +>> +>> thank you! +>> Konstantin +>> +>> +>> +>> ______________________________**_________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> http://lists.ninenines.eu:81/**listinfo/extend +>> +>> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Sep 20 20:56:31 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 20 Sep 2013 20:56:31 +0200 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +In-Reply-To: +References: + <523C9911.8070908@ninenines.eu> + +Message-ID: <523C9A5F.3080805@ninenines.eu> + +chunk only returns when the client has received the chunk, so the +timestamps solution should work. + +As for the timeout, you can simply use erlang:send_after or something +like usual and the message will arrive in info/3. + +On 09/20/2013 08:54 PM, akonsu wrote: +> thanks! +> +> how to implement timeout callback manually? if I had receive then I +> would just use timeout clause there, but with the handler I do not know... +> +> I have doubts about validity of my question on the erlang list. I later +> realised that there is no problem receiving messages in my handler from +> my upstream process, I can do it fast enough and shove everything to the +> response. my real problem is to determine if the http client is reading +> fast enough from the response... +> +> +> 2013/9/20 Lo?c Hoguin > +> +> Loop handlers close after a while regardless of what you send, it +> only checks what the client sends. The best way for you would be to +> disable that timeout and handle it manually. +> +> As for the second question, I'm still reading the thread on +> erlang-questions but I've seen some good ideas about timestamps so far. +> +> +> On 09/20/2013 08:47 PM, akonsu wrote: +> +> Hi, +> +> I am using loop handler and I stream from it: +> +> info({stream, Part}, Req, S) -> +> ok = cowboy_req:chunk(Part, Req), +> {loop, Req, S, hibernate}; +> +> I have two questions: +> +> 1. on timeouts cowboy sends 204 No Content. In my case it is not the +> right response because I may have already sent some data. Is +> there a way +> to send a custom response? +> +> 2. how to check if the client is too slow and is not reading the +> response stream fast enough? If this happens, then I need to +> disconnect. +> +> I can live without 1. but I need to figure out 2. Please help. +> +> thank you! +> Konstantin +> +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/__listinfo/extend +> +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From akonsu at gmail.com Fri Sep 20 20:59:46 2013 +From: akonsu at gmail.com (akonsu) +Date: Fri, 20 Sep 2013 14:59:46 -0400 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +In-Reply-To: <523C9A5F.3080805@ninenines.eu> +References: + <523C9911.8070908@ninenines.eu> + + <523C9A5F.3080805@ninenines.eu> +Message-ID: + +Understand about chunks being synchronous. that helps me tremendously to +understand how it works. + +would you give me a sketchy example of how to use send_after in a loop +handler? (sorry I am new to erlang) + +Konstantin + + +2013/9/20 Lo?c Hoguin + +> chunk only returns when the client has received the chunk, so the +> timestamps solution should work. +> +> As for the timeout, you can simply use erlang:send_after or something like +> usual and the message will arrive in info/3. +> +> +> On 09/20/2013 08:54 PM, akonsu wrote: +> +>> thanks! +>> +>> how to implement timeout callback manually? if I had receive then I +>> would just use timeout clause there, but with the handler I do not know... +>> +>> I have doubts about validity of my question on the erlang list. I later +>> realised that there is no problem receiving messages in my handler from +>> my upstream process, I can do it fast enough and shove everything to the +>> response. my real problem is to determine if the http client is reading +>> fast enough from the response... +>> +>> +>> 2013/9/20 Lo?c Hoguin > +>> +>> +>> Loop handlers close after a while regardless of what you send, it +>> only checks what the client sends. The best way for you would be to +>> disable that timeout and handle it manually. +>> +>> As for the second question, I'm still reading the thread on +>> erlang-questions but I've seen some good ideas about timestamps so +>> far. +>> +>> +>> On 09/20/2013 08:47 PM, akonsu wrote: +>> +>> Hi, +>> +>> I am using loop handler and I stream from it: +>> +>> info({stream, Part}, Req, S) -> +>> ok = cowboy_req:chunk(Part, Req), +>> {loop, Req, S, hibernate}; +>> +>> I have two questions: +>> +>> 1. on timeouts cowboy sends 204 No Content. In my case it is not +>> the +>> right response because I may have already sent some data. Is +>> there a way +>> to send a custom response? +>> +>> 2. how to check if the client is too slow and is not reading the +>> response stream fast enough? If this happens, then I need to +>> disconnect. +>> +>> I can live without 1. but I need to figure out 2. Please help. +>> +>> thank you! +>> Konstantin +>> +>> +>> +>> ______________________________**___________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> > +>> http://lists.ninenines.eu:81/_**_listinfo/extend +>> +>> +>> > +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> Erlang Cowboy +>> Nine Nines +>> http://ninenines.eu +>> +>> +>> +> +> -- +> Lo?c Hoguin +> +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Sep 20 21:04:34 2013 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 20 Sep 2013 21:04:34 +0200 +Subject: [99s-extend] timeouts and slow clients in cowboy loop handler +In-Reply-To: +References: + <523C9911.8070908@ninenines.eu> + + <523C9A5F.3080805@ninenines.eu> + +Message-ID: <523C9C42.4040300@ninenines.eu> + +send_after sends an Erlang message to a Pid after N milliseconds. It's +the same as Pid ! Message, except it's sent later. Send it to self(). + +But if you're going to use timestamps then you probably don't need this +timeout, just check the timestamps and close when too slow. + +On 09/20/2013 08:59 PM, akonsu wrote: +> Understand about chunks being synchronous. that helps me tremendously to +> understand how it works. +> +> would you give me a sketchy example of how to use send_after in a loop +> handler? (sorry I am new to erlang) +> +> Konstantin +> +> +> 2013/9/20 Lo?c Hoguin > +> +> chunk only returns when the client has received the chunk, so the +> timestamps solution should work. +> +> As for the timeout, you can simply use erlang:send_after or +> something like usual and the message will arrive in info/3. +> +> +> On 09/20/2013 08:54 PM, akonsu wrote: +> +> thanks! +> +> how to implement timeout callback manually? if I had receive then I +> would just use timeout clause there, but with the handler I do +> not know... +> +> I have doubts about validity of my question on the erlang list. +> I later +> realised that there is no problem receiving messages in my +> handler from +> my upstream process, I can do it fast enough and shove +> everything to the +> response. my real problem is to determine if the http client is +> reading +> fast enough from the response... +> +> +> 2013/9/20 Lo?c Hoguin >> +> +> +> Loop handlers close after a while regardless of what you +> send, it +> only checks what the client sends. The best way for you +> would be to +> disable that timeout and handle it manually. +> +> As for the second question, I'm still reading the thread on +> erlang-questions but I've seen some good ideas about +> timestamps so far. +> +> +> On 09/20/2013 08:47 PM, akonsu wrote: +> +> Hi, +> +> I am using loop handler and I stream from it: +> +> info({stream, Part}, Req, S) -> +> ok = cowboy_req:chunk(Part, Req), +> {loop, Req, S, hibernate}; +> +> I have two questions: +> +> 1. on timeouts cowboy sends 204 No Content. In my case +> it is not the +> right response because I may have already sent some +> data. Is +> there a way +> to send a custom response? +> +> 2. how to check if the client is too slow and is not +> reading the +> response stream fast enough? If this happens, then I +> need to +> disconnect. +> +> I can live without 1. but I need to figure out 2. +> Please help. +> +> thank you! +> Konstantin +> +> +> +> ___________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> > +> http://lists.ninenines.eu:81/____listinfo/extend +> +> +> > +> +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> +> +> +> -- +> Lo?c Hoguin +> +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From mrhegarty at gmail.com Sun Sep 22 22:55:31 2013 +From: mrhegarty at gmail.com (Matthew Hegarty) +Date: Sun, 22 Sep 2013 21:55:31 +0100 +Subject: [99s-extend] Cowboy helloworld make fails with missing_beam_file + (hipe) +Message-ID: + +hi +Just starting out so I've got latest versions of apps. +in cowboy/examples/hello_world, running make fails with: +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mrhegarty at gmail.com Sun Sep 22 22:59:37 2013 +From: mrhegarty at gmail.com (Matthew Hegarty) +Date: Sun, 22 Sep 2013 21:59:37 +0100 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: +References: +Message-ID: + +hi +Just starting out so I'm trying to run cowboy's helloworld +in cowboy/examples/hello_world, running make fails with: + +===> Provider (rlx_prv_discover) failed with: {error, + {rlx_app_discovery, + [{missing_beam_file, + hipe, + +<<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, + {missing_beam_file, + hipe, + +<<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} + +there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it is +in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +I've tried passing the correct dir to relx using --lib-dir but I still get +the same error. + +Any ideas what's going wrong? + +erl: Erlang R16B02 (erts-5.10.3) +relx: 0.0.0+build.275.refca03701 +rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc + + +On 22 September 2013 21:55, Matthew Hegarty wrote: + +> hi +> Just starting out so I've got latest versions of apps. +> in cowboy/examples/hello_world, running make fails with: +> +> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lloyd at writersglen.com Mon Sep 23 01:57:41 2013 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Sun, 22 Sep 2013 19:57:41 -0400 (EDT) +Subject: [99s-extend] Cowboy: Having problems with Getting Started +Message-ID: <1379894261.367227790@apps.rackspace.com> + +Hello, + +Forgive my ignorance, but I'm having problems with the Getting Started chapter of the Cowboy Guide. + +Near the end I can download relx just fine. But there seems to be a hidden assumption shared, perhaps, by all Erlang cowboys but outside my understanding. + +When I get to $./relx, the following is returned: + +lloyd at Reliance:~/hello_erlang/relx$ ./relx +===> Starting relx build process ... +===> Resolving OTP Applications from directories: + /home/lloyd/hello_erlang/relx/ebin + /home/lloyd/hello_erlang/relx/deps + /usr/lib/erlang/lib + +===> Resolving available OTP Releases from directories: + /home/lloyd/hello_erlang/relx/ebin + /home/lloyd/hello_erlang/relx/deps + /usr/lib/erlang/lib + +Failed to solve release: + Dependency hello_erlang is specified as a dependency but is not reachable by the system. + +I've added all variations to .erlang that I can think of to put hello_erlang into the code path, but none seem to work. Can some kind soul let me in on the secret? + +Many thanks, + +Lloyd + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From essen at ninenines.eu Wed Sep 25 17:09:16 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 25 Sep 2013 17:09:16 +0200 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: +References: + +Message-ID: <5242FC9C.2090501@ninenines.eu> + +Why does it look for hipe at all to begin with? + +I'll ping tristan about it. + +On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> hi +> Just starting out so I'm trying to run cowboy's helloworld +> in cowboy/examples/hello_world, running make fails with: +> +> ===> Provider (rlx_prv_discover) failed with: {error, +> {rlx_app_discovery, +> [{missing_beam_file, +> hipe, +> +> <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> {missing_beam_file, +> hipe, +> +> <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> +> there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it +> is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> I've tried passing the correct dir to relx using --lib-dir but I still +> get the same error. +> +> Any ideas what's going wrong? +> +> erl: Erlang R16B02 (erts-5.10.3) +> relx: 0.0.0+build.275.refca03701 +> rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc +> +> +> On 22 September 2013 21:55, Matthew Hegarty > wrote: +> +> hi +> Just starting out so I've got latest versions of apps. +> in cowboy/examples/hello_world, running make fails with: +> +> +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From essen at ninenines.eu Wed Sep 25 17:10:01 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 25 Sep 2013 17:10:01 +0200 +Subject: [99s-extend] Cowboy: Having problems with Getting Started +In-Reply-To: <1379894261.367227790@apps.rackspace.com> +References: <1379894261.367227790@apps.rackspace.com> +Message-ID: <5242FCC9.5090003@ninenines.eu> + +On 09/23/2013 01:57 AM, lloyd at writersglen.com wrote: +> Hello, +> +> Forgive my ignorance, but I'm having problems with the Getting Started chapter of the Cowboy Guide. +> +> Near the end I can download relx just fine. But there seems to be a hidden assumption shared, perhaps, by all Erlang cowboys but outside my understanding. +> +> When I get to $./relx, the following is returned: +> +> lloyd at Reliance:~/hello_erlang/relx$ ./relx + +You're in hello_erlang/relx, I'm guessing you want to do that in +hello_erlang/ directly. + +> ===> Starting relx build process ... +> ===> Resolving OTP Applications from directories: +> /home/lloyd/hello_erlang/relx/ebin +> /home/lloyd/hello_erlang/relx/deps +> /usr/lib/erlang/lib +> +> ===> Resolving available OTP Releases from directories: +> /home/lloyd/hello_erlang/relx/ebin +> /home/lloyd/hello_erlang/relx/deps +> /usr/lib/erlang/lib +> +> Failed to solve release: +> Dependency hello_erlang is specified as a dependency but is not reachable by the system. +> +> I've added all variations to .erlang that I can think of to put hello_erlang into the code path, but none seem to work. Can some kind soul let me in on the secret? +> +> Many thanks, +> +> Lloyd +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend +> + + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From tristan.sloughter at gmail.com Wed Sep 25 18:25:04 2013 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Wed, 25 Sep 2013 09:25:04 -0700 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: <5242FC9C.2090501@ninenines.eu> +References: + + <5242FC9C.2090501@ninenines.eu> +Message-ID: <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> + +I ran into the same thing. I assume you installed Erlang from the Erlang +Solutions repo? + +Install erlang-hipe package. Or remove +/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. + +Their packages install a broken hipe app, missing lots of beams, for +some reason. But if you install the hipe package it'll install what is +missing. I told them about this but I haven't heard back. + +-- + Tristan Sloughter + tsloughter at fastmail.fm + +On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +> Why does it look for hipe at all to begin with? +> +> I'll ping tristan about it. +> +> On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> > hi +> > Just starting out so I'm trying to run cowboy's helloworld +> > in cowboy/examples/hello_world, running make fails with: +> > +> > ===> Provider (rlx_prv_discover) failed with: {error, +> > {rlx_app_discovery, +> > [{missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> > {missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> > +> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it +> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> > I've tried passing the correct dir to relx using --lib-dir but I still +> > get the same error. +> > +> > Any ideas what's going wrong? +> > +> > erl: Erlang R16B02 (erts-5.10.3) +> > relx: 0.0.0+build.275.refca03701 +> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc +> > +> > +> > On 22 September 2013 21:55, Matthew Hegarty > > wrote: +> > +> > hi +> > Just starting out so I've got latest versions of apps. +> > in cowboy/examples/hello_world, running make fails with: +> > +> > +> > +> > +> > +> > +> > _______________________________________________ +> > Extend mailing list +> > Extend at lists.ninenines.eu +> > http://lists.ninenines.eu:81/listinfo/extend +> > +> +> +> -- +> Lo?c Hoguin +> Erlang Cowboy +> Nine Nines +> http://ninenines.eu +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> http://lists.ninenines.eu:81/listinfo/extend + + +-- + Tristan Sloughter + tristan.sloughter at gmail.com + + +From essen at ninenines.eu Wed Sep 25 18:27:58 2013 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Wed, 25 Sep 2013 18:27:58 +0200 +Subject: [99s-extend] Mailing lists maintenance 28th of September +Message-ID: <52430F0E.5090306@ninenines.eu> + +Hello, + +Just a heads up, I will be moving the mailing lists to a new server +Saturday. As a result they might be unavailable for a couple hours/days +depending on how well I manage to do it. + +Thanks for your understanding! + +-- +Lo?c Hoguin +Erlang Cowboy +Nine Nines +http://ninenines.eu + + +From mrhegarty at gmail.com Thu Sep 26 21:03:06 2013 +From: mrhegarty at gmail.com (Matthew Hegarty) +Date: Thu, 26 Sep 2013 20:03:06 +0100 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> +References: + + <5242FC9C.2090501@ninenines.eu> + <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> +Message-ID: + +hi +I compiled Erlang from source (downloaded from erlang.org) + + +On 25 September 2013 17:25, Tristan Sloughter +wrote: + +> I ran into the same thing. I assume you installed Erlang from the Erlang +> Solutions repo? +> +> Install erlang-hipe package. Or remove +> /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. +> +> Their packages install a broken hipe app, missing lots of beams, for +> some reason. But if you install the hipe package it'll install what is +> missing. I told them about this but I haven't heard back. +> +> -- +> Tristan Sloughter +> tsloughter at fastmail.fm +> +> On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +> > Why does it look for hipe at all to begin with? +> > +> > I'll ping tristan about it. +> > +> > On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> > > hi +> > > Just starting out so I'm trying to run cowboy's helloworld +> > > in cowboy/examples/hello_world, running make fails with: +> > > +> > > ===> Provider (rlx_prv_discover) failed with: {error, +> > > +> {rlx_app_discovery, +> > > +> [{missing_beam_file, +> > > hipe, +> > > +> > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> > > +> {missing_beam_file, +> > > hipe, +> > > +> > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> > > +> > > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, +> it +> > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> > > I've tried passing the correct dir to relx using --lib-dir but I still +> > > get the same error. +> > > +> > > Any ideas what's going wrong? +> > > +> > > erl: Erlang R16B02 (erts-5.10.3) +> > > relx: 0.0.0+build.275.refca03701 +> > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc +> > > +> > > +> > > On 22 September 2013 21:55, Matthew Hegarty > > > wrote: +> > > +> > > hi +> > > Just starting out so I've got latest versions of apps. +> > > in cowboy/examples/hello_world, running make fails with: +> > > +> > > +> > > +> > > +> > > +> > > +> > > _______________________________________________ +> > > Extend mailing list +> > > Extend at lists.ninenines.eu +> > > http://lists.ninenines.eu:81/listinfo/extend +> > > +> > +> > +> > -- +> > Lo?c Hoguin +> > Erlang Cowboy +> > Nine Nines +> > http://ninenines.eu +> > _______________________________________________ +> > Extend mailing list +> > Extend at lists.ninenines.eu +> > http://lists.ninenines.eu:81/listinfo/extend +> +> +> -- +> Tristan Sloughter +> tristan.sloughter at gmail.com +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From tristan.sloughter at gmail.com Thu Sep 26 21:04:00 2013 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Thu, 26 Sep 2013 12:04:00 -0700 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: +References: + + <5242FC9C.2090501@ninenines.eu> + <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> + +Message-ID: <1380222240.30914.26875993.6CA5F061@webmail.messagingengine.com> + +Did you enable hipe when you compiled? Does +/usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist? + + + +-- +Tristan Sloughter +tristan.sloughter at gmail.com + + + + + +On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote: + +hi + +I compiled Erlang from source (downloaded from [1]erlang.org) + + + +On 25 September 2013 17:25, Tristan Sloughter +<[2]tristan.sloughter at gmail.com> wrote: + +I ran into the same thing. I assume you installed Erlang from the +Erlang + +Solutions repo? + + + +Install erlang-hipe package. Or remove + +/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. + + + +Their packages install a broken hipe app, missing lots of beams, for + +some reason. But if you install the hipe package it'll install what is + +missing. I told them about this but I haven't heard back. + + + +-- + + Tristan Sloughter + + [3]tsloughter at fastmail.fm + + + + +On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +> Why does it look for hipe at all to begin with? +> +> I'll ping tristan about it. +> +> On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> > hi +> > Just starting out so I'm trying to run cowboy's helloworld +> > in cowboy/examples/hello_world, running make fails with: +> > +> > ===> Provider (rlx_prv_discover) failed with: {error, +> > +{rlx_app_discovery, +> > +[{missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> > +{missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> > +> > there is no hipe.beam in +/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it +> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> > I've tried passing the correct dir to relx using --lib-dir but I +still +> > get the same error. +> > +> > Any ideas what's going wrong? +> > +> > erl: Erlang R16B02 (erts-5.10.3) +> > relx: 0.0.0+build.275.refca03701 +> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git +2.1.0-pre-46-g78fa8fc +> > +> > +> > On 22 September 2013 21:55, Matthew Hegarty <[4]mrhegarty at gmail.com +> > > wrote: +> > +> > hi +> > Just starting out so I've got latest versions of apps. +> > in cowboy/examples/hello_world, running make fails with: +> > +> > +> > +> > +> > +> > +> > _______________________________________________ +> > Extend mailing list +> > [6]Extend at lists.ninenines.eu +> > [7]http://lists.ninenines.eu:81/listinfo/extend +> > +> +> +> -- + +> Lo?c Hoguin + + + +> Erlang Cowboy + +> Nine Nines + +> [8]http://ninenines.eu + +> _______________________________________________ +> Extend mailing list +> [9]Extend at lists.ninenines.eu +> [10]http://lists.ninenines.eu:81/listinfo/extend + + +-- + + Tristan Sloughter + + [11]tristan.sloughter at gmail.com + +References + +1. http://erlang.org/ +2. mailto:tristan.sloughter at gmail.com +3. mailto:tsloughter at fastmail.fm +4. mailto:mrhegarty at gmail.com +5. mailto:mrhegarty at gmail.com +6. mailto:Extend at lists.ninenines.eu +7. http://lists.ninenines.eu:81/listinfo/extend +8. http://ninenines.eu/ +9. mailto:Extend at lists.ninenines.eu + 10. http://lists.ninenines.eu:81/listinfo/extend + 11. mailto:tristan.sloughter at gmail.com +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mrhegarty at gmail.com Thu Sep 26 22:36:03 2013 +From: mrhegarty at gmail.com (Matthew Hegarty) +Date: Thu, 26 Sep 2013 21:36:03 +0100 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: <1380222240.30914.26875993.6CA5F061@webmail.messagingengine.com> +References: + + <5242FC9C.2090501@ninenines.eu> + <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> + + <1380222240.30914.26875993.6CA5F061@webmail.messagingengine.com> +Message-ID: + +yes it exists. I believe hipe is enabled by default when I compile. + +however there is no + + /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam + /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam + +which is what relx is apparently looking for. +Do you know where does relx get these paths from? + + +On 26 September 2013 20:04, Tristan Sloughter +wrote: + +> ** +> Did you enable hipe when you compiled? Does +> /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist? +> +> -- +> Tristan Sloughter +> tristan.sloughter at gmail.com +> +> +> +> On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote: +> +> hi +> I compiled Erlang from source (downloaded from erlang.org) +> +> +> On 25 September 2013 17:25, Tristan Sloughter > wrote: +> +> +> I ran into the same thing. I assume you installed Erlang from the Erlang +> Solutions repo? +> +> Install erlang-hipe package. Or remove +> /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. +> +> Their packages install a broken hipe app, missing lots of beams, for +> some reason. But if you install the hipe package it'll install what is +> missing. I told them about this but I haven't heard back. +> +> -- +> Tristan Sloughter +> tsloughter at fastmail.fm +> +> +> On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +> > Why does it look for hipe at all to begin with? +> > +> > I'll ping tristan about it. +> > +> > On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> > > hi +> > > Just starting out so I'm trying to run cowboy's helloworld +> > > in cowboy/examples/hello_world, running make fails with: +> > > +> > > ===> Provider (rlx_prv_discover) failed with: {error, +> > > +> {rlx_app_discovery, +> > > +> [{missing_beam_file, +> > > hipe, +> > > +> > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> > > +> {missing_beam_file, +> > > hipe, +> > > +> > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> > > +> > > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, +> it +> > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> > > I've tried passing the correct dir to relx using --lib-dir but I still +> > > get the same error. +> > > +> > > Any ideas what's going wrong? +> > > +> > > erl: Erlang R16B02 (erts-5.10.3) +> > > relx: 0.0.0+build.275.refca03701 +> > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git +> 2.1.0-pre-46-g78fa8fc +> > > +> > > +> > > On 22 September 2013 21:55, Matthew Hegarty > > > wrote: +> > > +> > > hi +> > > Just starting out so I've got latest versions of apps. +> > > in cowboy/examples/hello_world, running make fails with: +> > > +> > > +> > > +> > > +> > > +> > > +> > > _______________________________________________ +> > > Extend mailing list +> > > Extend at lists.ninenines.eu +> > > http://lists.ninenines.eu:81/listinfo/extend +> > > +> > +> > +> > -- +> > Lo?c Hoguin +> +> > Erlang Cowboy +> > Nine Nines +> > http://ninenines.eu +> > _______________________________________________ +> > Extend mailing list +> > Extend at lists.ninenines.eu +> > http://lists.ninenines.eu:81/listinfo/extend +> +> +> -- +> Tristan Sloughter +> tristan.sloughter at gmail.com +> +> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mrhegarty at gmail.com Sat Sep 28 22:41:16 2013 +From: mrhegarty at gmail.com (Matthew Hegarty) +Date: Sat, 28 Sep 2013 21:41:16 +0100 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: +References: + + <5242FC9C.2090501@ninenines.eu> + <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> + + <1380222240.30914.26875993.6CA5F061@webmail.messagingengine.com> + +Message-ID: + +Got it to work. I apparently had a few versions of hipe in my Erlang lib +dir: + +$ /usr/local/lib/erlang/lib $ ll -ld hipe* +drwxr-xr-x 9 root root 4096 Feb 11 2013 hipe-3.10/ +drwxr-xr-x 9 root root 4096 Mar 1 2013 hipe-3.10.1/ +drwxr-xr-x 10 root root 4096 Jul 2 11:31 hipe-3.10.2/ +drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/ + +They must have come from previous erlang installations (compilation from +source). The solution was to remove the older versions and leave only the +latest one. Maybe relx should be able to handle this? + +thanks for the responses + +Matt + + +On 26 September 2013 21:36, Matthew Hegarty wrote: + +> yes it exists. I believe hipe is enabled by default when I compile. +> +> however there is no +> +> /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam +> /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam +> +> which is what relx is apparently looking for. +> Do you know where does relx get these paths from? +> +> +> On 26 September 2013 20:04, Tristan Sloughter > wrote: +> +>> ** +>> Did you enable hipe when you compiled? Does +>> /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist? +>> +>> -- +>> Tristan Sloughter +>> tristan.sloughter at gmail.com +>> +>> +>> +>> On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote: +>> +>> hi +>> I compiled Erlang from source (downloaded from erlang.org) +>> +>> +>> On 25 September 2013 17:25, Tristan Sloughter < +>> tristan.sloughter at gmail.com> wrote: +>> +>> +>> I ran into the same thing. I assume you installed Erlang from the Erlang +>> Solutions repo? +>> +>> Install erlang-hipe package. Or remove +>> /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. +>> +>> Their packages install a broken hipe app, missing lots of beams, for +>> some reason. But if you install the hipe package it'll install what is +>> missing. I told them about this but I haven't heard back. +>> +>> -- +>> Tristan Sloughter +>> tsloughter at fastmail.fm +>> +>> +>> On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +>> > Why does it look for hipe at all to begin with? +>> > +>> > I'll ping tristan about it. +>> > +>> > On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +>> > > hi +>> > > Just starting out so I'm trying to run cowboy's helloworld +>> > > in cowboy/examples/hello_world, running make fails with: +>> > > +>> > > ===> Provider (rlx_prv_discover) failed with: {error, +>> > > +>> {rlx_app_discovery, +>> > > +>> [{missing_beam_file, +>> > > hipe, +>> > > +>> > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +>> > > +>> {missing_beam_file, +>> > > hipe, +>> > > +>> > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +>> > > +>> > > there is no hipe.beam in +>> /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it +>> > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +>> > > I've tried passing the correct dir to relx using --lib-dir but I +>> still +>> > > get the same error. +>> > > +>> > > Any ideas what's going wrong? +>> > > +>> > > erl: Erlang R16B02 (erts-5.10.3) +>> > > relx: 0.0.0+build.275.refca03701 +>> > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git +>> 2.1.0-pre-46-g78fa8fc +>> > > +>> > > +>> > > On 22 September 2013 21:55, Matthew Hegarty > > > > wrote: +>> > > +>> > > hi +>> > > Just starting out so I've got latest versions of apps. +>> > > in cowboy/examples/hello_world, running make fails with: +>> > > +>> > > +>> > > +>> > > +>> > > +>> > > +>> > > _______________________________________________ +>> > > Extend mailing list +>> > > Extend at lists.ninenines.eu +>> > > http://lists.ninenines.eu:81/listinfo/extend +>> > > +>> > +>> > +>> > -- +>> > Lo?c Hoguin +>> +>> > Erlang Cowboy +>> > Nine Nines +>> > http://ninenines.eu +>> > _______________________________________________ +>> > Extend mailing list +>> > Extend at lists.ninenines.eu +>> > http://lists.ninenines.eu:81/listinfo/extend +>> +>> +>> -- +>> Tristan Sloughter +>> tristan.sloughter at gmail.com +>> +>> +>> +>> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From tristan.sloughter at gmail.com Sat Sep 28 22:43:25 2013 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Sat, 28 Sep 2013 13:43:25 -0700 +Subject: [99s-extend] Cowboy helloworld make fails with + missing_beam_file (hipe) +In-Reply-To: +References: + + <5242FC9C.2090501@ninenines.eu> + <1380126304.20343.26357585.70B016C0@webmail.messagingengine.com> + + <1380222240.30914.26875993.6CA5F061@webmail.messagingengine.com> + + +Message-ID: <1380401005.2981.27620409.32622BC4@webmail.messagingengine.com> + +Yea, since I doubt the OTP team (or anyone) will fix the fact that it +installs a broken hipe we've decided to just warn on broken apps during +the discovery phase. So it'll only fail if the broken app is also +suppose to be part of the release. + + + +Finishing up the relx patch right now. + + + +-- +Tristan Sloughter +tristan.sloughter at gmail.com + + + + + +On Sat, Sep 28, 2013, at 01:41 PM, Matthew Hegarty wrote: + +Got it to work. I apparently had a few versions of hipe in my Erlang +lib dir: + +$ /usr/local/lib/erlang/lib $ ll -ld hipe* +drwxr-xr-x 9 root root 4096 Feb 11 2013 hipe-3.10/ +drwxr-xr-x 9 root root 4096 Mar 1 2013 hipe-3.10.1/ +drwxr-xr-x 10 root root 4096 Jul 2 11:31 hipe-3.10.2/ +drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/ + +They must have come from previous erlang installations (compilation +from source). The solution was to remove the older versions and leave +only the latest one. Maybe relx should be able to handle this? + +thanks for the responses + +Matt + + + +On 26 September 2013 21:36, Matthew Hegarty <[1]mrhegarty at gmail.com> +wrote: + +yes it exists. I believe hipe is enabled by default when I compile. + +however there is no + + /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam + /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam + +which is what relx is apparently looking for. +Do you know where does relx get these paths from? + + + +On 26 September 2013 20:04, Tristan Sloughter +<[2]tristan.sloughter at gmail.com> wrote: + +Did you enable hipe when you compiled? Does +/usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist? + +-- +Tristan Sloughter +[3]tristan.sloughter at gmail.com + + + +On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote: + +hi + +I compiled Erlang from source (downloaded from [4]erlang.org) + + + +On 25 September 2013 17:25, Tristan Sloughter +<[5]tristan.sloughter at gmail.com> wrote: + +I ran into the same thing. I assume you installed Erlang from the +Erlang + +Solutions repo? + + + +Install erlang-hipe package. Or remove + +/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely. + + + +Their packages install a broken hipe app, missing lots of beams, for + +some reason. But if you install the hipe package it'll install what is + +missing. I told them about this but I haven't heard back. + + + +-- + + Tristan Sloughter + + [6]tsloughter at fastmail.fm + + + + +On Wed, Sep 25, 2013, at 08:09 AM, Lo?c Hoguin wrote: +> Why does it look for hipe at all to begin with? +> +> I'll ping tristan about it. +> +> On 09/22/2013 10:59 PM, Matthew Hegarty wrote: +> > hi +> > Just starting out so I'm trying to run cowboy's helloworld +> > in cowboy/examples/hello_world, running make fails with: +> > +> > ===> Provider (rlx_prv_discover) failed with: {error, +> > +{rlx_app_discovery, +> > +[{missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>}, +> > +{missing_beam_file, +> > hipe, +> > +> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}} +> > +> > there is no hipe.beam in +/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it +> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam. +> > I've tried passing the correct dir to relx using --lib-dir but I +still +> > get the same error. +> > +> > Any ideas what's going wrong? +> > +> > erl: Erlang R16B02 (erts-5.10.3) +> > relx: 0.0.0+build.275.refca03701 +> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git +2.1.0-pre-46-g78fa8fc +> > +> > +> > On 22 September 2013 21:55, Matthew Hegarty <[7]mrhegarty at gmail.com +> > > wrote: +> > +> > hi +> > Just starting out so I've got latest versions of apps. +> > in cowboy/examples/hello_world, running make fails with: +> > +> > +> > +> > +> > +> > +> > _______________________________________________ +> > Extend mailing list +> > [9]Extend at lists.ninenines.eu +> > [10]http://lists.ninenines.eu:81/listinfo/extend +> > +> +> +> -- + +> Lo?c Hoguin + + + +> Erlang Cowboy + +> Nine Nines + +> [11]http://ninenines.eu + +> _______________________________________________ +> Extend mailing list +> [12]Extend at lists.ninenines.eu +> [13]http://lists.ninenines.eu:81/listinfo/extend + + +-- + + Tristan Sloughter + + [14]tristan.sloughter at gmail.com + +References + +1. mailto:mrhegarty at gmail.com +2. mailto:tristan.sloughter at gmail.com +3. mailto:tristan.sloughter at gmail.com +4. http://erlang.org/ +5. mailto:tristan.sloughter at gmail.com +6. mailto:tsloughter at fastmail.fm +7. mailto:mrhegarty at gmail.com +8. mailto:mrhegarty at gmail.com +9. mailto:Extend at lists.ninenines.eu + 10. http://lists.ninenines.eu:81/listinfo/extend + 11. http://ninenines.eu/ + 12. mailto:Extend at lists.ninenines.eu + 13. http://lists.ninenines.eu:81/listinfo/extend + 14. mailto:tristan.sloughter at gmail.com +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2013-September/000227.html b/_build/static/archives/extend/2013-September/000227.html new file mode 100644 index 00000000..9863b688 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000227.html @@ -0,0 +1,104 @@ + + + + [99s-extend] Cowboy load test + + + + + + + + + + +

[99s-extend] Cowboy load test

+ Joe Freeman + joe.freeman at bitroot.com +
+ Sun Sep 15 19:01:30 CEST 2013 +

+
+ +
Hi,
+
+I've started work on a project using Clojure, but I was wondering whether
+(and secretly hoping that) Erlang would be a better fit, so I've been load
+testing a few web server frameworks. I'm particularly interested in how the
+server can handle a large number of concurrent WebSocket connections, and
+the test I've been running is similar to Eric Moritz's [1].
+
+I've setup a simple Cowboy 'echo' server running on an EC2 instance
+(m1.medium, as in Eric's test) which could comfortably handle 10k
+concurrent WebSocket requests (as in Eric's results), while echoing about
+200 messages/second. The CPU usage of the VM at this point is about 99%,
+but the server continues to handle up to 40k concurrent connections with a
+consistent average response time (<30ms). Pushing the test beyond this
+number results in a spike in response times and lots of connection timeouts.
+
+40k connections seems pretty good, but when comparing this to the same test
+against a couple of Clojure/JVM-based frameworks (specifically Aleph/Netty
+and http-kit) I find I can get higher numbers of concurrent connections
+with slightly better average response times (100k connections, <10ms
+response time) using much less CPU (~20%). In fact, memory seems to be the
+limiting factor.
+
+So I have two questions:
+
+1) Should I be concerned about the CPU usage in the Erlang/Cowboy test? I
+have limited experience with Erlang so far, but 100% CPU feels like a bad
+thing.
+
+2) Is there any way to increase the performance of the cowboy server? Are
+there any Erlang VM parameters I can change? The fact that the Clojure/JVM
+tests (on the same machine) have managed to get to 100k connections
+suggests that the limitation isn't being imposed by the operating system
+(I've applied changes various changes to sysctl and ulimit).
+
+(Perhaps an echo server isn't the best way to compare HTTP servers, but it
+feels like a good starting point.)
+
+Thanks for any help.
+
+[1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md - the
+GitHub repo actually contains code for an Aleph server, but results from
+this aren't included in the summary here.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130915/c9a5340e/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000228.html b/_build/static/archives/extend/2013-September/000228.html new file mode 100644 index 00000000..88282495 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000228.html @@ -0,0 +1,133 @@ + + + + [99s-extend] Cowboy load test + + + + + + + + + + +

[99s-extend] Cowboy load test

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Sep 15 21:02:35 CEST 2013 +

+
+ +
This sounds like you have too many timers, or something else is using 
+the CPU. 40k connections is literally nothing. Also make sure the 
+clients are on a separate VM/machine.
+
+Either way 99% CPU for 10k sounds high, I've had that with 0 CPU (though 
+on real hardware).
+
+Someone a couple years back got above 1 million after fixing 'too many 
+timers issues' but I don't think it was on a medium instance.
+
+On 09/15/2013 07:01 PM, Joe Freeman wrote:
+> Hi,
+>
+> I've started work on a project using Clojure, but I was wondering
+> whether (and secretly hoping that) Erlang would be a better fit, so I've
+> been load testing a few web server frameworks. I'm particularly
+> interested in how the server can handle a large number of concurrent
+> WebSocket connections, and the test I've been running is similar to Eric
+> Moritz's [1].
+>
+> I've setup a simple Cowboy 'echo' server running on an EC2 instance
+> (m1.medium, as in Eric's test) which could comfortably handle 10k
+> concurrent WebSocket requests (as in Eric's results), while echoing
+> about 200 messages/second. The CPU usage of the VM at this point is
+> about 99%, but the server continues to handle up to 40k concurrent
+> connections with a consistent average response time (<30ms). Pushing the
+> test beyond this number results in a spike in response times and lots of
+> connection timeouts.
+>
+> 40k connections seems pretty good, but when comparing this to the same
+> test against a couple of Clojure/JVM-based frameworks (specifically
+> Aleph/Netty and http-kit) I find I can get higher numbers of concurrent
+> connections with slightly better average response times (100k
+> connections, <10ms response time) using much less CPU (~20%). In fact,
+> memory seems to be the limiting factor.
+>
+> So I have two questions:
+>
+> 1) Should I be concerned about the CPU usage in the Erlang/Cowboy test?
+> I have limited experience with Erlang so far, but 100% CPU feels like a
+> bad thing.
+>
+> 2) Is there any way to increase the performance of the cowboy server?
+> Are there any Erlang VM parameters I can change? The fact that the
+> Clojure/JVM tests (on the same machine) have managed to get to 100k
+> connections suggests that the limitation isn't being imposed by the
+> operating system (I've applied changes various changes to sysctl and
+> ulimit).
+>
+> (Perhaps an echo server isn't the best way to compare HTTP servers, but
+> it feels like a good starting point.)
+>
+> Thanks for any help.
+>
+> [1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md -
+> the GitHub repo actually contains code for an Aleph server, but results
+> from this aren't included in the summary here.
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000229.html b/_build/static/archives/extend/2013-September/000229.html new file mode 100644 index 00000000..3b7176d5 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000229.html @@ -0,0 +1,143 @@ + + + + [99s-extend] Cowboy load test + + + + + + + + + + +

[99s-extend] Cowboy load test

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Sep 15 21:05:02 CEST 2013 +

+
+ +
This just hit me after hitting send.
+
+Another possibility is that you are using text frames which are required 
+to be valid UTF-8. Cowboy checks that (as required by the RFC), and it's 
+fairly expensive, while most other servers don't. Try with binary frames 
+instead.
+
+On 09/15/2013 09:02 PM, Loïc Hoguin wrote:
+> This sounds like you have too many timers, or something else is using
+> the CPU. 40k connections is literally nothing. Also make sure the
+> clients are on a separate VM/machine.
+>
+> Either way 99% CPU for 10k sounds high, I've had that with 0 CPU (though
+> on real hardware).
+>
+> Someone a couple years back got above 1 million after fixing 'too many
+> timers issues' but I don't think it was on a medium instance.
+>
+> On 09/15/2013 07:01 PM, Joe Freeman wrote:
+>> Hi,
+>>
+>> I've started work on a project using Clojure, but I was wondering
+>> whether (and secretly hoping that) Erlang would be a better fit, so I've
+>> been load testing a few web server frameworks. I'm particularly
+>> interested in how the server can handle a large number of concurrent
+>> WebSocket connections, and the test I've been running is similar to Eric
+>> Moritz's [1].
+>>
+>> I've setup a simple Cowboy 'echo' server running on an EC2 instance
+>> (m1.medium, as in Eric's test) which could comfortably handle 10k
+>> concurrent WebSocket requests (as in Eric's results), while echoing
+>> about 200 messages/second. The CPU usage of the VM at this point is
+>> about 99%, but the server continues to handle up to 40k concurrent
+>> connections with a consistent average response time (<30ms). Pushing the
+>> test beyond this number results in a spike in response times and lots of
+>> connection timeouts.
+>>
+>> 40k connections seems pretty good, but when comparing this to the same
+>> test against a couple of Clojure/JVM-based frameworks (specifically
+>> Aleph/Netty and http-kit) I find I can get higher numbers of concurrent
+>> connections with slightly better average response times (100k
+>> connections, <10ms response time) using much less CPU (~20%). In fact,
+>> memory seems to be the limiting factor.
+>>
+>> So I have two questions:
+>>
+>> 1) Should I be concerned about the CPU usage in the Erlang/Cowboy test?
+>> I have limited experience with Erlang so far, but 100% CPU feels like a
+>> bad thing.
+>>
+>> 2) Is there any way to increase the performance of the cowboy server?
+>> Are there any Erlang VM parameters I can change? The fact that the
+>> Clojure/JVM tests (on the same machine) have managed to get to 100k
+>> connections suggests that the limitation isn't being imposed by the
+>> operating system (I've applied changes various changes to sysctl and
+>> ulimit).
+>>
+>> (Perhaps an echo server isn't the best way to compare HTTP servers, but
+>> it feels like a good starting point.)
+>>
+>> Thanks for any help.
+>>
+>> [1] https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md -
+>> the GitHub repo actually contains code for an Aleph server, but results
+>> from this aren't included in the summary here.
+>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/listinfo/extend
+>>
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000230.html b/_build/static/archives/extend/2013-September/000230.html new file mode 100644 index 00000000..365029b4 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000230.html @@ -0,0 +1,76 @@ + + + + [99s-extend] how to send a message to all connections in cowboy + + + + + + + + + + +

[99s-extend] how to send a message to all connections in cowboy

+ akonsu + akonsu at gmail.com +
+ Mon Sep 16 15:50:22 CEST 2013 +

+
+ +
Hello,
+
+this is somewhat similar to what someone else has asked:
+http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html
+
+I am new to cowboy, I have a process that runs alongside a cowboy server
+and this process needs to periodically send text to all http clients
+connected to the cowboy server. My goal is to have a streaming connection
+for each http client so that I could stream text to them from my process.
+how is this done?
+
+Thanks!
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130916/dedbf486/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000231.html b/_build/static/archives/extend/2013-September/000231.html new file mode 100644 index 00000000..aa0fe981 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000231.html @@ -0,0 +1,85 @@ + + + + [99s-extend] how to send a message to all connections in cowboy + + + + + + + + + + +

[99s-extend] how to send a message to all connections in cowboy

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Sep 16 19:06:32 CEST 2013 +

+
+ +
On 09/16/2013 03:50 PM, akonsu wrote:
+> Hello,
+>
+> this is somewhat similar to what someone else has asked:
+> http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html
+>
+> I am new to cowboy, I have a process that runs alongside a cowboy server
+> and this process needs to periodically send text to all http clients
+> connected to the cowboy server. My goal is to have a streaming
+> connection for each http client so that I could stream text to them from
+> my process. how is this done?
+
+Same answer really. You need some kind of process registry, like gproc 
+properties for example, that will store all Pids and allow you to send a 
+message to all of them.
+
+On init, register the process, and then handle the incoming message when 
+it arrives.
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000232.html b/_build/static/archives/extend/2013-September/000232.html new file mode 100644 index 00000000..623d57ed --- /dev/null +++ b/_build/static/archives/extend/2013-September/000232.html @@ -0,0 +1,99 @@ + + + + [99s-extend] how to send a message to all connections in cowboy + + + + + + + + + + +

[99s-extend] how to send a message to all connections in cowboy

+ akonsu + akonsu at gmail.com +
+ Mon Sep 16 19:14:24 CEST 2013 +

+
+ +
thanks. Suppose my external process is registered and has a name, so I can
+discover it by name from my cowboy request handler. when my cowboy handler
+is invoked, can I just send the handler's process ID to the external
+process? the question is then how does the external process know that the
+http client has disconnected so that it can stop sending data to it.
+
+
+2013/9/16 Loïc Hoguin <essen at ninenines.eu>
+
+> On 09/16/2013 03:50 PM, akonsu wrote:
+>
+>> Hello,
+>>
+>> this is somewhat similar to what someone else has asked:
+>> http://lists.ninenines.eu:81/**archives/extend/2013-August/**000224.html<http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html>
+>>
+>> I am new to cowboy, I have a process that runs alongside a cowboy server
+>> and this process needs to periodically send text to all http clients
+>> connected to the cowboy server. My goal is to have a streaming
+>> connection for each http client so that I could stream text to them from
+>> my process. how is this done?
+>>
+>
+> Same answer really. You need some kind of process registry, like gproc
+> properties for example, that will store all Pids and allow you to send a
+> message to all of them.
+>
+> On init, register the process, and then handle the incoming message when
+> it arrives.
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130916/f55d10f5/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000233.html b/_build/static/archives/extend/2013-September/000233.html new file mode 100644 index 00000000..1ac511fd --- /dev/null +++ b/_build/static/archives/extend/2013-September/000233.html @@ -0,0 +1,116 @@ + + + + [99s-extend] how to send a message to all connections in cowboy + + + + + + + + + + +

[99s-extend] how to send a message to all connections in cowboy

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Sep 16 19:19:59 CEST 2013 +

+
+ +
Monitors.
+
+But really gproc does all that for you and is already well tested.
+
+https://github.com/esl/gproc
+
+On 09/16/2013 07:14 PM, akonsu wrote:
+> thanks. Suppose my external process is registered and has a name, so I
+> can discover it by name from my cowboy request handler. when my cowboy
+> handler is invoked, can I just send the handler's process ID to the
+> external process? the question is then how does the external process
+> know that the http client has disconnected so that it can stop sending
+> data to it.
+>
+>
+> 2013/9/16 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     On 09/16/2013 03:50 PM, akonsu wrote:
+>
+>         Hello,
+>
+>         this is somewhat similar to what someone else has asked:
+>         http://lists.ninenines.eu:81/__archives/extend/2013-August/__000224.html
+>         <http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html>
+>
+>         I am new to cowboy, I have a process that runs alongside a
+>         cowboy server
+>         and this process needs to periodically send text to all http clients
+>         connected to the cowboy server. My goal is to have a streaming
+>         connection for each http client so that I could stream text to
+>         them from
+>         my process. how is this done?
+>
+>
+>     Same answer really. You need some kind of process registry, like
+>     gproc properties for example, that will store all Pids and allow you
+>     to send a message to all of them.
+>
+>     On init, register the process, and then handle the incoming message
+>     when it arrives.
+>
+>     --
+>     Loďc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000234.html b/_build/static/archives/extend/2013-September/000234.html new file mode 100644 index 00000000..b282a715 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000234.html @@ -0,0 +1,77 @@ + + + + [99s-extend] cowboy_loop_handler + + + + + + + + + + +

[99s-extend] cowboy_loop_handler

+ akonsu + akonsu at gmail.com +
+ Thu Sep 19 06:30:57 CEST 2013 +

+
+ +
Hello,
+
+from the documentation:
+
+info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State} | {loop,
+Req, State, hibernate}
+
+
+in case my handler receives a lot of messages, and they come very often,
+does a response of the latter form {loop, Req, State, hibernate} save
+anything? Can hibernating in this case actually hinder performance?
+
+thanks
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130919/9614ef5e/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000235.html b/_build/static/archives/extend/2013-September/000235.html new file mode 100644 index 00000000..cb8fdc7b --- /dev/null +++ b/_build/static/archives/extend/2013-September/000235.html @@ -0,0 +1,97 @@ + + + + [99s-extend] cowboy_loop_handler + + + + + + + + + + +

[99s-extend] cowboy_loop_handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Sep 19 11:03:02 CEST 2013 +

+
+ +
How much is a lot of messages?
+
+Hibernating is a bit more expensive on the CPU but better for saving 
+memory. It's generally fine to use except when you have a really busy 
+system. Do note that it also means your responses will be slightly 
+slower (though that is generally not noticeable).
+
+On 09/19/2013 06:30 AM, akonsu wrote:
+> Hello,
+>
+> from the documentation:
+>
+> info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}| {loop,
+> Req, State, hibernate}
+>
+>
+> in case my handler receives a lot of messages, and they come very often,
+> does a response of the latter form {loop, Req, State, hibernate} save
+> anything? Can hibernating in this case actually hinder performance?
+>
+> thanks
+> Konstantin
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000236.html b/_build/static/archives/extend/2013-September/000236.html new file mode 100644 index 00000000..c45f3491 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000236.html @@ -0,0 +1,109 @@ + + + + [99s-extend] cowboy_loop_handler + + + + + + + + + + +

[99s-extend] cowboy_loop_handler

+ akonsu + akonsu at gmail.com +
+ Thu Sep 19 13:37:58 CEST 2013 +

+
+ +
my http handler receives messages carrying json parts obtained from a
+twitter stream by a separate process. the twitter stream is the stream of
+all public tweets, (they call it "firehose") so there are a lot.
+
+
+2013/9/19 Loïc Hoguin <essen at ninenines.eu>
+
+> How much is a lot of messages?
+>
+> Hibernating is a bit more expensive on the CPU but better for saving
+> memory. It's generally fine to use except when you have a really busy
+> system. Do note that it also means your responses will be slightly slower
+> (though that is generally not noticeable).
+>
+>
+> On 09/19/2013 06:30 AM, akonsu wrote:
+>
+>> Hello,
+>>
+>> from the documentation:
+>>
+>> info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}| {loop,
+>> Req, State, hibernate}
+>>
+>>
+>> in case my handler receives a lot of messages, and they come very often,
+>> does a response of the latter form {loop, Req, State, hibernate} save
+>> anything? Can hibernating in this case actually hinder performance?
+>>
+>> thanks
+>> Konstantin
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130919/0a4bcb6c/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000237.html b/_build/static/archives/extend/2013-September/000237.html new file mode 100644 index 00000000..68c95fbb --- /dev/null +++ b/_build/static/archives/extend/2013-September/000237.html @@ -0,0 +1,84 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Fri Sep 20 20:47:54 CEST 2013 +

+
+ +
Hi,
+
+I am using loop handler and I stream from it:
+
+info({stream, Part}, Req, S) ->
+    ok = cowboy_req:chunk(Part, Req),
+    {loop, Req, S, hibernate};
+
+I have two questions:
+
+1. on timeouts cowboy sends 204 No Content. In my case it is not the right
+response because I may have already sent some data. Is there a way to send
+a custom response?
+
+2. how to check if the client is too slow and is not reading the response
+stream fast enough? If this happens, then I need to disconnect.
+
+I can live without 1. but I need to figure out 2. Please help.
+
+thank you!
+Konstantin
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130920/6e3fa036/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000238.html b/_build/static/archives/extend/2013-September/000238.html new file mode 100644 index 00000000..9a244158 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000238.html @@ -0,0 +1,105 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Sep 20 20:50:57 CEST 2013 +

+
+ +
Loop handlers close after a while regardless of what you send, it only 
+checks what the client sends. The best way for you would be to disable 
+that timeout and handle it manually.
+
+As for the second question, I'm still reading the thread on 
+erlang-questions but I've seen some good ideas about timestamps so far.
+
+On 09/20/2013 08:47 PM, akonsu wrote:
+> Hi,
+>
+> I am using loop handler and I stream from it:
+>
+> info({stream, Part}, Req, S) ->
+>      ok = cowboy_req:chunk(Part, Req),
+>      {loop, Req, S, hibernate};
+>
+> I have two questions:
+>
+> 1. on timeouts cowboy sends 204 No Content. In my case it is not the
+> right response because I may have already sent some data. Is there a way
+> to send a custom response?
+>
+> 2. how to check if the client is too slow and is not reading the
+> response stream fast enough? If this happens, then I need to disconnect.
+>
+> I can live without 1. but I need to figure out 2. Please help.
+>
+> thank you!
+> Konstantin
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000239.html b/_build/static/archives/extend/2013-September/000239.html new file mode 100644 index 00000000..e9bb837c --- /dev/null +++ b/_build/static/archives/extend/2013-September/000239.html @@ -0,0 +1,124 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Fri Sep 20 20:54:56 CEST 2013 +

+
+ +
thanks!
+
+how to implement timeout callback manually? if I had receive then I would
+just use timeout clause there, but with the handler I do not know...
+
+I have doubts about validity of my question on the erlang list.  I later
+realised that there is no problem receiving messages in my handler from my
+upstream process, I can do it fast enough and shove everything to the
+response. my real problem is to determine if the http client is reading
+fast enough from the response...
+
+
+2013/9/20 Loïc Hoguin <essen at ninenines.eu>
+
+> Loop handlers close after a while regardless of what you send, it only
+> checks what the client sends. The best way for you would be to disable that
+> timeout and handle it manually.
+>
+> As for the second question, I'm still reading the thread on
+> erlang-questions but I've seen some good ideas about timestamps so far.
+>
+>
+> On 09/20/2013 08:47 PM, akonsu wrote:
+>
+>> Hi,
+>>
+>> I am using loop handler and I stream from it:
+>>
+>> info({stream, Part}, Req, S) ->
+>>      ok = cowboy_req:chunk(Part, Req),
+>>      {loop, Req, S, hibernate};
+>>
+>> I have two questions:
+>>
+>> 1. on timeouts cowboy sends 204 No Content. In my case it is not the
+>> right response because I may have already sent some data. Is there a way
+>> to send a custom response?
+>>
+>> 2. how to check if the client is too slow and is not reading the
+>> response stream fast enough? If this happens, then I need to disconnect.
+>>
+>> I can live without 1. but I need to figure out 2. Please help.
+>>
+>> thank you!
+>> Konstantin
+>>
+>>
+>>
+>> ______________________________**_________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>>
+>>
+>
+> --
+> Loďc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130920/32352505/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000240.html b/_build/static/archives/extend/2013-September/000240.html new file mode 100644 index 00000000..a5c5c8b3 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000240.html @@ -0,0 +1,140 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Sep 20 20:56:31 CEST 2013 +

+
+ +
chunk only returns when the client has received the chunk, so the 
+timestamps solution should work.
+
+As for the timeout, you can simply use erlang:send_after or something 
+like usual and the message will arrive in info/3.
+
+On 09/20/2013 08:54 PM, akonsu wrote:
+> thanks!
+>
+> how to implement timeout callback manually? if I had receive then I
+> would just use timeout clause there, but with the handler I do not know...
+>
+> I have doubts about validity of my question on the erlang list.  I later
+> realised that there is no problem receiving messages in my handler from
+> my upstream process, I can do it fast enough and shove everything to the
+> response. my real problem is to determine if the http client is reading
+> fast enough from the response...
+>
+>
+> 2013/9/20 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     Loop handlers close after a while regardless of what you send, it
+>     only checks what the client sends. The best way for you would be to
+>     disable that timeout and handle it manually.
+>
+>     As for the second question, I'm still reading the thread on
+>     erlang-questions but I've seen some good ideas about timestamps so far.
+>
+>
+>     On 09/20/2013 08:47 PM, akonsu wrote:
+>
+>         Hi,
+>
+>         I am using loop handler and I stream from it:
+>
+>         info({stream, Part}, Req, S) ->
+>               ok = cowboy_req:chunk(Part, Req),
+>               {loop, Req, S, hibernate};
+>
+>         I have two questions:
+>
+>         1. on timeouts cowboy sends 204 No Content. In my case it is not the
+>         right response because I may have already sent some data. Is
+>         there a way
+>         to send a custom response?
+>
+>         2. how to check if the client is too slow and is not reading the
+>         response stream fast enough? If this happens, then I need to
+>         disconnect.
+>
+>         I can live without 1. but I need to figure out 2. Please help.
+>
+>         thank you!
+>         Konstantin
+>
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>
+>
+>
+>
+>     --
+>     Loďc Hoguin
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000241.html b/_build/static/archives/extend/2013-September/000241.html new file mode 100644 index 00000000..da555d9a --- /dev/null +++ b/_build/static/archives/extend/2013-September/000241.html @@ -0,0 +1,163 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ akonsu + akonsu at gmail.com +
+ Fri Sep 20 20:59:46 CEST 2013 +

+
+ +
Understand about chunks being synchronous. that helps me tremendously to
+understand how it works.
+
+would you give me a sketchy example of how to use send_after in a loop
+handler? (sorry I am new to erlang)
+
+Konstantin
+
+
+2013/9/20 Loïc Hoguin <essen at ninenines.eu>
+
+> chunk only returns when the client has received the chunk, so the
+> timestamps solution should work.
+>
+> As for the timeout, you can simply use erlang:send_after or something like
+> usual and the message will arrive in info/3.
+>
+>
+> On 09/20/2013 08:54 PM, akonsu wrote:
+>
+>> thanks!
+>>
+>> how to implement timeout callback manually? if I had receive then I
+>> would just use timeout clause there, but with the handler I do not know...
+>>
+>> I have doubts about validity of my question on the erlang list.  I later
+>> realised that there is no problem receiving messages in my handler from
+>> my upstream process, I can do it fast enough and shove everything to the
+>> response. my real problem is to determine if the http client is reading
+>> fast enough from the response...
+>>
+>>
+>> 2013/9/20 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>>
+>>
+>>     Loop handlers close after a while regardless of what you send, it
+>>     only checks what the client sends. The best way for you would be to
+>>     disable that timeout and handle it manually.
+>>
+>>     As for the second question, I'm still reading the thread on
+>>     erlang-questions but I've seen some good ideas about timestamps so
+>> far.
+>>
+>>
+>>     On 09/20/2013 08:47 PM, akonsu wrote:
+>>
+>>         Hi,
+>>
+>>         I am using loop handler and I stream from it:
+>>
+>>         info({stream, Part}, Req, S) ->
+>>               ok = cowboy_req:chunk(Part, Req),
+>>               {loop, Req, S, hibernate};
+>>
+>>         I have two questions:
+>>
+>>         1. on timeouts cowboy sends 204 No Content. In my case it is not
+>> the
+>>         right response because I may have already sent some data. Is
+>>         there a way
+>>         to send a custom response?
+>>
+>>         2. how to check if the client is too slow and is not reading the
+>>         response stream fast enough? If this happens, then I need to
+>>         disconnect.
+>>
+>>         I can live without 1. but I need to figure out 2. Please help.
+>>
+>>         thank you!
+>>         Konstantin
+>>
+>>
+>>
+>>         ______________________________**___________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.**ninenines.eu<Extend at lists.ninenines.eu>
+>> >
+>>         http://lists.ninenines.eu:81/_**_listinfo/extend<http://lists.ninenines.eu:81/__listinfo/extend>
+>>
+>>         <http://lists.ninenines.eu:81/**listinfo/extend<http://lists.ninenines.eu:81/listinfo/extend>
+>> >
+>>
+>>
+>>
+>>     --
+>>     Loďc Hoguin
+>>     Erlang Cowboy
+>>     Nine Nines
+>>     http://ninenines.eu
+>>
+>>
+>>
+>
+> --
+> Loïc Hoguin
+>
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130920/4c005881/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000242.html b/_build/static/archives/extend/2013-September/000242.html new file mode 100644 index 00000000..a9e2c705 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000242.html @@ -0,0 +1,191 @@ + + + + [99s-extend] timeouts and slow clients in cowboy loop handler + + + + + + + + + + +

[99s-extend] timeouts and slow clients in cowboy loop handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Sep 20 21:04:34 CEST 2013 +

+
+ +
send_after sends an Erlang message to a Pid after N milliseconds. It's 
+the same as Pid ! Message, except it's sent later. Send it to self().
+
+But if you're going to use timestamps then you probably don't need this 
+timeout, just check the timestamps and close when too slow.
+
+On 09/20/2013 08:59 PM, akonsu wrote:
+> Understand about chunks being synchronous. that helps me tremendously to
+> understand how it works.
+>
+> would you give me a sketchy example of how to use send_after in a loop
+> handler? (sorry I am new to erlang)
+>
+> Konstantin
+>
+>
+> 2013/9/20 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>
+>     chunk only returns when the client has received the chunk, so the
+>     timestamps solution should work.
+>
+>     As for the timeout, you can simply use erlang:send_after or
+>     something like usual and the message will arrive in info/3.
+>
+>
+>     On 09/20/2013 08:54 PM, akonsu wrote:
+>
+>         thanks!
+>
+>         how to implement timeout callback manually? if I had receive then I
+>         would just use timeout clause there, but with the handler I do
+>         not know...
+>
+>         I have doubts about validity of my question on the erlang list.
+>           I later
+>         realised that there is no problem receiving messages in my
+>         handler from
+>         my upstream process, I can do it fast enough and shove
+>         everything to the
+>         response. my real problem is to determine if the http client is
+>         reading
+>         fast enough from the response...
+>
+>
+>         2013/9/20 Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu> <mailto:essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>>>
+>
+>
+>              Loop handlers close after a while regardless of what you
+>         send, it
+>              only checks what the client sends. The best way for you
+>         would be to
+>              disable that timeout and handle it manually.
+>
+>              As for the second question, I'm still reading the thread on
+>              erlang-questions but I've seen some good ideas about
+>         timestamps so far.
+>
+>
+>              On 09/20/2013 08:47 PM, akonsu wrote:
+>
+>                  Hi,
+>
+>                  I am using loop handler and I stream from it:
+>
+>                  info({stream, Part}, Req, S) ->
+>                        ok = cowboy_req:chunk(Part, Req),
+>                        {loop, Req, S, hibernate};
+>
+>                  I have two questions:
+>
+>                  1. on timeouts cowboy sends 204 No Content. In my case
+>         it is not the
+>                  right response because I may have already sent some
+>         data. Is
+>                  there a way
+>                  to send a custom response?
+>
+>                  2. how to check if the client is too slow and is not
+>         reading the
+>                  response stream fast enough? If this happens, then I
+>         need to
+>                  disconnect.
+>
+>                  I can live without 1. but I need to figure out 2.
+>         Please help.
+>
+>                  thank you!
+>                  Konstantin
+>
+>
+>
+>                  ___________________________________________________
+>                  Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.__ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         http://lists.ninenines.eu:81/____listinfo/extend
+>         <http://lists.ninenines.eu:81/__listinfo/extend>
+>
+>                  <http://lists.ninenines.eu:81/__listinfo/extend
+>         <http://lists.ninenines.eu:81/listinfo/extend>>
+>
+>
+>
+>              --
+>              Loďc Hoguin
+>              Erlang Cowboy
+>              Nine Nines
+>         http://ninenines.eu
+>
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>
+>     Erlang Cowboy
+>     Nine Nines
+>     http://ninenines.eu
+>
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000243.html b/_build/static/archives/extend/2013-September/000243.html new file mode 100644 index 00000000..783433f9 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000243.html @@ -0,0 +1,66 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Matthew Hegarty + mrhegarty at gmail.com +
+ Sun Sep 22 22:55:31 CEST 2013 +

+
+ +
hi
+Just starting out so I've got latest versions of apps.
+in cowboy/examples/hello_world, running make fails with:
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130922/77e355ff/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000244.html b/_build/static/archives/extend/2013-September/000244.html new file mode 100644 index 00000000..175e1b7a --- /dev/null +++ b/_build/static/archives/extend/2013-September/000244.html @@ -0,0 +1,99 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Matthew Hegarty + mrhegarty at gmail.com +
+ Sun Sep 22 22:59:37 CEST 2013 +

+
+ +
hi
+Just starting out so I'm trying to run cowboy's helloworld
+in cowboy/examples/hello_world, running make fails with:
+
+===> Provider (rlx_prv_discover) failed with: {error,
+                                                      {rlx_app_discovery,
+                                                       [{missing_beam_file,
+                                                         hipe,
+
+<<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+                                                        {missing_beam_file,
+                                                         hipe,
+
+<<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+
+there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it is
+in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+I've tried passing the correct dir to relx using --lib-dir but I still get
+the same error.
+
+Any ideas what's going wrong?
+
+erl: Erlang R16B02 (erts-5.10.3)
+relx: 0.0.0+build.275.refca03701
+rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc
+
+
+On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com> wrote:
+
+> hi
+> Just starting out so I've got latest versions of apps.
+> in cowboy/examples/hello_world, running make fails with:
+>
+>
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130922/6e925e9d/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000245.html b/_build/static/archives/extend/2013-September/000245.html new file mode 100644 index 00000000..4912361a --- /dev/null +++ b/_build/static/archives/extend/2013-September/000245.html @@ -0,0 +1,117 @@ + + + + [99s-extend] Cowboy: Having problems with Getting Started + + + + + + + + + + +

[99s-extend] Cowboy: Having problems with Getting Started

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Mon Sep 23 01:57:41 CEST 2013 +

+
+ +
Hello,
+
+Forgive my ignorance, but I'm having problems with the Getting Started chapter of the Cowboy Guide.
+
+Near the end I can download relx just fine. But there seems to be a hidden assumption shared, perhaps, by all Erlang cowboys but outside my understanding.
+
+When I get to $./relx, the following is returned:
+
+lloyd at Reliance:~/hello_erlang/relx$ ./relx
+===> Starting relx build process ...
+===> Resolving OTP Applications from directories:
+          /home/lloyd/hello_erlang/relx/ebin
+          /home/lloyd/hello_erlang/relx/deps
+          /usr/lib/erlang/lib
+
+===> Resolving available OTP Releases from directories:
+          /home/lloyd/hello_erlang/relx/ebin
+          /home/lloyd/hello_erlang/relx/deps
+          /usr/lib/erlang/lib
+
+Failed to solve release:
+ Dependency hello_erlang is specified as a dependency but is not reachable by the system.
+
+I've added all variations to .erlang that I can think of to put hello_erlang into the code path, but none seem to work. Can some kind soul let me in on the secret?
+
+Many thanks,
+
+Lloyd
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000246.html b/_build/static/archives/extend/2013-September/000246.html new file mode 100644 index 00000000..90276dba --- /dev/null +++ b/_build/static/archives/extend/2013-September/000246.html @@ -0,0 +1,117 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Sep 25 17:09:16 CEST 2013 +

+
+ +
Why does it look for hipe at all to begin with?
+
+I'll ping tristan about it.
+
+On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+> hi
+> Just starting out so I'm trying to run cowboy's helloworld
+> in cowboy/examples/hello_world, running make fails with:
+>
+> ===> Provider (rlx_prv_discover) failed with: {error,
+>                                                        {rlx_app_discovery,
+>                                                         [{missing_beam_file,
+>                                                           hipe,
+>
+> <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+>                                                          {missing_beam_file,
+>                                                           hipe,
+>
+> <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+>
+> there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it
+> is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+> I've tried passing the correct dir to relx using --lib-dir but I still
+> get the same error.
+>
+> Any ideas what's going wrong?
+>
+> erl: Erlang R16B02 (erts-5.10.3)
+> relx: 0.0.0+build.275.refca03701
+> rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc
+>
+>
+> On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com
+> <mailto:mrhegarty at gmail.com>> wrote:
+>
+>     hi
+>     Just starting out so I've got latest versions of apps.
+>     in cowboy/examples/hello_world, running make fails with:
+>
+>
+>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000247.html b/_build/static/archives/extend/2013-September/000247.html new file mode 100644 index 00000000..c5263d81 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000247.html @@ -0,0 +1,134 @@ + + + + [99s-extend] Cowboy: Having problems with Getting Started + + + + + + + + + + +

[99s-extend] Cowboy: Having problems with Getting Started

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Sep 25 17:10:01 CEST 2013 +

+
+ +
On 09/23/2013 01:57 AM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> Forgive my ignorance, but I'm having problems with the Getting Started chapter of the Cowboy Guide.
+>
+> Near the end I can download relx just fine. But there seems to be a hidden assumption shared, perhaps, by all Erlang cowboys but outside my understanding.
+>
+> When I get to $./relx, the following is returned:
+>
+> lloyd at Reliance:~/hello_erlang/relx$ ./relx
+
+You're in hello_erlang/relx, I'm guessing you want to do that in 
+hello_erlang/ directly.
+
+> ===> Starting relx build process ...
+> ===> Resolving OTP Applications from directories:
+>            /home/lloyd/hello_erlang/relx/ebin
+>            /home/lloyd/hello_erlang/relx/deps
+>            /usr/lib/erlang/lib
+>
+> ===> Resolving available OTP Releases from directories:
+>            /home/lloyd/hello_erlang/relx/ebin
+>            /home/lloyd/hello_erlang/relx/deps
+>            /usr/lib/erlang/lib
+>
+> Failed to solve release:
+>   Dependency hello_erlang is specified as a dependency but is not reachable by the system.
+>
+> I've added all variations to .erlang that I can think of to put hello_erlang into the code path, but none seem to work. Can some kind soul let me in on the secret?
+>
+> Many thanks,
+>
+> Lloyd
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+>
+
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000248.html b/_build/static/archives/extend/2013-September/000248.html new file mode 100644 index 00000000..3d6dd723 --- /dev/null +++ b/_build/static/archives/extend/2013-September/000248.html @@ -0,0 +1,141 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Wed Sep 25 18:25:04 CEST 2013 +

+
+ +
I ran into the same thing. I assume you installed Erlang from the Erlang
+Solutions repo?
+
+Install erlang-hipe package. Or remove
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+
+Their packages install a broken hipe app, missing lots of beams, for
+some reason. But if you install the hipe package it'll install what is
+missing. I told them about this but I haven't heard back.
+
+-- 
+  Tristan Sloughter
+  tsloughter at fastmail.fm
+
+On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+> Why does it look for hipe at all to begin with?
+> 
+> I'll ping tristan about it.
+> 
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+> > hi
+> > Just starting out so I'm trying to run cowboy's helloworld
+> > in cowboy/examples/hello_world, running make fails with:
+> >
+> > ===> Provider (rlx_prv_discover) failed with: {error,
+> >                                                        {rlx_app_discovery,
+> >                                                         [{missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+> >                                                          {missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+> >
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+> > I've tried passing the correct dir to relx using --lib-dir but I still
+> > get the same error.
+> >
+> > Any ideas what's going wrong?
+> >
+> > erl: Erlang R16B02 (erts-5.10.3)
+> > relx: 0.0.0+build.275.refca03701
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc
+> >
+> >
+> > On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com
+> > <mailto:mrhegarty at gmail.com>> wrote:
+> >
+> >     hi
+> >     Just starting out so I've got latest versions of apps.
+> >     in cowboy/examples/hello_world, running make fails with:
+> >
+> >
+> >
+> >
+> >
+> >
+> > _______________________________________________
+> > Extend mailing list
+> > Extend at lists.ninenines.eu
+> > http://lists.ninenines.eu:81/listinfo/extend
+> >
+> 
+> 
+> -- 
+> Loïc Hoguin
+> Erlang Cowboy
+> Nine Nines
+> http://ninenines.eu
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> http://lists.ninenines.eu:81/listinfo/extend
+
+
+-- 
+  Tristan Sloughter
+  tristan.sloughter at gmail.com
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000249.html b/_build/static/archives/extend/2013-September/000249.html new file mode 100644 index 00000000..cc39f8fe --- /dev/null +++ b/_build/static/archives/extend/2013-September/000249.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Mailing lists maintenance 28th of September + + + + + + + + + + +

[99s-extend] Mailing lists maintenance 28th of September

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Sep 25 18:27:58 CEST 2013 +

+
+ +
Hello,
+
+Just a heads up, I will be moving the mailing lists to a new server 
+Saturday. As a result they might be unavailable for a couple hours/days 
+depending on how well I manage to do it.
+
+Thanks for your understanding!
+
+-- 
+Loïc Hoguin
+Erlang Cowboy
+Nine Nines
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000250.html b/_build/static/archives/extend/2013-September/000250.html new file mode 100644 index 00000000..75ceea7c --- /dev/null +++ b/_build/static/archives/extend/2013-September/000250.html @@ -0,0 +1,155 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Matthew Hegarty + mrhegarty at gmail.com +
+ Thu Sep 26 21:03:06 CEST 2013 +

+
+ +
hi
+I compiled Erlang from source (downloaded from erlang.org)
+
+
+On 25 September 2013 17:25, Tristan Sloughter
+<tristan.sloughter at gmail.com>wrote:
+
+> I ran into the same thing. I assume you installed Erlang from the Erlang
+> Solutions repo?
+>
+> Install erlang-hipe package. Or remove
+> /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+>
+> Their packages install a broken hipe app, missing lots of beams, for
+> some reason. But if you install the hipe package it'll install what is
+> missing. I told them about this but I haven't heard back.
+>
+> --
+>   Tristan Sloughter
+>   tsloughter at fastmail.fm
+>
+> On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+> > Why does it look for hipe at all to begin with?
+> >
+> > I'll ping tristan about it.
+> >
+> > On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+> > > hi
+> > > Just starting out so I'm trying to run cowboy's helloworld
+> > > in cowboy/examples/hello_world, running make fails with:
+> > >
+> > > ===> Provider (rlx_prv_discover) failed with: {error,
+> > >
+>  {rlx_app_discovery,
+> > >
+> [{missing_beam_file,
+> > >                                                           hipe,
+> > >
+> > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+> > >
+>  {missing_beam_file,
+> > >                                                           hipe,
+> > >
+> > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+> > >
+> > > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/,
+> it
+> > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+> > > I've tried passing the correct dir to relx using --lib-dir but I still
+> > > get the same error.
+> > >
+> > > Any ideas what's going wrong?
+> > >
+> > > erl: Erlang R16B02 (erts-5.10.3)
+> > > relx: 0.0.0+build.275.refca03701
+> > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc
+> > >
+> > >
+> > > On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com
+> > > <mailto:mrhegarty at gmail.com>> wrote:
+> > >
+> > >     hi
+> > >     Just starting out so I've got latest versions of apps.
+> > >     in cowboy/examples/hello_world, running make fails with:
+> > >
+> > >
+> > >
+> > >
+> > >
+> > >
+> > > _______________________________________________
+> > > Extend mailing list
+> > > Extend at lists.ninenines.eu
+> > > http://lists.ninenines.eu:81/listinfo/extend
+> > >
+> >
+> >
+> > --
+> > Loïc Hoguin
+> > Erlang Cowboy
+> > Nine Nines
+> > http://ninenines.eu
+> > _______________________________________________
+> > Extend mailing list
+> > Extend at lists.ninenines.eu
+> > http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+> --
+>   Tristan Sloughter
+>   tristan.sloughter at gmail.com
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130926/d34b33e3/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000251.html b/_build/static/archives/extend/2013-September/000251.html new file mode 100644 index 00000000..1bb672ae --- /dev/null +++ b/_build/static/archives/extend/2013-September/000251.html @@ -0,0 +1,212 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Thu Sep 26 21:04:00 CEST 2013 +

+
+ +
Did you enable hipe when you compiled? Does
+/usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?
+
+
+
+--
+Tristan Sloughter
+tristan.sloughter at gmail.com
+
+
+
+
+
+On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:
+
+hi
+
+I compiled Erlang from source (downloaded from [1]erlang.org)
+
+
+
+On 25 September 2013 17:25, Tristan Sloughter
+<[2]tristan.sloughter at gmail.com> wrote:
+
+I ran into the same thing. I assume you installed Erlang from the
+Erlang
+
+Solutions repo?
+
+
+
+Install erlang-hipe package. Or remove
+
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+
+
+
+Their packages install a broken hipe app, missing lots of beams, for
+
+some reason. But if you install the hipe package it'll install what is
+
+missing. I told them about this but I haven't heard back.
+
+
+
+--
+
+  Tristan Sloughter
+
+  [3]tsloughter at fastmail.fm
+
+
+
+
+On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+> Why does it look for hipe at all to begin with?
+>
+> I'll ping tristan about it.
+>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+> > hi
+> > Just starting out so I'm trying to run cowboy's helloworld
+> > in cowboy/examples/hello_world, running make fails with:
+> >
+> > ===> Provider (rlx_prv_discover) failed with: {error,
+> >
+{rlx_app_discovery,
+> >
+[{missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+> >
+{missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+> >
+> > there is no hipe.beam in
+/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+> > I've tried passing the correct dir to relx using --lib-dir but I
+still
+> > get the same error.
+> >
+> > Any ideas what's going wrong?
+> >
+> > erl: Erlang R16B02 (erts-5.10.3)
+> > relx: 0.0.0+build.275.refca03701
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git
+2.1.0-pre-46-g78fa8fc
+> >
+> >
+> > On 22 September 2013 21:55, Matthew Hegarty <[4]mrhegarty at gmail.com
+> > <mailto:[5]mrhegarty at gmail.com>> wrote:
+> >
+> >     hi
+> >     Just starting out so I've got latest versions of apps.
+> >     in cowboy/examples/hello_world, running make fails with:
+> >
+> >
+> >
+> >
+> >
+> >
+> > _______________________________________________
+> > Extend mailing list
+> > [6]Extend at lists.ninenines.eu
+> > [7]http://lists.ninenines.eu:81/listinfo/extend
+> >
+>
+>
+> --
+
+> Loïc Hoguin
+
+
+
+> Erlang Cowboy
+
+> Nine Nines
+
+> [8]http://ninenines.eu
+
+> _______________________________________________
+> Extend mailing list
+> [9]Extend at lists.ninenines.eu
+> [10]http://lists.ninenines.eu:81/listinfo/extend
+
+
+--
+
+  Tristan Sloughter
+
+  [11]tristan.sloughter at gmail.com
+
+References
+
+1. http://erlang.org/
+2. mailto:tristan.sloughter at gmail.com
+3. mailto:tsloughter at fastmail.fm
+4. mailto:mrhegarty at gmail.com
+5. mailto:mrhegarty at gmail.com
+6. mailto:Extend at lists.ninenines.eu
+7. http://lists.ninenines.eu:81/listinfo/extend
+8. http://ninenines.eu/
+9. mailto:Extend at lists.ninenines.eu
+  10. http://lists.ninenines.eu:81/listinfo/extend
+  11. mailto:tristan.sloughter at gmail.com
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130926/28d38e59/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000252.html b/_build/static/archives/extend/2013-September/000252.html new file mode 100644 index 00000000..68aa9a1a --- /dev/null +++ b/_build/static/archives/extend/2013-September/000252.html @@ -0,0 +1,188 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Matthew Hegarty + mrhegarty at gmail.com +
+ Thu Sep 26 22:36:03 CEST 2013 +

+
+ +
yes it exists.  I believe hipe is enabled by default when I compile.
+
+however there is no
+
+ /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam
+ /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam
+
+which is what relx is apparently looking for.
+Do you know where does relx get these paths from?
+
+
+On 26 September 2013 20:04, Tristan Sloughter
+<tristan.sloughter at gmail.com>wrote:
+
+> **
+> Did you enable hipe when you compiled? Does
+> /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?
+>
+> --
+>  Tristan Sloughter
+>  tristan.sloughter at gmail.com
+>
+>
+>
+> On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:
+>
+> hi
+> I compiled Erlang from source (downloaded from erlang.org)
+>
+>
+> On 25 September 2013 17:25, Tristan Sloughter <tristan.sloughter at gmail.com
+> > wrote:
+>
+>
+> I ran into the same thing. I assume you installed Erlang from the Erlang
+>  Solutions repo?
+>
+>  Install erlang-hipe package. Or remove
+>  /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+>
+>  Their packages install a broken hipe app, missing lots of beams, for
+>  some reason. But if you install the hipe package it'll install what is
+>  missing. I told them about this but I haven't heard back.
+>
+>  --
+>    Tristan Sloughter
+>    tsloughter at fastmail.fm
+>
+>
+>  On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+>  > Why does it look for hipe at all to begin with?
+>  >
+>  > I'll ping tristan about it.
+>  >
+>  > On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+>  > > hi
+>  > > Just starting out so I'm trying to run cowboy's helloworld
+>  > > in cowboy/examples/hello_world, running make fails with:
+>  > >
+>  > > ===> Provider (rlx_prv_discover) failed with: {error,
+>  > >
+>  {rlx_app_discovery,
+>  > >
+> [{missing_beam_file,
+>  > >                                                           hipe,
+>  > >
+>  > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+>  > >
+>  {missing_beam_file,
+>  > >                                                           hipe,
+>  > >
+>  > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+>  > >
+>  > > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/,
+> it
+>  > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+>  > > I've tried passing the correct dir to relx using --lib-dir but I still
+>  > > get the same error.
+>  > >
+>  > > Any ideas what's going wrong?
+>  > >
+>  > > erl: Erlang R16B02 (erts-5.10.3)
+>  > > relx: 0.0.0+build.275.refca03701
+>  > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git
+> 2.1.0-pre-46-g78fa8fc
+>  > >
+>  > >
+>  > > On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com
+>  > > <mailto:mrhegarty at gmail.com>> wrote:
+>  > >
+>  > >     hi
+>  > >     Just starting out so I've got latest versions of apps.
+>  > >     in cowboy/examples/hello_world, running make fails with:
+>  > >
+>  > >
+>  > >
+>  > >
+>  > >
+>  > >
+>  > > _______________________________________________
+>  > > Extend mailing list
+>  > > Extend at lists.ninenines.eu
+>  > > http://lists.ninenines.eu:81/listinfo/extend
+>  > >
+>  >
+>  >
+>  > --
+>  > Loïc Hoguin
+>
+> > Erlang Cowboy
+>  > Nine Nines
+>  > http://ninenines.eu
+> > _______________________________________________
+>  > Extend mailing list
+>  > Extend at lists.ninenines.eu
+>  > http://lists.ninenines.eu:81/listinfo/extend
+>
+>
+>  --
+>    Tristan Sloughter
+>    tristan.sloughter at gmail.com
+>
+>
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130926/3a77fe04/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000253.html b/_build/static/archives/extend/2013-September/000253.html new file mode 100644 index 00000000..168be8bc --- /dev/null +++ b/_build/static/archives/extend/2013-September/000253.html @@ -0,0 +1,210 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Matthew Hegarty + mrhegarty at gmail.com +
+ Sat Sep 28 22:41:16 CEST 2013 +

+
+ +
Got it to work.  I apparently had a few versions of hipe in my Erlang lib
+dir:
+
+$ /usr/local/lib/erlang/lib $ ll -ld hipe*
+drwxr-xr-x  9 root root 4096 Feb 11  2013 hipe-3.10/
+drwxr-xr-x  9 root root 4096 Mar  1  2013 hipe-3.10.1/
+drwxr-xr-x 10 root root 4096 Jul  2 11:31 hipe-3.10.2/
+drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/
+
+They must have come from previous erlang installations (compilation from
+source).  The solution was to remove the older versions and leave only the
+latest one.  Maybe relx should be able to handle this?
+
+thanks for the responses
+
+Matt
+
+
+On 26 September 2013 21:36, Matthew Hegarty <mrhegarty at gmail.com> wrote:
+
+> yes it exists.  I believe hipe is enabled by default when I compile.
+>
+> however there is no
+>
+>  /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam
+>  /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam
+>
+> which is what relx is apparently looking for.
+> Do you know where does relx get these paths from?
+>
+>
+> On 26 September 2013 20:04, Tristan Sloughter <tristan.sloughter at gmail.com
+> > wrote:
+>
+>> **
+>> Did you enable hipe when you compiled? Does
+>> /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?
+>>
+>> --
+>>  Tristan Sloughter
+>>  tristan.sloughter at gmail.com
+>>
+>>
+>>
+>> On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:
+>>
+>> hi
+>> I compiled Erlang from source (downloaded from erlang.org)
+>>
+>>
+>> On 25 September 2013 17:25, Tristan Sloughter <
+>> tristan.sloughter at gmail.com> wrote:
+>>
+>>
+>> I ran into the same thing. I assume you installed Erlang from the Erlang
+>>  Solutions repo?
+>>
+>>  Install erlang-hipe package. Or remove
+>>  /usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+>>
+>>  Their packages install a broken hipe app, missing lots of beams, for
+>>  some reason. But if you install the hipe package it'll install what is
+>>  missing. I told them about this but I haven't heard back.
+>>
+>>  --
+>>    Tristan Sloughter
+>>    tsloughter at fastmail.fm
+>>
+>>
+>>  On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+>>  > Why does it look for hipe at all to begin with?
+>>  >
+>>  > I'll ping tristan about it.
+>>  >
+>>  > On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+>>  > > hi
+>>  > > Just starting out so I'm trying to run cowboy's helloworld
+>>  > > in cowboy/examples/hello_world, running make fails with:
+>>  > >
+>>  > > ===> Provider (rlx_prv_discover) failed with: {error,
+>>  > >
+>>  {rlx_app_discovery,
+>>  > >
+>> [{missing_beam_file,
+>>  > >                                                           hipe,
+>>  > >
+>>  > > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+>>  > >
+>>  {missing_beam_file,
+>>  > >                                                           hipe,
+>>  > >
+>>  > > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+>>  > >
+>>  > > there is no hipe.beam in
+>> /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it
+>>  > > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+>>  > > I've tried passing the correct dir to relx using --lib-dir but I
+>> still
+>>  > > get the same error.
+>>  > >
+>>  > > Any ideas what's going wrong?
+>>  > >
+>>  > > erl: Erlang R16B02 (erts-5.10.3)
+>>  > > relx: 0.0.0+build.275.refca03701
+>>  > > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git
+>> 2.1.0-pre-46-g78fa8fc
+>>  > >
+>>  > >
+>>  > > On 22 September 2013 21:55, Matthew Hegarty <mrhegarty at gmail.com
+>>  > > <mailto:mrhegarty at gmail.com>> wrote:
+>>  > >
+>>  > >     hi
+>>  > >     Just starting out so I've got latest versions of apps.
+>>  > >     in cowboy/examples/hello_world, running make fails with:
+>>  > >
+>>  > >
+>>  > >
+>>  > >
+>>  > >
+>>  > >
+>>  > > _______________________________________________
+>>  > > Extend mailing list
+>>  > > Extend at lists.ninenines.eu
+>>  > > http://lists.ninenines.eu:81/listinfo/extend
+>>  > >
+>>  >
+>>  >
+>>  > --
+>>  > Loïc Hoguin
+>>
+>> > Erlang Cowboy
+>>  > Nine Nines
+>>  > http://ninenines.eu
+>> > _______________________________________________
+>>  > Extend mailing list
+>>  > Extend at lists.ninenines.eu
+>>  > http://lists.ninenines.eu:81/listinfo/extend
+>>
+>>
+>>  --
+>>    Tristan Sloughter
+>>    tristan.sloughter at gmail.com
+>>
+>>
+>>
+>>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130928/b1333ac2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/000254.html b/_build/static/archives/extend/2013-September/000254.html new file mode 100644 index 00000000..9e3ffb6a --- /dev/null +++ b/_build/static/archives/extend/2013-September/000254.html @@ -0,0 +1,269 @@ + + + + [99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe) + + + + + + + + + + +

[99s-extend] Cowboy helloworld make fails with missing_beam_file (hipe)

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Sat Sep 28 22:43:25 CEST 2013 +

+
+ +
Yea, since I doubt the OTP team (or anyone) will fix the fact that it
+installs a broken hipe we've decided to just warn on broken apps during
+the discovery phase. So it'll only fail if the broken app is also
+suppose to be part of the release.
+
+
+
+Finishing up the relx patch right now.
+
+
+
+--
+Tristan Sloughter
+tristan.sloughter at gmail.com
+
+
+
+
+
+On Sat, Sep 28, 2013, at 01:41 PM, Matthew Hegarty wrote:
+
+Got it to work.  I apparently had a few versions of hipe in my Erlang
+lib dir:
+
+$ /usr/local/lib/erlang/lib $ ll -ld hipe*
+drwxr-xr-x  9 root root 4096 Feb 11  2013 hipe-3.10/
+drwxr-xr-x  9 root root 4096 Mar  1  2013 hipe-3.10.1/
+drwxr-xr-x 10 root root 4096 Jul  2 11:31 hipe-3.10.2/
+drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/
+
+They must have come from previous erlang installations (compilation
+from source).  The solution was to remove the older versions and leave
+only the latest one.  Maybe relx should be able to handle this?
+
+thanks for the responses
+
+Matt
+
+
+
+On 26 September 2013 21:36, Matthew Hegarty <[1]mrhegarty at gmail.com>
+wrote:
+
+yes it exists.  I believe hipe is enabled by default when I compile.
+
+however there is no
+
+ /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam
+ /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam
+
+which is what relx is apparently looking for.
+Do you know where does relx get these paths from?
+
+
+
+On 26 September 2013 20:04, Tristan Sloughter
+<[2]tristan.sloughter at gmail.com> wrote:
+
+Did you enable hipe when you compiled? Does
+/usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?
+
+--
+Tristan Sloughter
+[3]tristan.sloughter at gmail.com
+
+
+
+On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:
+
+hi
+
+I compiled Erlang from source (downloaded from [4]erlang.org)
+
+
+
+On 25 September 2013 17:25, Tristan Sloughter
+<[5]tristan.sloughter at gmail.com> wrote:
+
+I ran into the same thing. I assume you installed Erlang from the
+Erlang
+
+Solutions repo?
+
+
+
+Install erlang-hipe package. Or remove
+
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.
+
+
+
+Their packages install a broken hipe app, missing lots of beams, for
+
+some reason. But if you install the hipe package it'll install what is
+
+missing. I told them about this but I haven't heard back.
+
+
+
+--
+
+  Tristan Sloughter
+
+  [6]tsloughter at fastmail.fm
+
+
+
+
+On Wed, Sep 25, 2013, at 08:09 AM, Loïc Hoguin wrote:
+> Why does it look for hipe at all to begin with?
+>
+> I'll ping tristan about it.
+>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:
+> > hi
+> > Just starting out so I'm trying to run cowboy's helloworld
+> > in cowboy/examples/hello_world, running make fails with:
+> >
+> > ===> Provider (rlx_prv_discover) failed with: {error,
+> >
+{rlx_app_discovery,
+> >
+[{missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},
+> >
+{missing_beam_file,
+> >                                                           hipe,
+> >
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}
+> >
+> > there is no hipe.beam in
+/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.
+> > I've tried passing the correct dir to relx using --lib-dir but I
+still
+> > get the same error.
+> >
+> > Any ideas what's going wrong?
+> >
+> > erl: Erlang R16B02 (erts-5.10.3)
+> > relx: 0.0.0+build.275.refca03701
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git
+2.1.0-pre-46-g78fa8fc
+> >
+> >
+> > On 22 September 2013 21:55, Matthew Hegarty <[7]mrhegarty at gmail.com
+> > <mailto:[8]mrhegarty at gmail.com>> wrote:
+> >
+> >     hi
+> >     Just starting out so I've got latest versions of apps.
+> >     in cowboy/examples/hello_world, running make fails with:
+> >
+> >
+> >
+> >
+> >
+> >
+> > _______________________________________________
+> > Extend mailing list
+> > [9]Extend at lists.ninenines.eu
+> > [10]http://lists.ninenines.eu:81/listinfo/extend
+> >
+>
+>
+> --
+
+> Loïc Hoguin
+
+
+
+> Erlang Cowboy
+
+> Nine Nines
+
+> [11]http://ninenines.eu
+
+> _______________________________________________
+> Extend mailing list
+> [12]Extend at lists.ninenines.eu
+> [13]http://lists.ninenines.eu:81/listinfo/extend
+
+
+--
+
+  Tristan Sloughter
+
+  [14]tristan.sloughter at gmail.com
+
+References
+
+1. mailto:mrhegarty at gmail.com
+2. mailto:tristan.sloughter at gmail.com
+3. mailto:tristan.sloughter at gmail.com
+4. http://erlang.org/
+5. mailto:tristan.sloughter at gmail.com
+6. mailto:tsloughter at fastmail.fm
+7. mailto:mrhegarty at gmail.com
+8. mailto:mrhegarty at gmail.com
+9. mailto:Extend at lists.ninenines.eu
+  10. http://lists.ninenines.eu:81/listinfo/extend
+  11. http://ninenines.eu/
+  12. mailto:Extend at lists.ninenines.eu
+  13. http://lists.ninenines.eu:81/listinfo/extend
+  14. mailto:tristan.sloughter at gmail.com
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20130928/41b322fd/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2013-September/author.html b/_build/static/archives/extend/2013-September/author.html new file mode 100644 index 00000000..97404d5d --- /dev/null +++ b/_build/static/archives/extend/2013-September/author.html @@ -0,0 +1,187 @@ + + + + The Extend September 2013 Archive by author + + + + + +

September 2013 Archives by author

+ +

Starting: Sun Sep 15 19:01:30 CEST 2013
+ Ending: Sat Sep 28 22:43:25 CEST 2013
+ Messages: 28

+

+

+ Last message date: + Sat Sep 28 22:43:25 CEST 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-September/date.html b/_build/static/archives/extend/2013-September/date.html new file mode 100644 index 00000000..ccbd2574 --- /dev/null +++ b/_build/static/archives/extend/2013-September/date.html @@ -0,0 +1,187 @@ + + + + The Extend September 2013 Archive by date + + + + + +

September 2013 Archives by date

+ +

Starting: Sun Sep 15 19:01:30 CEST 2013
+ Ending: Sat Sep 28 22:43:25 CEST 2013
+ Messages: 28

+

+

+ Last message date: + Sat Sep 28 22:43:25 CEST 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-September/index.html b/_build/static/archives/extend/2013-September/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2013-September/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2013-September/subject.html b/_build/static/archives/extend/2013-September/subject.html new file mode 100644 index 00000000..835ec2ec --- /dev/null +++ b/_build/static/archives/extend/2013-September/subject.html @@ -0,0 +1,187 @@ + + + + The Extend September 2013 Archive by subject + + + + + +

September 2013 Archives by subject

+ +

Starting: Sun Sep 15 19:01:30 CEST 2013
+ Ending: Sat Sep 28 22:43:25 CEST 2013
+ Messages: 28

+

+

+ Last message date: + Sat Sep 28 22:43:25 CEST 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2013-September/thread.html b/_build/static/archives/extend/2013-September/thread.html new file mode 100644 index 00000000..8366d4d0 --- /dev/null +++ b/_build/static/archives/extend/2013-September/thread.html @@ -0,0 +1,243 @@ + + + + The Extend September 2013 Archive by thread + + + + + +

September 2013 Archives by thread

+ +

Starting: Sun Sep 15 19:01:30 CEST 2013
+ Ending: Sat Sep 28 22:43:25 CEST 2013
+ Messages: 28

+

+

+ Last message date: + Sat Sep 28 22:43:25 CEST 2013
+ Archived on: Wed May 28 18:41:45 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-April.txt b/_build/static/archives/extend/2014-April.txt new file mode 100644 index 00000000..7118b8ac --- /dev/null +++ b/_build/static/archives/extend/2014-April.txt @@ -0,0 +1,943 @@ +From essen at ninenines.eu Tue Apr 8 11:11:07 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 08 Apr 2014 11:11:07 +0200 +Subject: [99s-extend] Closing the mailing lists later this week +Message-ID: <5343BD2B.1070400@ninenines.eu> + +Hello, + +I will be closing the mailing lists later this week. Preferred medium +for getting help will be opening tickets on github (if you can't figure +something out, then it's a bug!) or IRC. + +If you would like to continue helping users, then hop on IRC or follow +the projects on github and answer tickets. Thank you. + +Announcements will probably be made using the website's articles page +instead of here. + +The archives will be moved to git for safekeeping, but everything else +will be deleted, including user data and backups. + +Thanks for your understanding, + +-- +Lo?c Hoguin +http://ninenines.eu + + +From samset at wanadoo.fr Wed Apr 9 16:52:47 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Wed, 9 Apr 2014 16:52:47 +0200 +Subject: [99s-extend] REST handler with ssl support +Message-ID: + +Hi, + +I?d like to secure my rest api with an ssl transport. +Could not find any example to do so ? + +Any clue ? + +Thank you. + +Samir + +From samset at wanadoo.fr Fri Apr 11 12:39:13 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 11 Apr 2014 12:39:13 +0200 +Subject: [99s-extend] ssl_hello_world +Message-ID: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> + +Hi, + +Still struggling to make ssl work. + +I downloaded the example ssl_hello_world. +Upon execution : i get the following error with curl + + About to connect() to localhost port 8443 (#0) +* Trying ::1... Connexion refus?e +* Trying 127.0.0.1... connected +* Connected to localhost (127.0.0.1) port 8443 (#0) +* Initializing NSS with certpath: sql:/etc/pki/nssdb +* NSS error -8018 +* Closing connection #0 +* Problem with the SSL CA cert (path? access rights?) +curl: (77) Problem with the SSL CA cert (path? access rights?) + + +cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ + +cacert path checked. +read permission checked + +I?ve tested with a browser and get a connection error. + +Any clue ? + +Samir + + + + +From essen at ninenines.eu Fri Apr 11 13:18:56 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 11 Apr 2014 13:18:56 +0200 +Subject: [99s-extend] ssl_hello_world +In-Reply-To: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> +References: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> +Message-ID: <5347CFA0.9070907@ninenines.eu> + +The certificate in the SSL example is self-generated, try curl with the +--insecure option. + +On 04/11/2014 12:39 PM, Samir Sow wrote: +> Hi, +> +> Still struggling to make ssl work. +> +> I downloaded the example ssl_hello_world. +> Upon execution : i get the following error with curl +> +> About to connect() to localhost port 8443 (#0) +> * Trying ::1... Connexion refus?e +> * Trying 127.0.0.1... connected +> * Connected to localhost (127.0.0.1) port 8443 (#0) +> * Initializing NSS with certpath: sql:/etc/pki/nssdb +> * NSS error -8018 +> * Closing connection #0 +> * Problem with the SSL CA cert (path? access rights?) +> curl: (77) Problem with the SSL CA cert (path? access rights?) +> +> +> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ +> +> cacert path checked. +> read permission checked +> +> I?ve tested with a browser and get a connection error. +> +> Any clue ? +> +> Samir +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From samset at wanadoo.fr Fri Apr 11 13:25:51 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 11 Apr 2014 13:25:51 +0200 +Subject: [99s-extend] ssl_hello_world +In-Reply-To: <5347CFA0.9070907@ninenines.eu> +References: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> + <5347CFA0.9070907@ninenines.eu> +Message-ID: <352B535C-4C7E-41FB-86F1-02D48226BF50@wanadoo.fr> + +Thx. + +Same error ? +Openssl s_client does not work either. +the server does not answer to ClientHello ? + +Samir + +On 11 avr. 2014, at 13:18, Lo?c Hoguin wrote: + +> The certificate in the SSL example is self-generated, try curl with the --insecure option. +> +> On 04/11/2014 12:39 PM, Samir Sow wrote: +>> Hi, +>> +>> Still struggling to make ssl work. +>> +>> I downloaded the example ssl_hello_world. +>> Upon execution : i get the following error with curl +>> +>> About to connect() to localhost port 8443 (#0) +>> * Trying ::1... Connexion refus?e +>> * Trying 127.0.0.1... connected +>> * Connected to localhost (127.0.0.1) port 8443 (#0) +>> * Initializing NSS with certpath: sql:/etc/pki/nssdb +>> * NSS error -8018 +>> * Closing connection #0 +>> * Problem with the SSL CA cert (path? access rights?) +>> curl: (77) Problem with the SSL CA cert (path? access rights?) +>> +>> +>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ +>> +>> cacert path checked. +>> read permission checked +>> +>> I?ve tested with a browser and get a connection error. +>> +>> Any clue ? +>> +>> Samir +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + + +From essen at ninenines.eu Fri Apr 11 13:41:29 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 11 Apr 2014 13:41:29 +0200 +Subject: [99s-extend] ssl_hello_world +In-Reply-To: <352B535C-4C7E-41FB-86F1-02D48226BF50@wanadoo.fr> +References: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> + <5347CFA0.9070907@ninenines.eu> + <352B535C-4C7E-41FB-86F1-02D48226BF50@wanadoo.fr> +Message-ID: <5347D4E9.10005@ninenines.eu> + +This is the successful output I get. You should try to see why yours is +different, perhaps someone somewhere ran into the same issue at some +point. Note that the --cacert option isn't needed and basically makes no +difference. + + +% curl -ikvv https://localhost:8443 +* Rebuilt URL to: https://localhost:8443/ +* Hostname was NOT found in DNS cache +* Trying 127.0.0.1... +* Connected to localhost (127.0.0.1) port 8443 (#0) +* successfully set certificate verify locations: +* CAfile: /etc/ssl/certs/ca-certificates.crt + CApath: none +* SSLv3, TLS handshake, Client hello (1): +* SSLv3, TLS handshake, Server hello (2): +* SSLv3, TLS handshake, CERT (11): +* SSLv3, TLS handshake, Server key exchange (12): +* SSLv3, TLS handshake, Server finished (14): +* SSLv3, TLS handshake, Client key exchange (16): +* SSLv3, TLS change cipher, Client hello (1): +* SSLv3, TLS handshake, Finished (20): +* SSLv3, TLS change cipher, Client hello (1): +* SSLv3, TLS handshake, Finished (20): +* SSL connection using ECDHE-RSA-AES256-SHA384 +* Server certificate: +* subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost +* start date: 2013-02-28 05:23:34 GMT +* expire date: 2033-02-23 05:23:34 GMT +* issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA +* SSL certificate verify result: self signed certificate in +certificate chain (19), continuing anyway. + > GET / HTTP/1.1 + > User-Agent: curl/7.35.0 + > Host: localhost:8443 + > Accept: */* + > +< HTTP/1.1 200 OK +HTTP/1.1 200 OK +< connection: keep-alive +connection: keep-alive +* Server Cowboy is not blacklisted +< server: Cowboy +server: Cowboy +< date: Fri, 11 Apr 2014 11:30:03 GMT +date: Fri, 11 Apr 2014 11:30:03 GMT +< content-length: 12 +content-length: 12 +< content-type: text/plain +content-type: text/plain + +< + + +On 04/11/2014 01:25 PM, Samir Sow wrote: +> Thx. +> +> Same error ? +> Openssl s_client does not work either. +> the server does not answer to ClientHello ? +> +> Samir +> +> On 11 avr. 2014, at 13:18, Lo?c Hoguin wrote: +> +>> The certificate in the SSL example is self-generated, try curl with the --insecure option. +>> +>> On 04/11/2014 12:39 PM, Samir Sow wrote: +>>> Hi, +>>> +>>> Still struggling to make ssl work. +>>> +>>> I downloaded the example ssl_hello_world. +>>> Upon execution : i get the following error with curl +>>> +>>> About to connect() to localhost port 8443 (#0) +>>> * Trying ::1... Connexion refus?e +>>> * Trying 127.0.0.1... connected +>>> * Connected to localhost (127.0.0.1) port 8443 (#0) +>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb +>>> * NSS error -8018 +>>> * Closing connection #0 +>>> * Problem with the SSL CA cert (path? access rights?) +>>> curl: (77) Problem with the SSL CA cert (path? access rights?) +>>> +>>> +>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ +>>> +>>> cacert path checked. +>>> read permission checked +>>> +>>> I?ve tested with a browser and get a connection error. +>>> +>>> Any clue ? +>>> +>>> Samir +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From samset at wanadoo.fr Fri Apr 11 13:48:41 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 11 Apr 2014 13:48:41 +0200 +Subject: [99s-extend] ssl_hello_world +In-Reply-To: <5347D4E9.10005@ninenines.eu> +References: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> + <5347CFA0.9070907@ninenines.eu> + <352B535C-4C7E-41FB-86F1-02D48226BF50@wanadoo.fr> + <5347D4E9.10005@ninenines.eu> +Message-ID: + +Thx. + +On which OS + Erlang version is the server running ? + +Samir +On 11 avr. 2014, at 13:41, Lo?c Hoguin wrote: + +> This is the successful output I get. You should try to see why yours is different, perhaps someone somewhere ran into the same issue at some point. Note that the --cacert option isn't needed and basically makes no difference. +> +> +> % curl -ikvv https://localhost:8443 +> * Rebuilt URL to: https://localhost:8443/ +> * Hostname was NOT found in DNS cache +> * Trying 127.0.0.1... +> * Connected to localhost (127.0.0.1) port 8443 (#0) +> * successfully set certificate verify locations: +> * CAfile: /etc/ssl/certs/ca-certificates.crt +> CApath: none +> * SSLv3, TLS handshake, Client hello (1): +> * SSLv3, TLS handshake, Server hello (2): +> * SSLv3, TLS handshake, CERT (11): +> * SSLv3, TLS handshake, Server key exchange (12): +> * SSLv3, TLS handshake, Server finished (14): +> * SSLv3, TLS handshake, Client key exchange (16): +> * SSLv3, TLS change cipher, Client hello (1): +> * SSLv3, TLS handshake, Finished (20): +> * SSLv3, TLS change cipher, Client hello (1): +> * SSLv3, TLS handshake, Finished (20): +> * SSL connection using ECDHE-RSA-AES256-SHA384 +> * Server certificate: +> * subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost +> * start date: 2013-02-28 05:23:34 GMT +> * expire date: 2033-02-23 05:23:34 GMT +> * issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA +> * SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. +> > GET / HTTP/1.1 +> > User-Agent: curl/7.35.0 +> > Host: localhost:8443 +> > Accept: */* +> > +> < HTTP/1.1 200 OK +> HTTP/1.1 200 OK +> < connection: keep-alive +> connection: keep-alive +> * Server Cowboy is not blacklisted +> < server: Cowboy +> server: Cowboy +> < date: Fri, 11 Apr 2014 11:30:03 GMT +> date: Fri, 11 Apr 2014 11:30:03 GMT +> < content-length: 12 +> content-length: 12 +> < content-type: text/plain +> content-type: text/plain +> +> < +> +> +> On 04/11/2014 01:25 PM, Samir Sow wrote: +>> Thx. +>> +>> Same error ? +>> Openssl s_client does not work either. +>> the server does not answer to ClientHello ? +>> +>> Samir +>> +>> On 11 avr. 2014, at 13:18, Lo?c Hoguin wrote: +>> +>>> The certificate in the SSL example is self-generated, try curl with the --insecure option. +>>> +>>> On 04/11/2014 12:39 PM, Samir Sow wrote: +>>>> Hi, +>>>> +>>>> Still struggling to make ssl work. +>>>> +>>>> I downloaded the example ssl_hello_world. +>>>> Upon execution : i get the following error with curl +>>>> +>>>> About to connect() to localhost port 8443 (#0) +>>>> * Trying ::1... Connexion refus?e +>>>> * Trying 127.0.0.1... connected +>>>> * Connected to localhost (127.0.0.1) port 8443 (#0) +>>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb +>>>> * NSS error -8018 +>>>> * Closing connection #0 +>>>> * Problem with the SSL CA cert (path? access rights?) +>>>> curl: (77) Problem with the SSL CA cert (path? access rights?) +>>>> +>>>> +>>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ +>>>> +>>>> cacert path checked. +>>>> read permission checked +>>>> +>>>> I?ve tested with a browser and get a connection error. +>>>> +>>>> Any clue ? +>>>> +>>>> Samir +>>>> +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + + +From essen at ninenines.eu Fri Apr 11 13:57:59 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 11 Apr 2014 13:57:59 +0200 +Subject: [99s-extend] ssl_hello_world +In-Reply-To: +References: <8FB12862-814C-45A2-8E0D-6328CFDF8370@wanadoo.fr> + <5347CFA0.9070907@ninenines.eu> + <352B535C-4C7E-41FB-86F1-02D48226BF50@wanadoo.fr> + <5347D4E9.10005@ninenines.eu> + +Message-ID: <5347D8C7.8020906@ninenines.eu> + +It's tested on ArchLinux from R15B01 to master so that's unrelated to +the Erlang version. + +On 04/11/2014 01:48 PM, Samir Sow wrote: +> Thx. +> +> On which OS + Erlang version is the server running ? +> +> Samir +> On 11 avr. 2014, at 13:41, Lo?c Hoguin wrote: +> +>> This is the successful output I get. You should try to see why yours is different, perhaps someone somewhere ran into the same issue at some point. Note that the --cacert option isn't needed and basically makes no difference. +>> +>> +>> % curl -ikvv https://localhost:8443 +>> * Rebuilt URL to: https://localhost:8443/ +>> * Hostname was NOT found in DNS cache +>> * Trying 127.0.0.1... +>> * Connected to localhost (127.0.0.1) port 8443 (#0) +>> * successfully set certificate verify locations: +>> * CAfile: /etc/ssl/certs/ca-certificates.crt +>> CApath: none +>> * SSLv3, TLS handshake, Client hello (1): +>> * SSLv3, TLS handshake, Server hello (2): +>> * SSLv3, TLS handshake, CERT (11): +>> * SSLv3, TLS handshake, Server key exchange (12): +>> * SSLv3, TLS handshake, Server finished (14): +>> * SSLv3, TLS handshake, Client key exchange (16): +>> * SSLv3, TLS change cipher, Client hello (1): +>> * SSLv3, TLS handshake, Finished (20): +>> * SSLv3, TLS change cipher, Client hello (1): +>> * SSLv3, TLS handshake, Finished (20): +>> * SSL connection using ECDHE-RSA-AES256-SHA384 +>> * Server certificate: +>> * subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost +>> * start date: 2013-02-28 05:23:34 GMT +>> * expire date: 2033-02-23 05:23:34 GMT +>> * issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA +>> * SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway. +>>> GET / HTTP/1.1 +>>> User-Agent: curl/7.35.0 +>>> Host: localhost:8443 +>>> Accept: */* +>>> +>> < HTTP/1.1 200 OK +>> HTTP/1.1 200 OK +>> < connection: keep-alive +>> connection: keep-alive +>> * Server Cowboy is not blacklisted +>> < server: Cowboy +>> server: Cowboy +>> < date: Fri, 11 Apr 2014 11:30:03 GMT +>> date: Fri, 11 Apr 2014 11:30:03 GMT +>> < content-length: 12 +>> content-length: 12 +>> < content-type: text/plain +>> content-type: text/plain +>> +>> < +>> +>> +>> On 04/11/2014 01:25 PM, Samir Sow wrote: +>>> Thx. +>>> +>>> Same error ? +>>> Openssl s_client does not work either. +>>> the server does not answer to ClientHello ? +>>> +>>> Samir +>>> +>>> On 11 avr. 2014, at 13:18, Lo?c Hoguin wrote: +>>> +>>>> The certificate in the SSL example is self-generated, try curl with the --insecure option. +>>>> +>>>> On 04/11/2014 12:39 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> Still struggling to make ssl work. +>>>>> +>>>>> I downloaded the example ssl_hello_world. +>>>>> Upon execution : i get the following error with curl +>>>>> +>>>>> About to connect() to localhost port 8443 (#0) +>>>>> * Trying ::1... Connexion refus?e +>>>>> * Trying 127.0.0.1... connected +>>>>> * Connected to localhost (127.0.0.1) port 8443 (#0) +>>>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb +>>>>> * NSS error -8018 +>>>>> * Closing connection #0 +>>>>> * Problem with the SSL CA cert (path? access rights?) +>>>>> curl: (77) Problem with the SSL CA cert (path? access rights?) +>>>>> +>>>>> +>>>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/ +>>>>> +>>>>> cacert path checked. +>>>>> read permission checked +>>>>> +>>>>> I?ve tested with a browser and get a connection error. +>>>>> +>>>>> Any clue ? +>>>>> +>>>>> Samir +>>>>> +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From samset at wanadoo.fr Fri Apr 11 23:23:10 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 11 Apr 2014 23:23:10 +0200 +Subject: [99s-extend] ssl +Message-ID: <0C585951-B0F1-458F-8ED9-971980FC1FE6@wanadoo.fr> + +Hi, + +Still struggling with ssl. +I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. +Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. + +Any help welcomed. Thx + +Samir + +{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). +** exception exit: {{badarg, + [{erlang,size, + [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, + 58,145,197,219|...]], + []}, + {tls_record,get_tls_records_aux,2, + [{file,"tls_record.erl"},{line,122}]}, + {tls_connection,next_tls_record,2, + [{file,"tls_connection.erl"},{line,484}]}, + {tls_connection,handle_info,3, + [{file,"tls_connection.erl"},{line,307}]}, + {gen_fsm,handle_msg,7, + [{file,"gen_fsm.erl"},{line,503}]}, + {proc_lib,init_p_do_apply,3, + [{file,"proc_lib.erl"},{line,239}]}]}, + {gen_fsm,sync_send_all_state_event, + [<0.105.0>,{start,infinity},infinity]}} + in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) + in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) + in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) + in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) + in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) + +From essen at ninenines.eu Fri Apr 11 23:31:36 2014 +From: essen at ninenines.eu (=?ISO-8859-1?Q?Lo=EFc_Hoguin?=) +Date: Fri, 11 Apr 2014 23:31:36 +0200 +Subject: [99s-extend] ssl +Message-ID: + +Please report it to erlang-bugs, you'll get better help with ssl bugs there. + +-- +Lo?c Hoguin +http://ninenines.eu + +-------- Original Message -------- +From:Samir Sow +Sent:Fri, 11 Apr 2014 23:23:10 +0200 +To:extend at lists.ninenines.eu +Subject:[99s-extend] ssl + +>Hi, +> +>Still struggling with ssl. +>I decided to check what?s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc. +>Found an error erlang:size badarg, but could not understand if it?s a problem with the key/cert files or with the data sent by the client. +> +>Any help welcomed. Thx +> +>Samir +> +>{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]). +>** exception exit: {{badarg, +> [{erlang,size, +> [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175, +> 58,145,197,219|...]], +> []}, +> {tls_record,get_tls_records_aux,2, +> [{file,"tls_record.erl"},{line,122}]}, +> {tls_connection,next_tls_record,2, +> [{file,"tls_connection.erl"},{line,484}]}, +> {tls_connection,handle_info,3, +> [{file,"tls_connection.erl"},{line,307}]}, +> {gen_fsm,handle_msg,7, +> [{file,"gen_fsm.erl"},{line,503}]}, +> {proc_lib,init_p_do_apply,3, +> [{file,"proc_lib.erl"},{line,239}]}]}, +> {gen_fsm,sync_send_all_state_event, +> [<0.105.0>,{start,infinity},infinity]}} +> in function gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242) +> in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649) +> in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97) +> in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81) +> in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84) +>_______________________________________________ +>Extend mailing list +>Extend at lists.ninenines.eu +>https://lists.ninenines.eu/listinfo/extend +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ka.gemayel at gmail.com Sun Apr 20 19:46:55 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Sun, 20 Apr 2014 19:46:55 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +Message-ID: <5354080F.6030001@gmail.com> + +Hello, + +Writing a Cowboy (0.9.0) Websocket server (running on Ubuntu 12.04 ; +Erlang R16B03), it works fine on Firefox Desktop but fails on Firefox +Android (28.0.1). + +When testing with the websocket_example, on client-side Websockets are +detected but nothing happens then, no connection seems to be initiated ; +and on server-side, despite having traces in all functions of +ws_handler.erl, nothing appears in the console. + +However when testing http://www.websocket.org/echo.html with Firefox +Android, it works. + +So before going for remote debugging Firefox, I was looking for similar +cases using Cowboy Websocket with Firefox Android. Is there a JavaScript +tip to manage Websocket connection in that case ? Am I missing something ? + +Thanks. + +-- +Karim Gemayel + + +From essen at ninenines.eu Sun Apr 20 19:50:07 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sun, 20 Apr 2014 19:50:07 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +In-Reply-To: <5354080F.6030001@gmail.com> +References: <5354080F.6030001@gmail.com> +Message-ID: <535408CF.4050809@ninenines.eu> + +Try tracing the cowboy_websocket module? + +On 04/20/2014 07:46 PM, Karim Gemayel wrote: +> Hello, +> +> Writing a Cowboy (0.9.0) Websocket server (running on Ubuntu 12.04 ; +> Erlang R16B03), it works fine on Firefox Desktop but fails on Firefox +> Android (28.0.1). +> +> When testing with the websocket_example, on client-side Websockets are +> detected but nothing happens then, no connection seems to be initiated ; +> and on server-side, despite having traces in all functions of +> ws_handler.erl, nothing appears in the console. +> +> However when testing http://www.websocket.org/echo.html with Firefox +> Android, it works. +> +> So before going for remote debugging Firefox, I was looking for similar +> cases using Cowboy Websocket with Firefox Android. Is there a JavaScript +> tip to manage Websocket connection in that case ? Am I missing something ? +> +> Thanks. +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From ka.gemayel at gmail.com Sun Apr 20 20:28:16 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Sun, 20 Apr 2014 20:28:16 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +In-Reply-To: <535408CF.4050809@ninenines.eu> +References: <5354080F.6030001@gmail.com> <535408CF.4050809@ninenines.eu> +Message-ID: <535411C0.1020102@gmail.com> + +On 04/20/2014 07:50 PM, Lo?c Hoguin wrote: +> Try tracing the cowboy_websocket module? + +The same case happens, no logs at all from Android whereas logs appear +from Desktop. + +I've attached the traces diffs. + +-- +Karim Gemayel +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: cowboy_websocket.diff +Type: text/x-patch +Size: 5780 bytes +Desc: not available +URL: +-------------- next part -------------- +A non-text attachment was scrubbed... +Name: websocket_example.diff +Type: text/x-patch +Size: 2413 bytes +Desc: not available +URL: + +From essen at ninenines.eu Sun Apr 20 20:30:55 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sun, 20 Apr 2014 20:30:55 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +In-Reply-To: <535411C0.1020102@gmail.com> +References: <5354080F.6030001@gmail.com> <535408CF.4050809@ninenines.eu> + <535411C0.1020102@gmail.com> +Message-ID: <5354125F.9040603@ninenines.eu> + +You really should take a look at tracing using dbg at some point. :-) + +But yeah if you don't get the upgrade function output and you are +testing against the Websocket example then I doubt the request even +reaches the server. + +As for why, I have no idea. + +On 04/20/2014 08:28 PM, Karim Gemayel wrote: +> On 04/20/2014 07:50 PM, Lo?c Hoguin wrote: +>> Try tracing the cowboy_websocket module? +> +> The same case happens, no logs at all from Android whereas logs appear +> from Desktop. +> +> I've attached the traces diffs. +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From ka.gemayel at gmail.com Sun Apr 20 20:49:34 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Sun, 20 Apr 2014 20:49:34 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +In-Reply-To: <5354125F.9040603@ninenines.eu> +References: <5354080F.6030001@gmail.com> <535408CF.4050809@ninenines.eu> + <535411C0.1020102@gmail.com> <5354125F.9040603@ninenines.eu> +Message-ID: <535416BE.3030901@gmail.com> + +On 04/20/2014 08:30 PM, Lo?c Hoguin wrote: +> You really should take a look at tracing using dbg at some point. :-) + +Yes, true. Actually, dbg is on my to-learn list. :) + +> But yeah if you don't get the upgrade function output and you are +> testing against the Websocket example then I doubt the request even +> reaches the server. +> +> As for why, I have no idea. + +That's a bit frustrating because the app is supposed to be used +primarily on mobile, so it seems I have to implement an HTTP fallback +that I didn't want to implement. + +I'll have to go for Firefox remote debugging, so. + +Thanks anyway. + +-- +Karim Gemayel + + +From ka.gemayel at gmail.com Sun Apr 20 22:47:08 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Sun, 20 Apr 2014 22:47:08 +0200 +Subject: [99s-extend] [cowboy] Websocket with Firefox Android +In-Reply-To: <535416BE.3030901@gmail.com> +References: <5354080F.6030001@gmail.com> <535408CF.4050809@ninenines.eu> + <535411C0.1020102@gmail.com> <5354125F.9040603@ninenines.eu> + <535416BE.3030901@gmail.com> +Message-ID: <5354324C.8070003@gmail.com> + +On 04/20/2014 08:49 PM, Karim Gemayel wrote: +> I'll have to go for Firefox remote debugging, so. + +Erm, finally it does work if I set up the correct IP for the Websocket +server - localhost is unknown on the LAN... + +And it works nicely. Thanks ! + +-- +Karim Gemayel + + +From ka.gemayel at gmail.com Mon Apr 28 18:01:07 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Mon, 28 Apr 2014 18:01:07 +0200 +Subject: [99s-extend] [cowboy] SSL client authentication +Message-ID: <535E7B43.4050308@gmail.com> + +Hello, + +I'm looking to use SSL client certificate for authentication with +Cowboy, but according to the Farwest roadmap this feature is not +implemented. Is this correct ? + +Would Nginx + Cowboy be an alternate solution ? + +-- +Karim Gemayel + + +From essen at ninenines.eu Mon Apr 28 18:04:47 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 28 Apr 2014 18:04:47 +0200 +Subject: [99s-extend] [cowboy] SSL client authentication +In-Reply-To: <535E7B43.4050308@gmail.com> +References: <535E7B43.4050308@gmail.com> +Message-ID: <535E7C1F.90501@ninenines.eu> + +http://ninenines.eu/docs/en/ranch/HEAD/guide/ssl_auth/ + +On 04/28/2014 06:01 PM, Karim Gemayel wrote: +> Hello, +> +> I'm looking to use SSL client certificate for authentication with +> Cowboy, but according to the Farwest roadmap this feature is not +> implemented. Is this correct ? +> +> Would Nginx + Cowboy be an alternate solution ? +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From ka.gemayel at gmail.com Mon Apr 28 18:12:46 2014 +From: ka.gemayel at gmail.com (Karim Gemayel) +Date: Mon, 28 Apr 2014 18:12:46 +0200 +Subject: [99s-extend] [cowboy] SSL client authentication +In-Reply-To: <535E7C1F.90501@ninenines.eu> +References: <535E7B43.4050308@gmail.com> <535E7C1F.90501@ninenines.eu> +Message-ID: <535E7DFE.6060206@gmail.com> + +On 04/28/2014 06:04 PM, Lo?c Hoguin wrote: +> http://ninenines.eu/docs/en/ranch/HEAD/guide/ssl_auth/ + +Thanks ! + +-- +Karim Gemayel + + diff --git a/_build/static/archives/extend/2014-April/000364.html b/_build/static/archives/extend/2014-April/000364.html new file mode 100644 index 00000000..bd82a29d --- /dev/null +++ b/_build/static/archives/extend/2014-April/000364.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Closing the mailing lists later this week + + + + + + + + + + +

[99s-extend] Closing the mailing lists later this week

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Apr 8 11:11:07 CEST 2014 +

+
+ +
Hello,
+
+I will be closing the mailing lists later this week. Preferred medium 
+for getting help will be opening tickets on github (if you can't figure 
+something out, then it's a bug!) or IRC.
+
+If you would like to continue helping users, then hop on IRC or follow 
+the projects on github and answer tickets. Thank you.
+
+Announcements will probably be made using the website's articles page 
+instead of here.
+
+The archives will be moved to git for safekeeping, but everything else 
+will be deleted, including user data and backups.
+
+Thanks for your understanding,
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000365.html b/_build/static/archives/extend/2014-April/000365.html new file mode 100644 index 00000000..db44c9d2 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000365.html @@ -0,0 +1,70 @@ + + + + [99s-extend] REST handler with ssl support + + + + + + + + + + +

[99s-extend] REST handler with ssl support

+ Samir Sow + samset at wanadoo.fr +
+ Wed Apr 9 16:52:47 CEST 2014 +

+
+ +
Hi,
+
+I’d like to secure my rest api with an ssl transport.
+Could not find any example to do so ?
+
+Any clue ?
+
+Thank you.
+
+Samir
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000366.html b/_build/static/archives/extend/2014-April/000366.html new file mode 100644 index 00000000..e359596d --- /dev/null +++ b/_build/static/archives/extend/2014-April/000366.html @@ -0,0 +1,91 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Samir Sow + samset at wanadoo.fr +
+ Fri Apr 11 12:39:13 CEST 2014 +

+
+ +
Hi,
+
+Still struggling to make ssl work.
+
+I downloaded the example ssl_hello_world.
+Upon execution : i get the following error with curl 
+
+ About to connect() to localhost port 8443 (#0)
+*   Trying ::1... Connexion refusée
+*   Trying 127.0.0.1... connected
+* Connected to localhost (127.0.0.1) port 8443 (#0)
+* Initializing NSS with certpath: sql:/etc/pki/nssdb
+* NSS error -8018
+* Closing connection #0
+* Problem with the SSL CA cert (path? access rights?)
+curl: (77) Problem with the SSL CA cert (path? access rights?)
+
+
+cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+
+cacert path checked.
+read permission checked
+
+I’ve tested with a browser and get a connection error.
+
+Any clue ?
+
+Samir
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000367.html b/_build/static/archives/extend/2014-April/000367.html new file mode 100644 index 00000000..b97debd3 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000367.html @@ -0,0 +1,104 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 11 13:18:56 CEST 2014 +

+
+ +
The certificate in the SSL example is self-generated, try curl with the 
+--insecure option.
+
+On 04/11/2014 12:39 PM, Samir Sow wrote:
+> Hi,
+>
+> Still struggling to make ssl work.
+>
+> I downloaded the example ssl_hello_world.
+> Upon execution : i get the following error with curl
+>
+>   About to connect() to localhost port 8443 (#0)
+> *   Trying ::1... Connexion refusée
+> *   Trying 127.0.0.1... connected
+> * Connected to localhost (127.0.0.1) port 8443 (#0)
+> * Initializing NSS with certpath: sql:/etc/pki/nssdb
+> * NSS error -8018
+> * Closing connection #0
+> * Problem with the SSL CA cert (path? access rights?)
+> curl: (77) Problem with the SSL CA cert (path? access rights?)
+>
+>
+> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+>
+> cacert path checked.
+> read permission checked
+>
+> I’ve tested with a browser and get a connection error.
+>
+> Any clue ?
+>
+> Samir
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000368.html b/_build/static/archives/extend/2014-April/000368.html new file mode 100644 index 00000000..248f6be8 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000368.html @@ -0,0 +1,114 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Samir Sow + samset at wanadoo.fr +
+ Fri Apr 11 13:25:51 CEST 2014 +

+
+ +
Thx.
+
+Same error …
+Openssl s_client does not work either.
+the server does not answer to ClientHello …
+
+Samir
+
+On 11 avr. 2014, at 13:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> The certificate in the SSL example is self-generated, try curl with the --insecure option.
+> 
+> On 04/11/2014 12:39 PM, Samir Sow wrote:
+>> Hi,
+>> 
+>> Still struggling to make ssl work.
+>> 
+>> I downloaded the example ssl_hello_world.
+>> Upon execution : i get the following error with curl
+>> 
+>>  About to connect() to localhost port 8443 (#0)
+>> *   Trying ::1... Connexion refusée
+>> *   Trying 127.0.0.1... connected
+>> * Connected to localhost (127.0.0.1) port 8443 (#0)
+>> * Initializing NSS with certpath: sql:/etc/pki/nssdb
+>> * NSS error -8018
+>> * Closing connection #0
+>> * Problem with the SSL CA cert (path? access rights?)
+>> curl: (77) Problem with the SSL CA cert (path? access rights?)
+>> 
+>> 
+>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+>> 
+>> cacert path checked.
+>> read permission checked
+>> 
+>> I’ve tested with a browser and get a connection error.
+>> 
+>> Any clue ?
+>> 
+>> Samir
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000369.html b/_build/static/archives/extend/2014-April/000369.html new file mode 100644 index 00000000..882a8348 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000369.html @@ -0,0 +1,173 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 11 13:41:29 CEST 2014 +

+
+ +
This is the successful output I get. You should try to see why yours is 
+different, perhaps someone somewhere ran into the same issue at some 
+point. Note that the --cacert option isn't needed and basically makes no 
+difference.
+
+
+% curl -ikvv https://localhost:8443
+* Rebuilt URL to: https://localhost:8443/
+* Hostname was NOT found in DNS cache
+*   Trying 127.0.0.1...
+* Connected to localhost (127.0.0.1) port 8443 (#0)
+* successfully set certificate verify locations:
+*   CAfile: /etc/ssl/certs/ca-certificates.crt
+   CApath: none
+* SSLv3, TLS handshake, Client hello (1):
+* SSLv3, TLS handshake, Server hello (2):
+* SSLv3, TLS handshake, CERT (11):
+* SSLv3, TLS handshake, Server key exchange (12):
+* SSLv3, TLS handshake, Server finished (14):
+* SSLv3, TLS handshake, Client key exchange (16):
+* SSLv3, TLS change cipher, Client hello (1):
+* SSLv3, TLS handshake, Finished (20):
+* SSLv3, TLS change cipher, Client hello (1):
+* SSLv3, TLS handshake, Finished (20):
+* SSL connection using ECDHE-RSA-AES256-SHA384
+* Server certificate:
+* 	 subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost
+* 	 start date: 2013-02-28 05:23:34 GMT
+* 	 expire date: 2033-02-23 05:23:34 GMT
+* 	 issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA
+* 	 SSL certificate verify result: self signed certificate in 
+certificate chain (19), continuing anyway.
+ > GET / HTTP/1.1
+ > User-Agent: curl/7.35.0
+ > Host: localhost:8443
+ > Accept: */*
+ >
+< HTTP/1.1 200 OK
+HTTP/1.1 200 OK
+< connection: keep-alive
+connection: keep-alive
+* Server Cowboy is not blacklisted
+< server: Cowboy
+server: Cowboy
+< date: Fri, 11 Apr 2014 11:30:03 GMT
+date: Fri, 11 Apr 2014 11:30:03 GMT
+< content-length: 12
+content-length: 12
+< content-type: text/plain
+content-type: text/plain
+
+<
+
+
+On 04/11/2014 01:25 PM, Samir Sow wrote:
+> Thx.
+>
+> Same error …
+> Openssl s_client does not work either.
+> the server does not answer to ClientHello …
+>
+> Samir
+>
+> On 11 avr. 2014, at 13:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> The certificate in the SSL example is self-generated, try curl with the --insecure option.
+>>
+>> On 04/11/2014 12:39 PM, Samir Sow wrote:
+>>> Hi,
+>>>
+>>> Still struggling to make ssl work.
+>>>
+>>> I downloaded the example ssl_hello_world.
+>>> Upon execution : i get the following error with curl
+>>>
+>>>   About to connect() to localhost port 8443 (#0)
+>>> *   Trying ::1... Connexion refusée
+>>> *   Trying 127.0.0.1... connected
+>>> * Connected to localhost (127.0.0.1) port 8443 (#0)
+>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb
+>>> * NSS error -8018
+>>> * Closing connection #0
+>>> * Problem with the SSL CA cert (path? access rights?)
+>>> curl: (77) Problem with the SSL CA cert (path? access rights?)
+>>>
+>>>
+>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+>>>
+>>> cacert path checked.
+>>> read permission checked
+>>>
+>>> I’ve tested with a browser and get a connection error.
+>>>
+>>> Any clue ?
+>>>
+>>> Samir
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000370.html b/_build/static/archives/extend/2014-April/000370.html new file mode 100644 index 00000000..6423667b --- /dev/null +++ b/_build/static/archives/extend/2014-April/000370.html @@ -0,0 +1,177 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Samir Sow + samset at wanadoo.fr +
+ Fri Apr 11 13:48:41 CEST 2014 +

+
+ +
Thx.
+
+On which OS + Erlang version is the server running ?
+
+Samir
+On 11 avr. 2014, at 13:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> This is the successful output I get. You should try to see why yours is different, perhaps someone somewhere ran into the same issue at some point. Note that the --cacert option isn't needed and basically makes no difference.
+> 
+> 
+> % curl -ikvv https://localhost:8443
+> * Rebuilt URL to: https://localhost:8443/
+> * Hostname was NOT found in DNS cache
+> *   Trying 127.0.0.1...
+> * Connected to localhost (127.0.0.1) port 8443 (#0)
+> * successfully set certificate verify locations:
+> *   CAfile: /etc/ssl/certs/ca-certificates.crt
+>  CApath: none
+> * SSLv3, TLS handshake, Client hello (1):
+> * SSLv3, TLS handshake, Server hello (2):
+> * SSLv3, TLS handshake, CERT (11):
+> * SSLv3, TLS handshake, Server key exchange (12):
+> * SSLv3, TLS handshake, Server finished (14):
+> * SSLv3, TLS handshake, Client key exchange (16):
+> * SSLv3, TLS change cipher, Client hello (1):
+> * SSLv3, TLS handshake, Finished (20):
+> * SSLv3, TLS change cipher, Client hello (1):
+> * SSLv3, TLS handshake, Finished (20):
+> * SSL connection using ECDHE-RSA-AES256-SHA384
+> * Server certificate:
+> * 	 subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost
+> * 	 start date: 2013-02-28 05:23:34 GMT
+> * 	 expire date: 2033-02-23 05:23:34 GMT
+> * 	 issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA
+> * 	 SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
+> > GET / HTTP/1.1
+> > User-Agent: curl/7.35.0
+> > Host: localhost:8443
+> > Accept: */*
+> >
+> < HTTP/1.1 200 OK
+> HTTP/1.1 200 OK
+> < connection: keep-alive
+> connection: keep-alive
+> * Server Cowboy is not blacklisted
+> < server: Cowboy
+> server: Cowboy
+> < date: Fri, 11 Apr 2014 11:30:03 GMT
+> date: Fri, 11 Apr 2014 11:30:03 GMT
+> < content-length: 12
+> content-length: 12
+> < content-type: text/plain
+> content-type: text/plain
+> 
+> <
+> 
+> 
+> On 04/11/2014 01:25 PM, Samir Sow wrote:
+>> Thx.
+>> 
+>> Same error …
+>> Openssl s_client does not work either.
+>> the server does not answer to ClientHello …
+>> 
+>> Samir
+>> 
+>> On 11 avr. 2014, at 13:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> 
+>>> The certificate in the SSL example is self-generated, try curl with the --insecure option.
+>>> 
+>>> On 04/11/2014 12:39 PM, Samir Sow wrote:
+>>>> Hi,
+>>>> 
+>>>> Still struggling to make ssl work.
+>>>> 
+>>>> I downloaded the example ssl_hello_world.
+>>>> Upon execution : i get the following error with curl
+>>>> 
+>>>>  About to connect() to localhost port 8443 (#0)
+>>>> *   Trying ::1... Connexion refusée
+>>>> *   Trying 127.0.0.1... connected
+>>>> * Connected to localhost (127.0.0.1) port 8443 (#0)
+>>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb
+>>>> * NSS error -8018
+>>>> * Closing connection #0
+>>>> * Problem with the SSL CA cert (path? access rights?)
+>>>> curl: (77) Problem with the SSL CA cert (path? access rights?)
+>>>> 
+>>>> 
+>>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+>>>> 
+>>>> cacert path checked.
+>>>> read permission checked
+>>>> 
+>>>> I’ve tested with a browser and get a connection error.
+>>>> 
+>>>> Any clue ?
+>>>> 
+>>>> Samir
+>>>> 
+>>>> 
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> https://lists.ninenines.eu/listinfo/extend
+>>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000371.html b/_build/static/archives/extend/2014-April/000371.html new file mode 100644 index 00000000..1809aeae --- /dev/null +++ b/_build/static/archives/extend/2014-April/000371.html @@ -0,0 +1,185 @@ + + + + [99s-extend] ssl_hello_world + + + + + + + + + + +

[99s-extend] ssl_hello_world

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 11 13:57:59 CEST 2014 +

+
+ +
It's tested on ArchLinux from R15B01 to master so that's unrelated to 
+the Erlang version.
+
+On 04/11/2014 01:48 PM, Samir Sow wrote:
+> Thx.
+>
+> On which OS + Erlang version is the server running ?
+>
+> Samir
+> On 11 avr. 2014, at 13:41, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> This is the successful output I get. You should try to see why yours is different, perhaps someone somewhere ran into the same issue at some point. Note that the --cacert option isn't needed and basically makes no difference.
+>>
+>>
+>> % curl -ikvv https://localhost:8443
+>> * Rebuilt URL to: https://localhost:8443/
+>> * Hostname was NOT found in DNS cache
+>> *   Trying 127.0.0.1...
+>> * Connected to localhost (127.0.0.1) port 8443 (#0)
+>> * successfully set certificate verify locations:
+>> *   CAfile: /etc/ssl/certs/ca-certificates.crt
+>>   CApath: none
+>> * SSLv3, TLS handshake, Client hello (1):
+>> * SSLv3, TLS handshake, Server hello (2):
+>> * SSLv3, TLS handshake, CERT (11):
+>> * SSLv3, TLS handshake, Server key exchange (12):
+>> * SSLv3, TLS handshake, Server finished (14):
+>> * SSLv3, TLS handshake, Client key exchange (16):
+>> * SSLv3, TLS change cipher, Client hello (1):
+>> * SSLv3, TLS handshake, Finished (20):
+>> * SSLv3, TLS change cipher, Client hello (1):
+>> * SSLv3, TLS handshake, Finished (20):
+>> * SSL connection using ECDHE-RSA-AES256-SHA384
+>> * Server certificate:
+>> * 	 subject: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=localhost
+>> * 	 start date: 2013-02-28 05:23:34 GMT
+>> * 	 expire date: 2033-02-23 05:23:34 GMT
+>> * 	 issuer: C=US; ST=Texas; O=Nine Nines; OU=Cowboy; CN=ROOT CA
+>> * 	 SSL certificate verify result: self signed certificate in certificate chain (19), continuing anyway.
+>>> GET / HTTP/1.1
+>>> User-Agent: curl/7.35.0
+>>> Host: localhost:8443
+>>> Accept: */*
+>>>
+>> < HTTP/1.1 200 OK
+>> HTTP/1.1 200 OK
+>> < connection: keep-alive
+>> connection: keep-alive
+>> * Server Cowboy is not blacklisted
+>> < server: Cowboy
+>> server: Cowboy
+>> < date: Fri, 11 Apr 2014 11:30:03 GMT
+>> date: Fri, 11 Apr 2014 11:30:03 GMT
+>> < content-length: 12
+>> content-length: 12
+>> < content-type: text/plain
+>> content-type: text/plain
+>>
+>> <
+>>
+>>
+>> On 04/11/2014 01:25 PM, Samir Sow wrote:
+>>> Thx.
+>>>
+>>> Same error …
+>>> Openssl s_client does not work either.
+>>> the server does not answer to ClientHello …
+>>>
+>>> Samir
+>>>
+>>> On 11 avr. 2014, at 13:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>>> The certificate in the SSL example is self-generated, try curl with the --insecure option.
+>>>>
+>>>> On 04/11/2014 12:39 PM, Samir Sow wrote:
+>>>>> Hi,
+>>>>>
+>>>>> Still struggling to make ssl work.
+>>>>>
+>>>>> I downloaded the example ssl_hello_world.
+>>>>> Upon execution : i get the following error with curl
+>>>>>
+>>>>>   About to connect() to localhost port 8443 (#0)
+>>>>> *   Trying ::1... Connexion refusée
+>>>>> *   Trying 127.0.0.1... connected
+>>>>> * Connected to localhost (127.0.0.1) port 8443 (#0)
+>>>>> * Initializing NSS with certpath: sql:/etc/pki/nssdb
+>>>>> * NSS error -8018
+>>>>> * Closing connection #0
+>>>>> * Problem with the SSL CA cert (path? access rights?)
+>>>>> curl: (77) Problem with the SSL CA cert (path? access rights?)
+>>>>>
+>>>>>
+>>>>> cmd = curl -vv --cacert priv/cert/cowboy-ca.crt -i https://localhost:8443/
+>>>>>
+>>>>> cacert path checked.
+>>>>> read permission checked
+>>>>>
+>>>>> I’ve tested with a browser and get a connection error.
+>>>>>
+>>>>> Any clue ?
+>>>>>
+>>>>> Samir
+>>>>>
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> http://ninenines.eu
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000372.html b/_build/static/archives/extend/2014-April/000372.html new file mode 100644 index 00000000..a537db02 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000372.html @@ -0,0 +1,93 @@ + + + + [99s-extend] ssl + + + + + + + + + + +

[99s-extend] ssl

+ Samir Sow + samset at wanadoo.fr +
+ Fri Apr 11 23:23:10 CEST 2014 +

+
+ +
Hi,
+
+Still struggling with ssl.
+I decided to check what’s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc.
+Found an error erlang:size badarg, but could not understand if it’s a problem with the key/cert files or with the data sent by the client.
+
+Any help welcomed. Thx
+
+Samir
+
+{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]).
+** exception exit: {{badarg,
+                        [{erlang,size,
+                             [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175,
+                               58,145,197,219|...]],
+                             []},
+                         {tls_record,get_tls_records_aux,2,
+                             [{file,"tls_record.erl"},{line,122}]},
+                         {tls_connection,next_tls_record,2,
+                             [{file,"tls_connection.erl"},{line,484}]},
+                         {tls_connection,handle_info,3,
+                             [{file,"tls_connection.erl"},{line,307}]},
+                         {gen_fsm,handle_msg,7,
+                             [{file,"gen_fsm.erl"},{line,503}]},
+                         {proc_lib,init_p_do_apply,3,
+                             [{file,"proc_lib.erl"},{line,239}]}]},
+                    {gen_fsm,sync_send_all_state_event,
+                        [<0.105.0>,{start,infinity},infinity]}}
+     in function  gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242)
+     in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649)
+     in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97)
+     in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81)
+     in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84)
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000373.html b/_build/static/archives/extend/2014-April/000373.html new file mode 100644 index 00000000..a442c6e6 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000373.html @@ -0,0 +1,112 @@ + + + + [99s-extend] ssl + + + + + + + + + + +

[99s-extend] ssl

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Apr 11 23:31:36 CEST 2014 +

+
+ +
Please report it to erlang-bugs, you'll get better help with ssl bugs there.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+-------- Original Message --------
+From:Samir Sow <samset at wanadoo.fr>
+Sent:Fri, 11 Apr 2014 23:23:10 +0200
+To:extend at lists.ninenines.eu
+Subject:[99s-extend] ssl
+
+>Hi,
+>
+>Still struggling with ssl.
+>I decided to check what’s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc.
+>Found an error erlang:size badarg, but could not understand if it’s a problem with the key/cert files or with the data sent by the client.
+>
+>Any help welcomed. Thx
+>
+>Samir
+>
+>{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]).
+>** exception exit: {{badarg,
+>                        [{erlang,size,
+>                             [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175,
+>                               58,145,197,219|...]],
+>                             []},
+>                         {tls_record,get_tls_records_aux,2,
+>                             [{file,"tls_record.erl"},{line,122}]},
+>                         {tls_connection,next_tls_record,2,
+>                             [{file,"tls_connection.erl"},{line,484}]},
+>                         {tls_connection,handle_info,3,
+>                             [{file,"tls_connection.erl"},{line,307}]},
+>                         {gen_fsm,handle_msg,7,
+>                             [{file,"gen_fsm.erl"},{line,503}]},
+>                         {proc_lib,init_p_do_apply,3,
+>                             [{file,"proc_lib.erl"},{line,239}]}]},
+>                    {gen_fsm,sync_send_all_state_event,
+>                        [<0.105.0>,{start,infinity},infinity]}}
+>     in function  gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242)
+>     in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649)
+>     in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97)
+>     in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81)
+>     in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84)
+>_______________________________________________
+>Extend mailing list
+>Extend at lists.ninenines.eu
+>https://lists.ninenines.eu/listinfo/extend
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140411/9e3c6c32/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000374.html b/_build/static/archives/extend/2014-April/000374.html new file mode 100644 index 00000000..8a7da0fe --- /dev/null +++ b/_build/static/archives/extend/2014-April/000374.html @@ -0,0 +1,83 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Sun Apr 20 19:46:55 CEST 2014 +

+
+ +
Hello,
+
+Writing a Cowboy (0.9.0) Websocket server (running on Ubuntu 12.04 ; 
+Erlang R16B03), it works fine on Firefox Desktop but fails on Firefox 
+Android (28.0.1).
+
+When testing with the websocket_example, on client-side Websockets are 
+detected but nothing happens then, no connection seems to be initiated ; 
+and on server-side, despite having traces in all functions of 
+ws_handler.erl, nothing appears in the console.
+
+However when testing http://www.websocket.org/echo.html with Firefox 
+Android, it works.
+
+So before going for remote debugging Firefox, I was looking for similar 
+cases using Cowboy Websocket with Firefox Android. Is there a JavaScript 
+tip to manage Websocket connection in that case ? Am I missing something ?
+
+Thanks.
+
+-- 
+Karim Gemayel
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000375.html b/_build/static/archives/extend/2014-April/000375.html new file mode 100644 index 00000000..e8a6e397 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000375.html @@ -0,0 +1,88 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Apr 20 19:50:07 CEST 2014 +

+
+ +
Try tracing the cowboy_websocket module?
+
+On 04/20/2014 07:46 PM, Karim Gemayel wrote:
+> Hello,
+>
+> Writing a Cowboy (0.9.0) Websocket server (running on Ubuntu 12.04 ;
+> Erlang R16B03), it works fine on Firefox Desktop but fails on Firefox
+> Android (28.0.1).
+>
+> When testing with the websocket_example, on client-side Websockets are
+> detected but nothing happens then, no connection seems to be initiated ;
+> and on server-side, despite having traces in all functions of
+> ws_handler.erl, nothing appears in the console.
+>
+> However when testing http://www.websocket.org/echo.html with Firefox
+> Android, it works.
+>
+> So before going for remote debugging Firefox, I was looking for similar
+> cases using Cowboy Websocket with Firefox Android. Is there a JavaScript
+> tip to manage Websocket connection in that case ? Am I missing something ?
+>
+> Thanks.
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000376.html b/_build/static/archives/extend/2014-April/000376.html new file mode 100644 index 00000000..60f40fb0 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000376.html @@ -0,0 +1,84 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Sun Apr 20 20:28:16 CEST 2014 +

+
+ +
On 04/20/2014 07:50 PM, Loïc Hoguin wrote:
+> Try tracing the cowboy_websocket module?
+
+The same case happens, no logs at all from Android whereas logs appear 
+from Desktop.
+
+I've attached the traces diffs.
+
+-- 
+Karim Gemayel
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: cowboy_websocket.diff
+Type: text/x-patch
+Size: 5780 bytes
+Desc: not available
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140420/bf45e4d0/attachment.bin>
+-------------- next part --------------
+A non-text attachment was scrubbed...
+Name: websocket_example.diff
+Type: text/x-patch
+Size: 2413 bytes
+Desc: not available
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140420/bf45e4d0/attachment-0001.bin>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000377.html b/_build/static/archives/extend/2014-April/000377.html new file mode 100644 index 00000000..654943ab --- /dev/null +++ b/_build/static/archives/extend/2014-April/000377.html @@ -0,0 +1,89 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Apr 20 20:30:55 CEST 2014 +

+
+ +
You really should take a look at tracing using dbg at some point. :-)
+
+But yeah if you don't get the upgrade function output and you are 
+testing against the Websocket example then I doubt the request even 
+reaches the server.
+
+As for why, I have no idea.
+
+On 04/20/2014 08:28 PM, Karim Gemayel wrote:
+> On 04/20/2014 07:50 PM, Loïc Hoguin wrote:
+>> Try tracing the cowboy_websocket module?
+>
+> The same case happens, no logs at all from Android whereas logs appear
+> from Desktop.
+>
+> I've attached the traces diffs.
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000378.html b/_build/static/archives/extend/2014-April/000378.html new file mode 100644 index 00000000..b74a3401 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000378.html @@ -0,0 +1,82 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Sun Apr 20 20:49:34 CEST 2014 +

+
+ +
On 04/20/2014 08:30 PM, Loïc Hoguin wrote:
+> You really should take a look at tracing using dbg at some point. :-)
+
+Yes, true. Actually, dbg is on my to-learn list. :)
+
+> But yeah if you don't get the upgrade function output and you are
+> testing against the Websocket example then I doubt the request even
+> reaches the server.
+>
+> As for why, I have no idea.
+
+That's a bit frustrating because the app is supposed to be used 
+primarily on mobile, so it seems I have to implement an HTTP fallback 
+that I didn't want to implement.
+
+I'll have to go for Firefox remote debugging, so.
+
+Thanks anyway.
+
+-- 
+Karim Gemayel
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000379.html b/_build/static/archives/extend/2014-April/000379.html new file mode 100644 index 00000000..d035c834 --- /dev/null +++ b/_build/static/archives/extend/2014-April/000379.html @@ -0,0 +1,71 @@ + + + + [99s-extend] [cowboy] Websocket with Firefox Android + + + + + + + + + + +

[99s-extend] [cowboy] Websocket with Firefox Android

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Sun Apr 20 22:47:08 CEST 2014 +

+
+ +
On 04/20/2014 08:49 PM, Karim Gemayel wrote:
+> I'll have to go for Firefox remote debugging, so.
+
+Erm, finally it does work if I set up the correct IP for the Websocket 
+server - localhost is unknown on the LAN...
+
+And it works nicely. Thanks !
+
+-- 
+Karim Gemayel
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000380.html b/_build/static/archives/extend/2014-April/000380.html new file mode 100644 index 00000000..626411ed --- /dev/null +++ b/_build/static/archives/extend/2014-April/000380.html @@ -0,0 +1,71 @@ + + + + [99s-extend] [cowboy] SSL client authentication + + + + + + + + + + +

[99s-extend] [cowboy] SSL client authentication

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Mon Apr 28 18:01:07 CEST 2014 +

+
+ +
Hello,
+
+I'm looking to use SSL client certificate for authentication with 
+Cowboy, but according to the Farwest roadmap this feature is not 
+implemented. Is this correct ?
+
+Would Nginx + Cowboy be an alternate solution ?
+
+-- 
+Karim Gemayel
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000381.html b/_build/static/archives/extend/2014-April/000381.html new file mode 100644 index 00000000..ea10c9ff --- /dev/null +++ b/_build/static/archives/extend/2014-April/000381.html @@ -0,0 +1,76 @@ + + + + [99s-extend] [cowboy] SSL client authentication + + + + + + + + + + +

[99s-extend] [cowboy] SSL client authentication

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Apr 28 18:04:47 CEST 2014 +

+
+ +
http://ninenines.eu/docs/en/ranch/HEAD/guide/ssl_auth/
+
+On 04/28/2014 06:01 PM, Karim Gemayel wrote:
+> Hello,
+>
+> I'm looking to use SSL client certificate for authentication with
+> Cowboy, but according to the Farwest roadmap this feature is not
+> implemented. Is this correct ?
+>
+> Would Nginx + Cowboy be an alternate solution ?
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/000382.html b/_build/static/archives/extend/2014-April/000382.html new file mode 100644 index 00000000..8c262edd --- /dev/null +++ b/_build/static/archives/extend/2014-April/000382.html @@ -0,0 +1,66 @@ + + + + [99s-extend] [cowboy] SSL client authentication + + + + + + + + + + +

[99s-extend] [cowboy] SSL client authentication

+ Karim Gemayel + ka.gemayel at gmail.com +
+ Mon Apr 28 18:12:46 CEST 2014 +

+
+ +
On 04/28/2014 06:04 PM, Loïc Hoguin wrote:
+> http://ninenines.eu/docs/en/ranch/HEAD/guide/ssl_auth/
+
+Thanks !
+
+-- 
+Karim Gemayel
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-April/author.html b/_build/static/archives/extend/2014-April/author.html new file mode 100644 index 00000000..1f765f04 --- /dev/null +++ b/_build/static/archives/extend/2014-April/author.html @@ -0,0 +1,142 @@ + + + + The Extend April 2014 Archive by author + + + + + +

April 2014 Archives by author

+ +

Starting: Tue Apr 8 11:11:07 CEST 2014
+ Ending: Mon Apr 28 18:12:46 CEST 2014
+ Messages: 19

+

+

+ Last message date: + Mon Apr 28 18:12:46 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-April/date.html b/_build/static/archives/extend/2014-April/date.html new file mode 100644 index 00000000..c8d03130 --- /dev/null +++ b/_build/static/archives/extend/2014-April/date.html @@ -0,0 +1,142 @@ + + + + The Extend April 2014 Archive by date + + + + + +

April 2014 Archives by date

+ +

Starting: Tue Apr 8 11:11:07 CEST 2014
+ Ending: Mon Apr 28 18:12:46 CEST 2014
+ Messages: 19

+

+

+ Last message date: + Mon Apr 28 18:12:46 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-April/index.html b/_build/static/archives/extend/2014-April/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-April/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-April/subject.html b/_build/static/archives/extend/2014-April/subject.html new file mode 100644 index 00000000..16a9826e --- /dev/null +++ b/_build/static/archives/extend/2014-April/subject.html @@ -0,0 +1,142 @@ + + + + The Extend April 2014 Archive by subject + + + + + +

April 2014 Archives by subject

+ +

Starting: Tue Apr 8 11:11:07 CEST 2014
+ Ending: Mon Apr 28 18:12:46 CEST 2014
+ Messages: 19

+

+

+ Last message date: + Mon Apr 28 18:12:46 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-April/thread.html b/_build/static/archives/extend/2014-April/thread.html new file mode 100644 index 00000000..2087e02b --- /dev/null +++ b/_build/static/archives/extend/2014-April/thread.html @@ -0,0 +1,179 @@ + + + + The Extend April 2014 Archive by thread + + + + + +

April 2014 Archives by thread

+ +

Starting: Tue Apr 8 11:11:07 CEST 2014
+ Ending: Mon Apr 28 18:12:46 CEST 2014
+ Messages: 19

+

+

+ Last message date: + Mon Apr 28 18:12:46 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-August.txt b/_build/static/archives/extend/2014-August.txt new file mode 100644 index 00000000..4903378b --- /dev/null +++ b/_build/static/archives/extend/2014-August.txt @@ -0,0 +1,2532 @@ +From samset at wanadoo.fr Mon Aug 4 18:39:26 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 18:39:26 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +Message-ID: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> + +Hi, + +I?ve moved a working http server to https. +SSL handshaking is ok but i got the following Ranch error : + +[error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} + +call is + +curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? + + +dispatch is + +[{'_', [ + {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, + {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, + {"/mtagw", hck_mta, []} + ]}]). + + +Any clue ? + +Thanks + +sincerely + +Samir + + +From essen at ninenines.eu Mon Aug 4 18:49:32 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 18:49:32 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> +References: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> +Message-ID: <53DFB99C.9060401@ninenines.eu> + +Surely there's something else that you're not showing there. For some +reason you got a list of segments in the error, and we haven't had that +for a very long time. Do you have an onrequest hook or middleware that +does weird things perhaps? + +On 08/04/2014 06:39 PM, Samir Sow wrote: +> Hi, +> +> I?ve moved a working http server to https. +> SSL handshaking is ok but i got the following Ranch error : +> +> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +> +> call is +> +> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +> +> +> dispatch is +> +> [{'_', [ +> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +> {"/mtagw", hck_mta, []} +> ]}]). +> +> +> Any clue ? +> +> Thanks +> +> sincerely +> +> Samir +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 19:50:36 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 19:50:36 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <53DFB99C.9060401@ninenines.eu> +References: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> + <53DFB99C.9060401@ninenines.eu> +Message-ID: <76854630-A55A-4A7D-9CC0-4BA78636AFAA@wanadoo.fr> + +I?m not sure i understand your question. + +I?ve only started a cowboy https server with a handler. +The http version was working fine. + +Sincerely + +Samir + +On 4 ao?t 2014, at 18:49, Lo?c Hoguin wrote: + +> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +> +> On 08/04/2014 06:39 PM, Samir Sow wrote: +>> Hi, +>> +>> I?ve moved a working http server to https. +>> SSL handshaking is ok but i got the following Ranch error : +>> +>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>> +>> call is +>> +>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>> +>> +>> dispatch is +>> +>> [{'_', [ +>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>> {"/mtagw", hck_mta, []} +>> ]}]). +>> +>> +>> Any clue ? +>> +>> Thanks +>> +>> sincerely +>> +>> Samir +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Mon Aug 4 19:59:57 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 19:59:57 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <76854630-A55A-4A7D-9CC0-4BA78636AFAA@wanadoo.fr> +References: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> + <53DFB99C.9060401@ninenines.eu> + <76854630-A55A-4A7D-9CC0-4BA78636AFAA@wanadoo.fr> +Message-ID: <53DFCA1D.60001@ninenines.eu> + +I'm saying it can't be the only difference. + +On 08/04/2014 07:50 PM, Samir Sow wrote: +> I?m not sure i understand your question. +> +> I?ve only started a cowboy https server with a handler. +> The http version was working fine. +> +> Sincerely +> +> Samir +> +> On 4 ao?t 2014, at 18:49, Lo?c Hoguin wrote: +> +>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>> +>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>> Hi, +>>> +>>> I?ve moved a working http server to https. +>>> SSL handshaking is ok but i got the following Ranch error : +>>> +>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>> +>>> call is +>>> +>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>> +>>> +>>> dispatch is +>>> +>>> [{'_', [ +>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>> {"/mtagw", hck_mta, []} +>>> ]}]). +>>> +>>> +>>> Any clue ? +>>> +>>> Thanks +>>> +>>> sincerely +>>> +>>> Samir +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 20:16:06 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 20:16:06 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: <53DFCA1D.60001@ninenines.eu> +References: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> + <53DFB99C.9060401@ninenines.eu> + <76854630-A55A-4A7D-9CC0-4BA78636AFAA@wanadoo.fr> + <53DFCA1D.60001@ninenines.eu> +Message-ID: + +I can assure you it?s the only one :) + +Samir + +On 4 ao?t 2014, at 19:59, Lo?c Hoguin wrote: + +> I'm saying it can't be the only difference. +> +> On 08/04/2014 07:50 PM, Samir Sow wrote: +>> I?m not sure i understand your question. +>> +>> I?ve only started a cowboy https server with a handler. +>> The http version was working fine. +>> +>> Sincerely +>> +>> Samir +>> +>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin wrote: +>> +>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>> +>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>> Hi, +>>>> +>>>> I?ve moved a working http server to https. +>>>> SSL handshaking is ok but i got the following Ranch error : +>>>> +>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>> +>>>> call is +>>>> +>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>> +>>>> +>>>> dispatch is +>>>> +>>>> [{'_', [ +>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>> {"/mtagw", hck_mta, []} +>>>> ]}]). +>>>> +>>>> +>>>> Any clue ? +>>>> +>>>> Thanks +>>>> +>>>> sincerely +>>>> +>>>> Samir +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Mon Aug 4 20:24:15 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 04 Aug 2014 20:24:15 +0200 +Subject: [99s-extend] ranch dispatch error ver 1.0.0 +In-Reply-To: +References: <923834FE-1A66-44E6-923A-9C15BF16E181@wanadoo.fr> + <53DFB99C.9060401@ninenines.eu> + <76854630-A55A-4A7D-9CC0-4BA78636AFAA@wanadoo.fr> + <53DFCA1D.60001@ninenines.eu> + +Message-ID: <53DFCFCF.4010900@ninenines.eu> + +Well I don't have any idea then. Cowboy is tested with http and https, +both with and without compression enabled. There's never been any +difference of the kind, the only difference is timing related. + +On 08/04/2014 08:16 PM, Samir Sow wrote: +> I can assure you it?s the only one :) +> +> Samir +> +> On 4 ao?t 2014, at 19:59, Lo?c Hoguin wrote: +> +>> I'm saying it can't be the only difference. +>> +>> On 08/04/2014 07:50 PM, Samir Sow wrote: +>>> I?m not sure i understand your question. +>>> +>>> I?ve only started a cowboy https server with a handler. +>>> The http version was working fine. +>>> +>>> Sincerely +>>> +>>> Samir +>>> +>>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin wrote: +>>> +>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>>> +>>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> I?ve moved a working http server to https. +>>>>> SSL handshaking is ok but i got the following Ranch error : +>>>>> +>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>>> +>>>>> call is +>>>>> +>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>>> +>>>>> +>>>>> dispatch is +>>>>> +>>>>> [{'_', [ +>>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>>> {"/mtagw", hck_mta, []} +>>>>> ]}]). +>>>>> +>>>>> +>>>>> Any clue ? +>>>>> +>>>>> Thanks +>>>>> +>>>>> sincerely +>>>>> +>>>>> Samir +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Aug 4 20:25:25 2014 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 4 Aug 2014 20:25:25 +0200 +Subject: [99s-extend] Fwd: ranch dispatch error ver 1.0.0 +References: +Message-ID: + + +I found my mistake. + +I?ve a typo error - used a token instead of a function call in the dispatch object. +I apologize for the disturbance. + +Thank you. + +Sincerely + +Samir + +Begin forwarded message: + +> From: Samir Sow +> Subject: Re: [99s-extend] ranch dispatch error ver 1.0.0 +> Date: 4 ao?t 2014 20:16:06 UTC+2 +> To: Lo?c Hoguin +> Cc: extend at lists.ninenines.eu +> +> I can assure you it?s the only one :) +> +> Samir +> +> On 4 ao?t 2014, at 19:59, Lo?c Hoguin wrote: +> +>> I'm saying it can't be the only difference. +>> +>> On 08/04/2014 07:50 PM, Samir Sow wrote: +>>> I?m not sure i understand your question. +>>> +>>> I?ve only started a cowboy https server with a handler. +>>> The http version was working fine. +>>> +>>> Sincerely +>>> +>>> Samir +>>> +>>> On 4 ao?t 2014, at 18:49, Lo?c Hoguin wrote: +>>> +>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps? +>>>> +>>>> On 08/04/2014 06:39 PM, Samir Sow wrote: +>>>>> Hi, +>>>>> +>>>>> I?ve moved a working http server to https. +>>>>> SSL handshaking is ok but i got the following Ranch error : +>>>>> +>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]} +>>>>> +>>>>> call is +>>>>> +>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw? +>>>>> +>>>>> +>>>>> dispatch is +>>>>> +>>>>> [{'_', [ +>>>>> {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}}, +>>>>> {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]}, +>>>>> {"/mtagw", hck_mta, []} +>>>>> ]}]). +>>>>> +>>>>> +>>>>> Any clue ? +>>>>> +>>>>> Thanks +>>>>> +>>>>> sincerely +>>>>> +>>>>> Samir +>>>>> +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 12:58:10 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 11:58:10 +0100 +Subject: [99s-extend] Broken links for REST flowcharts +Message-ID: + +Hi. + +The image links are broken for the REST flowcharts' guide, part of cowboy. + +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png +(for example) +should probably be +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png +according to the hierarchy here: +https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide + +Thanks. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Aug 5 13:19:12 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 13:19:12 +0200 +Subject: [99s-extend] Broken links for REST flowcharts +In-Reply-To: +References: +Message-ID: <53E0BDB0.70401@ninenines.eu> + +Fixed, thanks. + +On 08/05/2014 12:58 PM, Paulo F. Oliveira wrote: +> Hi. +> +> The image links are broken for the REST flowcharts' guide, part of cowboy. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png +> (for example) +> should probably be +> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png +> according to the hierarchy here: +> https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide +> +> Thanks. +> +> - Paulo F. Oliveira +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Tue Aug 5 14:43:47 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 14:43:47 +0200 +Subject: [99s-extend] [ANN] Cowboy 1.0 +Message-ID: <53E0D183.1060206@ninenines.eu> + +Hello! + +Cowboy 1.0 has been released. + +Cowboy is a small and fast HTTP server for Erlang with support for +Webmachine-like REST, Websocket and more. + + https://github.com/ninenines/cowboy + +Cowboy is the work of more than 80 people. I would like to congratulate +everyone for the great work done so far. Thank you! + +Please see the CHANGELOG for details on what's changed. + + https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md + +This release marks the beginning of the 1.0.x branch which will contain +backward compatible fixes. This branch will be maintained at least until +Cowboy 2.0 gets released (longer if sponsors request it). It is highly +recommended that you follow this branch if you were following master +before, as master will receive backward incompatible changes starting +tomorrow. + +Cowboy is now fully documented. It has a user guide, a function +reference manual, and a wealth of examples. You can also install man +pages as explained in the README of the project. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/ + http://ninenines.eu/docs/en/cowboy/1.0/manual/ + https://github.com/ninenines/cowboy/tree/master/examples + +Following a discussion on the Erlang mailing lists the Getting Started +chapter was reworked and greatly simplified, in parts due to the +improvements made to erlang.mk. Feedback is of course always welcome. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ + +Starting tomorrow the master branch will receive backward incompatible +changes. Most of the planned changes are detailed in the ROADMAP. You +are welcome to suggest additional changes. + + https://github.com/ninenines/cowboy/blob/master/ROADMAP.md + +Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +18.0 comes out. There are no plans for a Cowboy 1.1 at this time, +although that may change in the coming months if there is interest in +new features. + +Ranch also got upgraded to 1.0, although there was no changes from the +previous release. + + https://github.com/ninenines/ranch + +Thanks to everyone who made this project what it is today! + +-- +Lo?c Hoguin +http://ninenines.eu + +From max.lapshin at gmail.com Tue Aug 5 15:33:27 2014 +From: max.lapshin at gmail.com (Max Lapshin) +Date: Tue, 5 Aug 2014 17:33:27 +0400 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <53E0D183.1060206@ninenines.eu> +References: <53E0D183.1060206@ninenines.eu> +Message-ID: + +Loic, it is very cool! + +Thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From gumm at sigma-star.com Tue Aug 5 17:56:25 2014 +From: gumm at sigma-star.com (Jesse Gumm) +Date: Tue, 5 Aug 2014 10:56:25 -0500 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <53E0D183.1060206@ninenines.eu> +References: <53E0D183.1060206@ninenines.eu> +Message-ID: + +Congrats Loic! + +-- +Jesse Gumm +Owner, Sigma Star Systems +414.940.4866 || sigma-star.com || @jessegumm +On Aug 5, 2014 7:43 AM, "Lo?c Hoguin" wrote: + +> Hello! +> +> Cowboy 1.0 has been released. +> +> Cowboy is a small and fast HTTP server for Erlang with support for +> Webmachine-like REST, Websocket and more. +> +> https://github.com/ninenines/cowboy +> +> Cowboy is the work of more than 80 people. I would like to congratulate +> everyone for the great work done so far. Thank you! +> +> Please see the CHANGELOG for details on what's changed. +> +> https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md +> +> This release marks the beginning of the 1.0.x branch which will contain +> backward compatible fixes. This branch will be maintained at least until +> Cowboy 2.0 gets released (longer if sponsors request it). It is highly +> recommended that you follow this branch if you were following master +> before, as master will receive backward incompatible changes starting +> tomorrow. +> +> Cowboy is now fully documented. It has a user guide, a function reference +> manual, and a wealth of examples. You can also install man pages as +> explained in the README of the project. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/ +> http://ninenines.eu/docs/en/cowboy/1.0/manual/ +> https://github.com/ninenines/cowboy/tree/master/examples +> +> Following a discussion on the Erlang mailing lists the Getting Started +> chapter was reworked and greatly simplified, in parts due to the +> improvements made to erlang.mk. Feedback is of course always welcome. +> +> http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ +> +> Starting tomorrow the master branch will receive backward incompatible +> changes. Most of the planned changes are detailed in the ROADMAP. You are +> welcome to suggest additional changes. +> +> https://github.com/ninenines/cowboy/blob/master/ROADMAP.md +> +> Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +> 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although +> that may change in the coming months if there is interest in new features. +> +> Ranch also got upgraded to 1.0, although there was no changes from the +> previous release. +> +> https://github.com/ninenines/ranch +> +> Thanks to everyone who made this project what it is today! +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lloyd at writersglen.com Tue Aug 5 19:34:33 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Tue, 5 Aug 2014 13:34:33 -0400 (EDT) +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <53E0D183.1060206@ninenines.eu> +References: <53E0D183.1060206@ninenines.eu> +Message-ID: <1407260073.80138967@apps.rackspace.com> + +Tip of the hat, Lo?c et. al. + +Outstanding and much appreciated work. + +Best to all, + +Lloyd + +-----Original Message----- +From: "Lo?c Hoguin" +Sent: Tuesday, August 5, 2014 8:43am +To: "Erlang" , Extend at lists.ninenines.eu +Subject: [erlang-questions] [ANN] Cowboy 1.0 + +Hello! + +Cowboy 1.0 has been released. + +Cowboy is a small and fast HTTP server for Erlang with support for +Webmachine-like REST, Websocket and more. + + https://github.com/ninenines/cowboy + +Cowboy is the work of more than 80 people. I would like to congratulate +everyone for the great work done so far. Thank you! + +Please see the CHANGELOG for details on what's changed. + + https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md + +This release marks the beginning of the 1.0.x branch which will contain +backward compatible fixes. This branch will be maintained at least until +Cowboy 2.0 gets released (longer if sponsors request it). It is highly +recommended that you follow this branch if you were following master +before, as master will receive backward incompatible changes starting +tomorrow. + +Cowboy is now fully documented. It has a user guide, a function +reference manual, and a wealth of examples. You can also install man +pages as explained in the README of the project. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/ + http://ninenines.eu/docs/en/cowboy/1.0/manual/ + https://github.com/ninenines/cowboy/tree/master/examples + +Following a discussion on the Erlang mailing lists the Getting Started +chapter was reworked and greatly simplified, in parts due to the +improvements made to erlang.mk. Feedback is of course always welcome. + + http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/ + +Starting tomorrow the master branch will receive backward incompatible +changes. Most of the planned changes are detailed in the ROADMAP. You +are welcome to suggest additional changes. + + https://github.com/ninenines/cowboy/blob/master/ROADMAP.md + +Cowboy 2.0 is planned to be released at around the same time Erlang/OTP +18.0 comes out. There are no plans for a Cowboy 1.1 at this time, +although that may change in the coming months if there is interest in +new features. + +Ranch also got upgraded to 1.0, although there was no changes from the +previous release. + + https://github.com/ninenines/ranch + +Thanks to everyone who made this project what it is today! + +-- +Lo?c Hoguin +http://ninenines.eu +_______________________________________________ +erlang-questions mailing list +erlang-questions at erlang.org +http://erlang.org/mailman/listinfo/erlang-questions + + + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 22:33:17 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 21:33:17 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: +References: <53E0D183.1060206@ninenines.eu> + + +Message-ID: + +Hi, Federico. + +Check this out for the "why" regarding your question: +https://github.com/ninenines/cowboy/issues/715 + +It's one of the reasons (I haven't detected others yet) stopping me from +moving to 1.0, unfortunately (I have some projects depending on these +status codes already), but as soon as I have some time and look at all the +_major_ differences between 0.9.0 and 1.0 I think I'll make the move. For +the time being, I have found no issues with the REST part of cowboy (the +one I use). + +Thank you, Lo?c et all for the effort and for keeping it open source. + +Regards. + +- Paulo F. Oliveira + + +On 5 August 2014 15:18, Federico Carrone wrote: + +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 instead of +> 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin +> wrote: +> +>> Loic, it is very cool! +>> +>> Thanks. +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +> +> +> -- +> http://federicocarrone.com/ +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Aug 5 22:55:34 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 22:55:34 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: +References: <53E0D183.1060206@ninenines.eu> + + + +Message-ID: <53E144C6.7040701@ninenines.eu> + +You can easily send 422 and return halt instead of returning false if +you need to keep that, it'll just be 2 lines instead of 1. :) + +On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> Hi, Federico. +> +> Check this out for the "why" regarding your question: +> https://github.com/ninenines/cowboy/issues/715 +> +> It's one of the reasons (I haven't detected others yet) stopping me from +> moving to 1.0, unfortunately (I have some projects depending on these +> status codes already), but as soon as I have some time and look at all +> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +> move. For the time being, I have found no issues with the REST part of +> cowboy (the one I use). +> +> Thank you, Lo?c et all for the effort and for keeping it open source. +> +> Regards. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 15:18, Federico Carrone > wrote: +> +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 +> instead of 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > wrote: +> +> Loic, it is very cool! +> +> Thanks. +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +> +> +> -- +> http://federicocarrone.com/ +> +> _______________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> http://erlang.org/mailman/listinfo/erlang-questions +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Tue Aug 5 23:01:38 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 5 Aug 2014 22:01:38 +0100 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: <53E144C6.7040701@ninenines.eu> +References: <53E0D183.1060206@ninenines.eu> + + + + <53E144C6.7040701@ninenines.eu> +Message-ID: + +Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only +important difference I should be aware of, then? I haven't written any real +tests, for the time being, to guarantee backward compatibility for +dependants... + +In any case, I'm thinking about updating the dependencies in the future (I +own one of them and the other one is an internal project, for the time +being). + +Thanks for the tip. + +Cheers. + +- Paulo F. Oliveira + + +On 5 August 2014 21:55, Lo?c Hoguin wrote: + +> You can easily send 422 and return halt instead of returning false if you +> need to keep that, it'll just be 2 lines instead of 1. :) +> +> On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> +>> Hi, Federico. +>> +>> Check this out for the "why" regarding your question: +>> https://github.com/ninenines/cowboy/issues/715 +>> +>> It's one of the reasons (I haven't detected others yet) stopping me from +>> moving to 1.0, unfortunately (I have some projects depending on these +>> status codes already), but as soon as I have some time and look at all +>> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +>> move. For the time being, I have found no issues with the REST part of +>> cowboy (the one I use). +>> +>> Thank you, Lo?c et all for the effort and for keeping it open source. +>> +>> Regards. +>> +>> - Paulo F. Oliveira +>> +>> +>> On 5 August 2014 15:18, Federico Carrone > > wrote: +>> +>> Congratulations Loic. I really love cowboy. +>> +>> I got only one question: Why did you change the reply with 400 +>> instead of 422 in cowboy_rest for unprocessable entities? +>> +>> Regards, +>> Federico. +>> +>> +>> +>> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin > > wrote: +>> +>> Loic, it is very cool! +>> +>> Thanks. +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +>> +>> +>> -- +>> http://federicocarrone.com/ +>> +>> _______________________________________________ +>> erlang-questions mailing list +>> erlang-questions at erlang.org +>> http://erlang.org/mailman/listinfo/erlang-questions +>> +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Aug 5 23:06:19 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 05 Aug 2014 23:06:19 +0200 +Subject: [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 +In-Reply-To: +References: <53E0D183.1060206@ninenines.eu> <53E144C6.7040701@ninenines.eu> + +Message-ID: <53E1474B.1080407@ninenines.eu> + +If you were already at the previous version (0.10) then that plus a 400 +instead of 500 when header parsing fails are pretty much the only changes. + +There's some more if you were at 0.9, mostly the body reading interface +changed to prevent annoying timeout issues. + +On 08/05/2014 11:01 PM, Paulo F. Oliveira wrote: +> Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only +> important difference I should be aware of, then? I haven't written any +> real tests, for the time being, to guarantee backward compatibility for +> dependants... +> +> In any case, I'm thinking about updating the dependencies in the future +> (I own one of them and the other one is an internal project, for the +> time being). +> +> Thanks for the tip. +> +> Cheers. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 21:55, Lo?c Hoguin > wrote: +> +> You can easily send 422 and return halt instead of returning false +> if you need to keep that, it'll just be 2 lines instead of 1. :) +> +> On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote: +> +> Hi, Federico. +> +> Check this out for the "why" regarding your question: +> https://github.com/ninenines/__cowboy/issues/715 +> +> +> It's one of the reasons (I haven't detected others yet) stopping +> me from +> moving to 1.0, unfortunately (I have some projects depending on +> these +> status codes already), but as soon as I have some time and look +> at all +> the _major_ differences between 0.9.0 and 1.0 I think I'll make the +> move. For the time being, I have found no issues with the REST +> part of +> cowboy (the one I use). +> +> Thank you, Lo?c et all for the effort and for keeping it open +> source. +> +> Regards. +> +> - Paulo F. Oliveira +> +> +> On 5 August 2014 15:18, Federico Carrone +> +> >> wrote: +> +> Congratulations Loic. I really love cowboy. +> +> I got only one question: Why did you change the reply with 400 +> instead of 422 in cowboy_rest for unprocessable entities? +> +> Regards, +> Federico. +> +> +> +> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin +> +> >__> wrote: +> +> Loic, it is very cool! +> +> Thanks. +> +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> > +> http://erlang.org/mailman/__listinfo/erlang-questions +> +> +> +> +> +> -- +> http://federicocarrone.com/ +> +> _________________________________________________ +> erlang-questions mailing list +> erlang-questions at erlang.org +> > +> http://erlang.org/mailman/__listinfo/erlang-questions +> +> +> +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/__listinfo/extend +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From michael.wittig at tullius-walden.com Wed Aug 13 11:17:51 2014 +From: michael.wittig at tullius-walden.com (Michael Wittig) +Date: Wed, 13 Aug 2014 11:17:51 +0200 +Subject: [99s-extend] eunit suppoort in erlang.mk? +Message-ID: + +hi, + +is it possible to run eunit tests when executing make tests? +I have my tests directly in the modules (e.g. xyz_server) + +Regards, + +Michael +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From chaehb at gmail.com Thu Aug 14 03:20:05 2014 +From: chaehb at gmail.com (chaehb) +Date: Thu, 14 Aug 2014 10:20:05 +0900 +Subject: [99s-extend] couldn't quit in Erlang 17.1 +In-Reply-To: <53D4C59E.2010909@ninenines.eu> +References: <5E6EEC48-13CF-48A9-BD48-DC339D93B75D@gmail.com> + <53D4C59E.2010909@ninenines.eu> +Message-ID: <159B6EFE-5869-4503-ADD7-5547D8A0A6B2@gmail.com> + + +On 2014. 7. 27., at ?? 6:25, Lo?c Hoguin wrote: + +> Does it happen with ssl_hello_world? +> +> On 07/26/2014 09:06 AM, chaehb wrote: +>> Hi, everybody. +>> +>> After Erlang updated to 17.1, +>> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages.. +>> +>> (after ok signal printed) +>> +>> ?... +>> =ERROR REPORT==== 26-Jul-2014::15:23:33 === +>> Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +>> ?. +>> +>> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments. +>> +>> This is only appeared when I only use ssl(https). +>> But when use only http with same dispatch rules, cowboy normally quitted. +>> + +I?ve try to do more tests with ssl_hello_world in cowboy(v1.0) and various Erlang/OTP versions. + +If ErlangOTP < 17.0, http/https works fine. +If ErlangOTP >= 17.1(17.1.x,17.2 in github), http works fine but with https the same errors appeared. + +***** +When I edited ranch_accepter.erl > line 40 + {error, Reason} when Reason =/= closed -> + to + {error, Reason} -> +, +https work and app was normally quitted. + +When I printed, Reason == closed. + + +From lists at tuli.pe Thu Aug 14 17:44:25 2014 +From: lists at tuli.pe (Camille Troillard) +Date: Thu, 14 Aug 2014 17:44:25 +0200 +Subject: [99s-extend] cowboy_rest and response headers +Message-ID: <16D8B25C-9FED-4688-8710-8B0811A8A4F6@tuli.pe> + +Hello, + +I would like to set a Content-Range header in the response of a HEAD request. +Can I do that within the context of a cowboy_rest handler? +Ideally, I wish to let cowboy_rest reply and just specify this additional header. + + +Best, +Camille +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Aug 14 17:50:09 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 14 Aug 2014 17:50:09 +0200 +Subject: [99s-extend] cowboy_rest and response headers +In-Reply-To: <16D8B25C-9FED-4688-8710-8B0811A8A4F6@tuli.pe> +References: <16D8B25C-9FED-4688-8710-8B0811A8A4F6@tuli.pe> +Message-ID: <53ECDAB1.8060504@ninenines.eu> + +Use cowboy_req:set_resp_header and return the Req this function gives you. + +On 08/14/2014 05:44 PM, Camille Troillard wrote: +> Hello, +> +> I would like to set a Content-Range header in the response of a HEAD +> request. +> Can I do that within the context of a cowboy_rest handler? +> Ideally, I wish to let cowboy_rest reply and just specify this +> additional header. +> +> +> Best, +> Camille +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Sun Aug 24 01:58:12 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 01:58:12 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +Message-ID: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> + +Hi all, + +1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +have a small crash. + +Here is my code: + +https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 + +Could you tell me if I correctly use cowboy_rest for the PUT verb? I +have seen is_conflict/2, but I don't know how to use it. + +2. I would like to change the response code, but I get the error. Is it +possible? + +Thank you. + +Regards, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From daniel.goertzen at gmail.com Sun Aug 24 02:16:02 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Sat, 23 Aug 2014 19:16:02 -0500 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> +References: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> +Message-ID: + +You should implement the resource_exists() callback; this will let the rest +module pick a 200 vs 201. If the db name was incorrect, I think you are +just supposed to return false from the put callback. I can't remember the +http code for that case. + +Regards, +Dan. + + +On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel wrote: + +> Hi all, +> +> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have +> a small crash. +> +> Here is my code: +> +> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +> +> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +> seen is_conflict/2, but I don't know how to use it. +> +> 2. I would like to change the response code, but I get the error. Is it +> possible? +> +> Thank you. +> +> Regards, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From stephane at wirtel.be Sun Aug 24 02:22:22 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 02:22:22 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: +References: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> + +Message-ID: <5C66851E-7B69-426A-9444-51C81E8EBE59@wirtel.be> + +resource_exists is used by POST +is_conflict is used by PUT (from the code) +but in the case where my database already exists, I need to return 412 +and not 409. + +and I know I don't respect the default value returned by Cowboy_rest. + +On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: + +> You should implement the resource_exists() callback; this will let the +> rest +> module pick a 200 vs 201. If the db name was incorrect, I think you +> are +> just supposed to return false from the put callback. I can't remember +> the +> http code for that case. +> +> Regards, +> Dan. +> +> +> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel +> wrote: +> +>> Hi all, +>> +>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +>> have +>> a small crash. +>> +>> Here is my code: +>> +>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>> +>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I +>> have +>> seen is_conflict/2, but I don't know how to use it. +>> +>> 2. I would like to change the response code, but I get the error. Is +>> it +>> possible? +>> +>> Thank you. +>> +>> Regards, +>> +>> Stephane +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From edgurgel at gmail.com Sun Aug 24 02:25:54 2014 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Sun, 24 Aug 2014 12:25:54 +1200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: <5C66851E-7B69-426A-9444-51C81E8EBE59@wirtel.be> +References: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> + + <5C66851E-7B69-426A-9444-51C81E8EBE59@wirtel.be> +Message-ID: + +I think you can always halt the processing and do the reply by yourself: + +{ok, Req2} = cowboy_req:reply(412, Req), +{halt, Req2, State}. + + +On Sun, Aug 24, 2014 at 12:22 PM, St?phane Wirtel +wrote: + +> resource_exists is used by POST +> is_conflict is used by PUT (from the code) +> but in the case where my database already exists, I need to return 412 and +> not 409. +> +> and I know I don't respect the default value returned by Cowboy_rest. +> +> +> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: +> +> You should implement the resource_exists() callback; this will let the +>> rest +>> module pick a 200 vs 201. If the db name was incorrect, I think you are +>> just supposed to return false from the put callback. I can't remember the +>> http code for that case. +>> +>> Regards, +>> Dan. +>> +>> +>> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel +>> wrote: +>> +>> Hi all, +>>> +>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I +>>> have +>>> a small crash. +>>> +>>> Here is my code: +>>> +>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>>> +>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +>>> seen is_conflict/2, but I don't know how to use it. +>>> +>>> 2. I would like to change the response code, but I get the error. Is it +>>> possible? +>>> +>>> Thank you. +>>> +>>> Regards, +>>> +>>> Stephane +>>> +>>> -- +>>> St?phane Wirtel - http://wirtel.be - @matrixise +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>>> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + + + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From stephane at wirtel.be Sun Aug 24 02:52:58 2014 +From: stephane at wirtel.be (Stephane Wirtel) +Date: Sun, 24 Aug 2014 02:52:58 +0200 +Subject: [99s-extend] How to use the PUT verb with Cowboy_Rest ? +In-Reply-To: +References: <273F5C1E-4CAF-4BD6-8229-64EA2788E970@wirtel.be> + + <5C66851E-7B69-426A-9444-51C81E8EBE59@wirtel.be> + +Message-ID: <864BDA07-F0F6-43A3-8D6C-12056DFE6C5E@wirtel.be> + +Ok I will try asap, thanks + +> On 24 ao?t 2014, at 02:25 AM, Eduardo Gurgel wrote: +> +> I think you can always halt the processing and do the reply by yourself: +> +> {ok, Req2} = cowboy_req:reply(412, Req), +> {halt, Req2, State}. +> +> +>> On Sun, Aug 24, 2014 at 12:22 PM, St?phane Wirtel wrote: +>> resource_exists is used by POST +>> is_conflict is used by PUT (from the code) +>> but in the case where my database already exists, I need to return 412 and not 409. +>> +>> and I know I don't respect the default value returned by Cowboy_rest. +>> +>> +>> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote: +>> +>>> You should implement the resource_exists() callback; this will let the rest +>>> module pick a 200 vs 201. If the db name was incorrect, I think you are +>>> just supposed to return false from the put callback. I can't remember the +>>> http code for that case. +>>> +>>> Regards, +>>> Dan. +>>> +>>> +>>> On Sat, Aug 23, 2014 at 6:58 PM, St?phane Wirtel wrote: +>>> +>>>> Hi all, +>>>> +>>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have +>>>> a small crash. +>>>> +>>>> Here is my code: +>>>> +>>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4 +>>>> +>>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have +>>>> seen is_conflict/2, but I don't know how to use it. +>>>> +>>>> 2. I would like to change the response code, but I get the error. Is it +>>>> possible? +>>>> +>>>> Thank you. +>>>> +>>>> Regards, +>>>> +>>>> Stephane +>>>> +>>>> -- +>>>> St?phane Wirtel - http://wirtel.be - @matrixise +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> +> +> +> -- +> Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From stephane at wirtel.be Sun Aug 24 11:54:58 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Sun, 24 Aug 2014 11:54:58 +0200 +Subject: [99s-extend] Full example of cowboy_rest? +Message-ID: + +Hi all, + +Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, +PUT and DELETE ? + +POST will use resource_exists and allow_missing_post +PUT will use is_conflict +DELETE delete_resource, etc... + +Currently, I started with the example with put_json and get_json and in +the functions, I fetch the Method and I use the pattern matching with +the Method, but I think it's not the right solution. + +What are the best practices? + +The examples in the repository of cowboy don't cover all the +possibilities of a simple rest api with these verbs. + +Thanks in advance, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From paulo.ferraz.oliveira at gmail.com Tue Aug 26 01:11:44 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 26 Aug 2014 00:11:44 +0100 +Subject: [99s-extend] Full example of cowboy_rest? +In-Reply-To: +References: +Message-ID: + +Hello, St?phane. + +On 24 August 2014 10:54, St?phane Wirtel wrote: +> +> Hi all, +> +> Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, PUT and DELETE ? + +AFAIK, from the official examples, the correct answer is "no", there +is no "complete" example (does it even make sense to have one?). + +On the other hand, I've been using Cowboy for a couple of months now, +and find these docs (REST flowcharts - +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/) to be +very useful, and they might also help you. You should find the time to +read the complete REST guide/manual as a lot of useful information can +be found there and a very nice effort was put into not wasting words +and going straight to the point. + +... + +> What are the best practices? + +For what specifically? + +> The examples in the repository of cowboy don't cover all the possibilities of a simple rest api with these verbs. + +That is a fact. I, for one, tend to have a _template_ source code file +from where I get the functions that I need (only not to have to write +2/3 lines of code every time), and that I "chain" looking at the +flowcharts. [I also have a lib for JSON parsing and validating, query +string validation, etc...] This might not always be very easy (to +"chain" it all together, but it shouldn't be that hard either"), but +my approach is usually "OK, so I want a route to have GET, PUT and +DELETE... what are the related methods that I'll most probably +require? resource_exists (serves all methods), is_conflict (serves +PUT), delete_resource (serves DELETE), delete_completed (serves +DELETE)" and then I think about replying with a body or not (in the +case of GET there will almost always be a body, in the case of PUT +your method call might result in a 204 and in the case of DELETE there +may or not be a body). I then code the methods, test the API, checking +that the codes I get make sense (404, 200, 409, 204, 202, ... +depending on the conditions I want set) and then slightly document +this for the users of the API (if the API is complicated and requires +a lot of documentation there might be something wrong with it). For +documentation purposes you can either go with a "[VERB] route +accepts...?..., serves...?..., and the result codes are...?..." simple +doc or something more elaborate like +https://helloreverb.com/developers/swagger. + +Hope it helps. + +- Paulo F. Oliveira + +> +> Thanks in advance, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +From stephane at wirtel.be Tue Aug 26 23:59:50 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Tue, 26 Aug 2014 23:59:50 +0200 +Subject: [99s-extend] cowboy_rest and delete_completed and response +Message-ID: <1E843973-E0BD-41FA-AC69-53BEECAD5489@wirtel.be> + +Hi all, + +I work with two content-types (json, msgpack). + +In the DELETE verb, I need to return an object and in this case, I work +on delete_resource/2 and delete_completed/2. +The problem is, how can I return a body in function of the content-type? +because after delete_completed, there is a call to the +cowboy_rest:has_resp_body function and I need to set the body of the +response. + +delete_completed(Req, State) -> + Body = Json or MsgPack ? <-- Which content ? + + Req2 = cowboy_req:set_resp_body(Body, Req), + {true, Req2, State}. + +Ok, but in this case, what's the reason of content_types_provided/2 and +content_types_accepted/2 ? + +Thank you, + +Stephane + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 00:03:45 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 01:03:45 +0300 +Subject: [99s-extend] cowboy_rest and delete_completed and response +In-Reply-To: <1E843973-E0BD-41FA-AC69-53BEECAD5489@wirtel.be> +References: <1E843973-E0BD-41FA-AC69-53BEECAD5489@wirtel.be> +Message-ID: <53FD0441.1070701@ninenines.eu> + +Call cowboy_req:meta(media_type, Req) to retrieve it. + +On 08/27/2014 12:59 AM, St?phane Wirtel wrote: +> Hi all, +> +> I work with two content-types (json, msgpack). +> +> In the DELETE verb, I need to return an object and in this case, I work +> on delete_resource/2 and delete_completed/2. +> The problem is, how can I return a body in function of the content-type? +> because after delete_completed, there is a call to the +> cowboy_rest:has_resp_body function and I need to set the body of the +> response. +> +> delete_completed(Req, State) -> +> Body = Json or MsgPack ? <-- Which content ? +> +> Req2 = cowboy_req:set_resp_body(Body, Req), +> {true, Req2, State}. +> +> Ok, but in this case, what's the reason of content_types_provided/2 and +> content_types_accepted/2 ? +> +> Thank you, +> +> Stephane +> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 00:12:00 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 00:12:00 +0200 +Subject: [99s-extend] cowboy_rest and delete_completed and response +In-Reply-To: <53FD0441.1070701@ninenines.eu> +References: <1E843973-E0BD-41FA-AC69-53BEECAD5489@wirtel.be> + <53FD0441.1070701@ninenines.eu> +Message-ID: <90BE6FF2-659A-487A-AB91-C968658CE3D3@wirtel.be> + +What's the purpose of the callbacks in content_types_accepted and +content_types_provided? + +I prefer set the response in the State to the callbacks and they convert +it to the right format. + +Example: + +delete_completed(Req, State) -> + Response = [{<<"ok">>, <<"dbname">>}], + {true, Req, State#state{response=Response}}. + +get_json(Req, #{response=Response}=State) -> + Body = jsx:encode(Response), + {Body, Req, State}. + +get_msgpack(Req, #{response=Response}=State) -> + Body = msgpack:pack(Response, [{format, jsx}], + {Body, Req, State}. + + + +On 27 Aug 2014, at 0:03, Lo?c Hoguin wrote: + +> Call cowboy_req:meta(media_type, Req) to retrieve it. +> +> On 08/27/2014 12:59 AM, St?phane Wirtel wrote: +>> Hi all, +>> +>> I work with two content-types (json, msgpack). +>> +>> In the DELETE verb, I need to return an object and in this case, I +>> work +>> on delete_resource/2 and delete_completed/2. +>> The problem is, how can I return a body in function of the +>> content-type? +>> because after delete_completed, there is a call to the +>> cowboy_rest:has_resp_body function and I need to set the body of the +>> response. +>> +>> delete_completed(Req, State) -> +>> Body = Json or MsgPack ? <-- Which content ? +>> +>> Req2 = cowboy_req:set_resp_body(Body, Req), +>> {true, Req2, State}. +>> +>> Ok, but in this case, what's the reason of content_types_provided/2 +>> and +>> content_types_accepted/2 ? +>> +>> Thank you, +>> +>> Stephane +>> +>> +>> -- +>> St?phane Wirtel - http://wirtel.be - @matrixise +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From stephane at wirtel.be Wed Aug 27 11:29:46 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 11:29:46 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest handler. +Message-ID: + +Hi all, + +This night, I wrote an example because I wanted to show you my work. + +I have one handler for the concept of collections (in this case, tasks). + +In this handler, I want these following methods: + +POST /:collection +GET /:collection +DELETE /:collection +PUT /:collection +HEAD /:collection + +:collection is a string, example: /tasks1 + +HEAD /:collection (/tasks1) +StatusCode: + * 200 ok + * 404 not found + +GET /:collection (/tasks1) +Gets information about the collection +StatusCode: + * 200 ok + * 404 not found + +PUT /:collection (/tasks1) +Create a new collection of tasks +Status_Code: + * 201 created + Response: an object, in msgpack or json and I need to had a location +header + * 412 precondition failed, the collection name already exists + Response: an object, in msgpack or json with the error (already exists) + +POST /:collection (/tasks1) +Add a new item in the collection, a new task +StatusCode: + * 201 created + * 202 accepted + * 404 not found (error in the collection name) +Response: need to add a location header and return an object in msgpack +or json. + +DELETE /:collection (/tasks1) +Delete all the tasks +Status_Code: + * 200 ok. + * 404 not found +In the case of 200, we need to return an object in msgpack or json. + + +I provided a code and If you can help me, because I think cowboy_rest is +a good solution, but I also think I will have some problems with my +service. + +Examples: +* delete_completed, I need to write the serialisation in the +delete_completed function and not with the help of the defined callbacks +of content_types_provided. +* for PUT, I need to return a location header, should I add it in the +is_conflict +function? +* for PUT, how I have a 201? I have read the rest_flowchart and I need +to specify the location header ok, but where? in the is_conflict +function? + +So, do you have time to help me, because with this example, I can +propose it to the cowboy repository. +https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl + +You can propose your PR, comments or remarks, but I would like to use +cowboy_rest. + +Regards, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 12:03:41 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 13:03:41 +0300 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: +References: +Message-ID: <53FDACFD.7020204@ninenines.eu> + +Hey, + +On 08/27/2014 12:29 PM, St?phane Wirtel wrote: +> Hi all, +> +> This night, I wrote an example because I wanted to show you my work. +> +> I have one handler for the concept of collections (in this case, tasks). +> +> In this handler, I want these following methods: +> +> POST /:collection +> GET /:collection +> DELETE /:collection +> PUT /:collection +> HEAD /:collection +> +> :collection is a string, example: /tasks1 +> +> HEAD /:collection (/tasks1) +> StatusCode: +> * 200 ok +> * 404 not found +> +> GET /:collection (/tasks1) +> Gets information about the collection +> StatusCode: +> * 200 ok +> * 404 not found +> +> PUT /:collection (/tasks1) +> Create a new collection of tasks +> Status_Code: +> * 201 created +> Response: an object, in msgpack or json and I need to had a +> location header +> * 412 precondition failed, the collection name already exists +> Response: an object, in msgpack or json with the error (already +> exists) +> +> POST /:collection (/tasks1) +> Add a new item in the collection, a new task +> StatusCode: +> * 201 created +> * 202 accepted +> * 404 not found (error in the collection name) +> Response: need to add a location header and return an object in msgpack +> or json. +> +> DELETE /:collection (/tasks1) +> Delete all the tasks +> Status_Code: +> * 200 ok. +> * 404 not found +> In the case of 200, we need to return an object in msgpack or json. +> +> +> I provided a code and If you can help me, because I think cowboy_rest is +> a good solution, but I also think I will have some problems with my +> service. +> +> Examples: +> * delete_completed, I need to write the serialisation in the +> delete_completed function and not with the help of the defined callbacks +> of content_types_provided. + +What's the problem? The callbacks you set in content_types_provided are +there to provide the *resource*. If you set a body in response to the +DELETE method you are not sending the resource but information about the +result of the operation. + +> * for PUT, I need to return a location header, should I add it in the +> is_conflict +> function? + +I would say in the callback you set in content_types_accepted. But... + +> * for PUT, how I have a 201? I have read the rest_flowchart and I need +> to specify the location header ok, but where? in the is_conflict function? + +Why do you need a 201? If you PUT a collection to /:collection then this +is already the location of the collection. I am not sure what you are +trying to do there exactly? + +> So, do you have time to help me, because with this example, I can +> propose it to the cowboy repository. +> https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl +> +> +> You can propose your PR, comments or remarks, but I would like to use +> cowboy_rest. +> +> Regards, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 12:35:33 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 12:35:33 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <53FDACFD.7020204@ninenines.eu> +References: + <53FDACFD.7020204@ninenines.eu> +Message-ID: + +On 27 Aug 2014, at 12:03, Lo?c Hoguin wrote: + +> Hey, +> +> On 08/27/2014 12:29 PM, St?phane Wirtel wrote: +>> Hi all, +>> +>> This night, I wrote an example because I wanted to show you my work. +>> +>> I have one handler for the concept of collections (in this case, +>> tasks). +>> +>> In this handler, I want these following methods: +>> +>> POST /:collection +>> GET /:collection +>> DELETE /:collection +>> PUT /:collection +>> HEAD /:collection +>> +>> :collection is a string, example: /tasks1 +>> +>> HEAD /:collection (/tasks1) +>> StatusCode: +>> * 200 ok +>> * 404 not found +>> +>> GET /:collection (/tasks1) +>> Gets information about the collection +>> StatusCode: +>> * 200 ok +>> * 404 not found +>> +>> PUT /:collection (/tasks1) +>> Create a new collection of tasks +>> Status_Code: +>> * 201 created +>> Response: an object, in msgpack or json and I need to had a +>> location header +>> * 412 precondition failed, the collection name already exists +>> Response: an object, in msgpack or json with the error (already +>> exists) +>> +>> POST /:collection (/tasks1) +>> Add a new item in the collection, a new task +>> StatusCode: +>> * 201 created +>> * 202 accepted +>> * 404 not found (error in the collection name) +>> Response: need to add a location header and return an object in +>> msgpack +>> or json. +>> +>> DELETE /:collection (/tasks1) +>> Delete all the tasks +>> Status_Code: +>> * 200 ok. +>> * 404 not found +>> In the case of 200, we need to return an object in msgpack or json. +>> +>> +>> I provided a code and If you can help me, because I think cowboy_rest +>> is +>> a good solution, but I also think I will have some problems with my +>> service. +>> +>> Examples: +>> * delete_completed, I need to write the serialisation in the +>> delete_completed function and not with the help of the defined +>> callbacks +>> of content_types_provided. +> +> What's the problem? The callbacks you set in content_types_provided +> are there to provide the *resource*. If you set a body in response to +> the DELETE method you are not sending the resource but information +> about the result of the operation. +Ok, in this case, I understand. thanks +> +>> * for PUT, I need to return a location header, should I add it in the +>> is_conflict +>> function? +> +> I would say in the callback you set in content_types_accepted. But... +Works fine in the is_conflict function. +> +>> * for PUT, how I have a 201? I have read the rest_flowchart and I +>> need +>> to specify the location header ok, but where? in the is_conflict +>> function? +> +> Why do you need a 201? If you PUT a collection to /:collection then +> this is already the location of the collection. I am not sure what you +> are trying to do there exactly? +In this case, the PUT method is used for the creation of the resource +and not for the update. This is the reason of the 201 status code. + +In the rest_flowchart graph for the PUT/POST methods, what is the node +"new resource" ? Is it just the {true, Req, State} from the callback +defined in the content_types_accepted? + +PS: I retested and now, I have my 201 with PUT, just resource_exists has +to return false and not true ;-) + +Thanks + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 12:53:19 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 27 Aug 2014 13:53:19 +0300 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: +References: + <53FDACFD.7020204@ninenines.eu> + +Message-ID: <53FDB89F.2080308@ninenines.eu> + +>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need +>>> to specify the location header ok, but where? in the is_conflict +>>> function? +>> +>> Why do you need a 201? If you PUT a collection to /:collection then +>> this is already the location of the collection. I am not sure what you +>> are trying to do there exactly? +> In this case, the PUT method is used for the creation of the resource +> and not for the update. This is the reason of the 201 status code. +> +> In the rest_flowchart graph for the PUT/POST methods, what is the node +> "new resource" ? Is it just the {true, Req, State} from the callback +> defined in the content_types_accepted? +> +> PS: I retested and now, I have my 201 with PUT, just resource_exists has +> to return false and not true ;-) + +My bad I was a little confusing in my previous answer. You are right, if +the resource doesn't exist and PUT is used we get a 201 automatically. +The location header must only be provided if the resource was created +elsewhere. + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 15:26:11 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 15:26:11 +0200 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <53FDB89F.2080308@ninenines.eu> +References: + <53FDACFD.7020204@ninenines.eu> + + <53FDB89F.2080308@ninenines.eu> +Message-ID: <426265B5-9DC3-4068-A377-C3B4441A6F45@wirtel.be> + +On 27 Aug 2014, at 12:53, Lo?c Hoguin wrote: + +>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I +>>>> need +>>>> to specify the location header ok, but where? in the is_conflict +>>>> function? +>>> +>>> Why do you need a 201? If you PUT a collection to /:collection then +>>> this is already the location of the collection. I am not sure what +>>> you +>>> are trying to do there exactly? +>> In this case, the PUT method is used for the creation of the resource +>> and not for the update. This is the reason of the 201 status code. +>> +>> In the rest_flowchart graph for the PUT/POST methods, what is the +>> node +>> "new resource" ? Is it just the {true, Req, State} from the callback +>> defined in the content_types_accepted? +>> +>> PS: I retested and now, I have my 201 with PUT, just resource_exists +>> has +>> to return false and not true ;-) +> +> My bad I was a little confusing in my previous answer. You are right, +> if the resource doesn't exist and PUT is used we get a 201 +> automatically. The location header must only be provided if the +> resource was created elsewhere. + +Don't worry and thank you for your answers. + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From a.brandon.clark at gmail.com Wed Aug 27 21:06:25 2014 +From: a.brandon.clark at gmail.com (Brandon Clark) +Date: Wed, 27 Aug 2014 12:06:25 -0700 +Subject: [99s-extend] Which erlang.mk? +Message-ID: + +Greetings! + +I'm trying to resurrect one of my neglected ranch applications. It uses +Common Test, erlang.mk, and relx all in the usual way. When I run make +tests with all fresh dependencies, I get this: + +Doing /home/brandon/src/my_proj/deps/ranch... + +make[1]: *** No rule to make target `build-tests'. Stop. + +make: *** [build-deps-tests] Error 2 + + +A diff of my erlang.mk and deps/ranch/erlang.mk shows they are dramatically +different. Mine came from here just this morning: + +https://raw.*github.com */extend/ +erlang.mk/master/erlang.mk + +Which one is the "right" one for creating new apps? + + +Thank you! + +~BC +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Aug 27 23:26:26 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 28 Aug 2014 00:26:26 +0300 +Subject: [99s-extend] Which erlang.mk? +In-Reply-To: +References: +Message-ID: <53FE4D02.9050804@ninenines.eu> + +The one you downloaded from github is the correct one. It's a new +version compared to the older one. A few small things changed, +including, in this case, that build-tests was renamed to something like +ct-build-tests (please open it to make sure of the name). + +The new version allows greater customization and has a better package +index feature and other things, but breaking compatibility with older +Makefiles. The new version is labeled 1 (beginning of erlang.mk file) +while the older one has no such label. + +On 08/27/2014 10:06 PM, Brandon Clark wrote: +> Greetings! +> +> I'm trying to resurrect one of my neglected ranch applications. It uses +> Common Test, erlang.mk , and relx all in the usual +> way. When I run make tests with all fresh dependencies, I get this: +> +> Doing /home/brandon/src/my_proj/deps/ranch... +> +> make[1]: *** No rule to make target `build-tests'. Stop. +> +> make: *** [build-deps-tests] Error 2 +> +> +> A diff of my erlang.mk and deps/ranch/erlang.mk +> shows they are dramatically different. Mine came +> from here just this morning: +> +> https://raw._github.com +> _/extend/erlang.mk/master/erlang.mk +> +> +> Which one is the "right" one for creating new apps? +> +> +> Thank you! +> +> ~BC +> +> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Wed Aug 27 23:41:25 2014 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Wed, 27 Aug 2014 23:41:25 +0200 +Subject: [99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ? +Message-ID: <5F045BA1-B52D-43BD-8E61-061CD2B4DFC9@wirtel.be> + +Hi all, + +For the PUT method, the flow is + +resource_exists +if method == PUT then go to the is_conflict function. +In each function, we need to check if the resource already exists or not. + +I think we check twice, is it normal? + +Thank you, + +Stephane + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From essen at ninenines.eu Wed Aug 27 23:48:41 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 28 Aug 2014 00:48:41 +0300 +Subject: [99s-extend] cowboy_rest : PUT and resource_exists vs + is_conflict ? +In-Reply-To: <5F045BA1-B52D-43BD-8E61-061CD2B4DFC9@wirtel.be> +References: <5F045BA1-B52D-43BD-8E61-061CD2B4DFC9@wirtel.be> +Message-ID: <53FE5239.6080008@ninenines.eu> + +For some callbacks you may need to check but only if you need to perform +a different operation when it does/doesn't. For example if you write to +files a PUT is the same operation either way, but if you write to an SQL +DB you will want to do INSERT/UPDATE depending on that. Same goes for +is_conflict and others, it depends. + +So sometimes you need to keep that info around in the state and +sometimes you don't. + +On 08/28/2014 12:41 AM, St?phane Wirtel wrote: +> Hi all, +> +> For the PUT method, the flow is +> +> resource_exists +> if method == PUT then go to the is_conflict function. +> In each function, we need to check if the resource already exists or not. +> +> I think we check twice, is it normal? +> +> Thank you, +> +> Stephane +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Sat Aug 30 00:15:56 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Fri, 29 Aug 2014 23:15:56 +0100 +Subject: [99s-extend] I need your feedback about this cowboy_rest + handler. +In-Reply-To: <426265B5-9DC3-4068-A377-C3B4441A6F45@wirtel.be> +References: + <53FDACFD.7020204@ninenines.eu> + + <53FDB89F.2080308@ninenines.eu> + <426265B5-9DC3-4068-A377-C3B4441A6F45@wirtel.be> +Message-ID: + +PUT _should_ (there is no police here though) be used to either create +a resource or completely update it (it's refered to as "upsert" by +some; in Redis, for example, a similar concept would be "set"). +Partial modifications should be made using PATCH. POST is what is +commonly used to create a resource. According to +http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 412 is used +when "[t]he precondition given in one or more of the request-header +fields evaluated to false when it was tested on the server." (also: +http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24). + +- Paulo F. Oliveira + +On 27 August 2014 14:26, St?phane Wirtel wrote: +> On 27 Aug 2014, at 12:53, Lo?c Hoguin wrote: +> +>>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need +>>>>> to specify the location header ok, but where? in the is_conflict +>>>>> function? +>>>> +>>>> +>>>> Why do you need a 201? If you PUT a collection to /:collection then +>>>> this is already the location of the collection. I am not sure what you +>>>> are trying to do there exactly? +>>> +>>> In this case, the PUT method is used for the creation of the resource +>>> and not for the update. This is the reason of the 201 status code. +>>> +>>> In the rest_flowchart graph for the PUT/POST methods, what is the node +>>> "new resource" ? Is it just the {true, Req, State} from the callback +>>> defined in the content_types_accepted? +>>> +>>> PS: I retested and now, I have my 201 with PUT, just resource_exists has +>>> to return false and not true ;-) +>> +>> +>> My bad I was a little confusing in my previous answer. You are right, if +>> the resource doesn't exist and PUT is used we get a 201 automatically. The +>> location header must only be provided if the resource was created elsewhere. +> +> +> Don't worry and thank you for your answers. +> +> Stephane +> +> +> -- +> St?phane Wirtel - http://wirtel.be - @matrixise +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + diff --git a/_build/static/archives/extend/2014-August/000417.html b/_build/static/archives/extend/2014-August/000417.html new file mode 100644 index 00000000..591df4e1 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000417.html @@ -0,0 +1,88 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Samir Sow + samset at wanadoo.fr +
+ Mon Aug 4 18:39:26 CEST 2014 +

+
+ +
Hi,
+
+I’ve moved a working http server to https.
+SSL handshaking is ok but i got the following Ranch error :
+
+[error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+
+call is
+
+curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+
+
+dispatch is 
+
+[{'_', [
+        {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+        {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+	{"/mtagw", hck_mta, []}
+    ]}]).
+
+
+Any clue ?
+
+Thanks
+
+sincerely
+
+Samir
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000418.html b/_build/static/archives/extend/2014-August/000418.html new file mode 100644 index 00000000..809f37a0 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000418.html @@ -0,0 +1,105 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Aug 4 18:49:32 CEST 2014 +

+
+ +
Surely there's something else that you're not showing there. For some 
+reason you got a list of segments in the error, and we haven't had that 
+for a very long time. Do you have an onrequest hook or middleware that 
+does weird things perhaps?
+
+On 08/04/2014 06:39 PM, Samir Sow wrote:
+> Hi,
+>
+> I’ve moved a working http server to https.
+> SSL handshaking is ok but i got the following Ranch error :
+>
+> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>
+> call is
+>
+> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>
+>
+> dispatch is
+>
+> [{'_', [
+>          {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>          {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+> 	{"/mtagw", hck_mta, []}
+>      ]}]).
+>
+>
+> Any clue ?
+>
+> Thanks
+>
+> sincerely
+>
+> Samir
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000419.html b/_build/static/archives/extend/2014-August/000419.html new file mode 100644 index 00000000..5b7554e4 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000419.html @@ -0,0 +1,114 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Samir Sow + samset at wanadoo.fr +
+ Mon Aug 4 19:50:36 CEST 2014 +

+
+ +
I’m not sure i understand your question.
+
+I’ve only started a cowboy https server with a handler.
+The http version was working fine.
+
+Sincerely
+
+Samir
+
+On 4 août 2014, at 18:49, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps?
+> 
+> On 08/04/2014 06:39 PM, Samir Sow wrote:
+>> Hi,
+>> 
+>> I’ve moved a working http server to https.
+>> SSL handshaking is ok but i got the following Ranch error :
+>> 
+>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>> 
+>> call is
+>> 
+>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>> 
+>> 
+>> dispatch is
+>> 
+>> [{'_', [
+>>         {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>>         {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+>> 	{"/mtagw", hck_mta, []}
+>>     ]}]).
+>> 
+>> 
+>> Any clue ?
+>> 
+>> Thanks
+>> 
+>> sincerely
+>> 
+>> Samir
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000420.html b/_build/static/archives/extend/2014-August/000420.html new file mode 100644 index 00000000..5f08fd62 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000420.html @@ -0,0 +1,121 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Aug 4 19:59:57 CEST 2014 +

+
+ +
I'm saying it can't be the only difference.
+
+On 08/04/2014 07:50 PM, Samir Sow wrote:
+> I’m not sure i understand your question.
+>
+> I’ve only started a cowboy https server with a handler.
+> The http version was working fine.
+>
+> Sincerely
+>
+> Samir
+>
+> On 4 août 2014, at 18:49, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps?
+>>
+>> On 08/04/2014 06:39 PM, Samir Sow wrote:
+>>> Hi,
+>>>
+>>> I’ve moved a working http server to https.
+>>> SSL handshaking is ok but i got the following Ranch error :
+>>>
+>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>>>
+>>> call is
+>>>
+>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>>>
+>>>
+>>> dispatch is
+>>>
+>>> [{'_', [
+>>>          {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>>>          {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+>>> 	{"/mtagw", hck_mta, []}
+>>>      ]}]).
+>>>
+>>>
+>>> Any clue ?
+>>>
+>>> Thanks
+>>>
+>>> sincerely
+>>>
+>>> Samir
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000421.html b/_build/static/archives/extend/2014-August/000421.html new file mode 100644 index 00000000..96719127 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000421.html @@ -0,0 +1,128 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Samir Sow + samset at wanadoo.fr +
+ Mon Aug 4 20:16:06 CEST 2014 +

+
+ +
I can assure you it’s the only one :)
+
+Samir
+
+On 4 août 2014, at 19:59, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> I'm saying it can't be the only difference.
+> 
+> On 08/04/2014 07:50 PM, Samir Sow wrote:
+>> I’m not sure i understand your question.
+>> 
+>> I’ve only started a cowboy https server with a handler.
+>> The http version was working fine.
+>> 
+>> Sincerely
+>> 
+>> Samir
+>> 
+>> On 4 août 2014, at 18:49, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> 
+>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps?
+>>> 
+>>> On 08/04/2014 06:39 PM, Samir Sow wrote:
+>>>> Hi,
+>>>> 
+>>>> I’ve moved a working http server to https.
+>>>> SSL handshaking is ok but i got the following Ranch error :
+>>>> 
+>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>>>> 
+>>>> call is
+>>>> 
+>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>>>> 
+>>>> 
+>>>> dispatch is
+>>>> 
+>>>> [{'_', [
+>>>>         {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>>>>         {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+>>>> 	{"/mtagw", hck_mta, []}
+>>>>     ]}]).
+>>>> 
+>>>> 
+>>>> Any clue ?
+>>>> 
+>>>> Thanks
+>>>> 
+>>>> sincerely
+>>>> 
+>>>> Samir
+>>>> 
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> https://lists.ninenines.eu/listinfo/extend
+>>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000422.html b/_build/static/archives/extend/2014-August/000422.html new file mode 100644 index 00000000..e23681d9 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000422.html @@ -0,0 +1,137 @@ + + + + [99s-extend] ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] ranch dispatch error ver 1.0.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Aug 4 20:24:15 CEST 2014 +

+
+ +
Well I don't have any idea then. Cowboy is tested with http and https, 
+both with and without compression enabled. There's never been any 
+difference of the kind, the only difference is timing related.
+
+On 08/04/2014 08:16 PM, Samir Sow wrote:
+> I can assure you it’s the only one :)
+>
+> Samir
+>
+> On 4 août 2014, at 19:59, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> I'm saying it can't be the only difference.
+>>
+>> On 08/04/2014 07:50 PM, Samir Sow wrote:
+>>> I’m not sure i understand your question.
+>>>
+>>> I’ve only started a cowboy https server with a handler.
+>>> The http version was working fine.
+>>>
+>>> Sincerely
+>>>
+>>> Samir
+>>>
+>>> On 4 août 2014, at 18:49, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>
+>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps?
+>>>>
+>>>> On 08/04/2014 06:39 PM, Samir Sow wrote:
+>>>>> Hi,
+>>>>>
+>>>>> I’ve moved a working http server to https.
+>>>>> SSL handshaking is ok but i got the following Ranch error :
+>>>>>
+>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>>>>>
+>>>>> call is
+>>>>>
+>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>>>>>
+>>>>>
+>>>>> dispatch is
+>>>>>
+>>>>> [{'_', [
+>>>>>          {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>>>>>          {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+>>>>> 	{"/mtagw", hck_mta, []}
+>>>>>      ]}]).
+>>>>>
+>>>>>
+>>>>> Any clue ?
+>>>>>
+>>>>> Thanks
+>>>>>
+>>>>> sincerely
+>>>>>
+>>>>> Samir
+>>>>>
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> http://ninenines.eu
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000423.html b/_build/static/archives/extend/2014-August/000423.html new file mode 100644 index 00000000..f7bb6c65 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000423.html @@ -0,0 +1,149 @@ + + + + [99s-extend] Fwd: ranch dispatch error ver 1.0.0 + + + + + + + + + + +

[99s-extend] Fwd: ranch dispatch error ver 1.0.0

+ Samir Sow + samset at wanadoo.fr +
+ Mon Aug 4 20:25:25 CEST 2014 +

+
+ +
+I found my mistake.
+
+I’ve a typo error - used a token instead of a function call in the dispatch object.
+I apologize for the disturbance.
+
+Thank you.
+
+Sincerely
+
+Samir
+
+Begin forwarded message:
+
+> From: Samir Sow <samset at wanadoo.fr>
+> Subject: Re: [99s-extend] ranch dispatch error ver 1.0.0
+> Date: 4 août 2014 20:16:06 UTC+2
+> To: Loïc Hoguin <essen at ninenines.eu>
+> Cc: extend at lists.ninenines.eu
+> 
+> I can assure you it’s the only one :)
+> 
+> Samir
+> 
+> On 4 août 2014, at 19:59, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+>> I'm saying it can't be the only difference.
+>> 
+>> On 08/04/2014 07:50 PM, Samir Sow wrote:
+>>> I’m not sure i understand your question.
+>>> 
+>>> I’ve only started a cowboy https server with a handler.
+>>> The http version was working fine.
+>>> 
+>>> Sincerely
+>>> 
+>>> Samir
+>>> 
+>>> On 4 août 2014, at 18:49, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>>> Surely there's something else that you're not showing there. For some reason you got a list of segments in the error, and we haven't had that for a very long time. Do you have an onrequest hook or middleware that does weird things perhaps?
+>>>> 
+>>>> On 08/04/2014 06:39 PM, Samir Sow wrote:
+>>>>> Hi,
+>>>>> 
+>>>>> I’ve moved a working http server to https.
+>>>>> SSL handshaking is ok but i got the following Ranch error :
+>>>>> 
+>>>>> [error] Ranch listener https_mta had connection process started with cowboy_protocol:start_link/4 at <0.601.0> exit with reason: {badarg,[{binary,match,[[<<"com">>,<<"oockit">>,<<"www">>],<<".">>],[]},{cowboy_router,split_host,2,[{file,"src/cowboy_router.erl"},{line,305}]},{cowboy_router,match,3,[{file,"src/cowboy_router.erl"},{line,240}]},{cowboy_router,execute,2,[{file,"src/cowboy_router.erl"},{line,169}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]}
+>>>>> 
+>>>>> call is
+>>>>> 
+>>>>> curl --cacert priv/cert/root.crt "https://www.oockit.com:7171/mtagw?
+>>>>> 
+>>>>> 
+>>>>> dispatch is
+>>>>> 
+>>>>> [{'_', [
+>>>>>        {["/static/[...]"], cowboy_static, [{directory, {priv_dir, ?APP, [<<"static">>]}},
+>>>>>        {mimetypes, {fun mimetypes:path_to_mimes/2, default}}]},
+>>>>> 	{"/mtagw", hck_mta, []}
+>>>>>    ]}]).
+>>>>> 
+>>>>> 
+>>>>> Any clue ?
+>>>>> 
+>>>>> Thanks
+>>>>> 
+>>>>> sincerely
+>>>>> 
+>>>>> Samir
+>>>>> 
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>> 
+>>>> 
+>>>> --
+>>>> Loïc Hoguin
+>>>> http://ninenines.eu
+>>> 
+>> 
+>> -- 
+>> Loïc Hoguin
+>> http://ninenines.eu
+> 
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000424.html b/_build/static/archives/extend/2014-August/000424.html new file mode 100644 index 00000000..5118e1ad --- /dev/null +++ b/_build/static/archives/extend/2014-August/000424.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Broken links for REST flowcharts + + + + + + + + + + +

[99s-extend] Broken links for REST flowcharts

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Aug 5 12:58:10 CEST 2014 +

+
+ +
Hi.
+
+The image links are broken for the REST flowcharts' guide, part of cowboy.
+
+http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png
+(for example)
+should probably be
+http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png
+according to the hierarchy here:
+https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide
+
+Thanks.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/2c08b12c/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000425.html b/_build/static/archives/extend/2014-August/000425.html new file mode 100644 index 00000000..1991924d --- /dev/null +++ b/_build/static/archives/extend/2014-August/000425.html @@ -0,0 +1,89 @@ + + + + [99s-extend] Broken links for REST flowcharts + + + + + + + + + + +

[99s-extend] Broken links for REST flowcharts

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Aug 5 13:19:12 CEST 2014 +

+
+ +
Fixed, thanks.
+
+On 08/05/2014 12:58 PM, Paulo F. Oliveira wrote:
+> Hi.
+>
+> The image links are broken for the REST flowcharts' guide, part of cowboy.
+>
+> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/rest_start.png
+> (for example)
+> should probably be
+> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_start.png
+> according to the hierarchy here:
+> https://github.com/ninenines/ninenines.github.io/tree/master/docs/en/cowboy/1.0/guide
+>
+> Thanks.
+>
+> - Paulo F. Oliveira
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000426.html b/_build/static/archives/extend/2014-August/000426.html new file mode 100644 index 00000000..8f3db309 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000426.html @@ -0,0 +1,119 @@ + + + + [99s-extend] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy 1.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Aug 5 14:43:47 CEST 2014 +

+
+ +
Hello!
+
+Cowboy 1.0 has been released.
+
+Cowboy is a small and fast HTTP server for Erlang with support for 
+Webmachine-like REST, Websocket and more.
+
+   https://github.com/ninenines/cowboy
+
+Cowboy is the work of more than 80 people. I would like to congratulate 
+everyone for the great work done so far. Thank you!
+
+Please see the CHANGELOG for details on what's changed.
+
+   https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md
+
+This release marks the beginning of the 1.0.x branch which will contain 
+backward compatible fixes. This branch will be maintained at least until 
+Cowboy 2.0 gets released (longer if sponsors request it). It is highly 
+recommended that you follow this branch if you were following master 
+before, as master will receive backward incompatible changes starting 
+tomorrow.
+
+Cowboy is now fully documented. It has a user guide, a function 
+reference manual, and a wealth of examples. You can also install man 
+pages as explained in the README of the project.
+
+   http://ninenines.eu/docs/en/cowboy/1.0/guide/
+   http://ninenines.eu/docs/en/cowboy/1.0/manual/
+   https://github.com/ninenines/cowboy/tree/master/examples
+
+Following a discussion on the Erlang mailing lists the Getting Started 
+chapter was reworked and greatly simplified, in parts due to the 
+improvements made to erlang.mk. Feedback is of course always welcome.
+
+   http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/
+
+Starting tomorrow the master branch will receive backward incompatible 
+changes. Most of the planned changes are detailed in the ROADMAP. You 
+are welcome to suggest additional changes.
+
+   https://github.com/ninenines/cowboy/blob/master/ROADMAP.md
+
+Cowboy 2.0 is planned to be released at around the same time Erlang/OTP 
+18.0 comes out. There are no plans for a Cowboy 1.1 at this time, 
+although that may change in the coming months if there is interest in 
+new features.
+
+Ranch also got upgraded to 1.0, although there was no changes from the 
+previous release.
+
+   https://github.com/ninenines/ranch
+
+Thanks to everyone who made this project what it is today!
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000427.html b/_build/static/archives/extend/2014-August/000427.html new file mode 100644 index 00000000..c11add6d --- /dev/null +++ b/_build/static/archives/extend/2014-August/000427.html @@ -0,0 +1,68 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Max Lapshin + max.lapshin at gmail.com +
+ Tue Aug 5 15:33:27 CEST 2014 +

+
+ +
Loic, it is very cool!
+
+Thanks.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/a3d520b7/attachment.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000428.html b/_build/static/archives/extend/2014-August/000428.html new file mode 100644 index 00000000..f46a98ce --- /dev/null +++ b/_build/static/archives/extend/2014-August/000428.html @@ -0,0 +1,138 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Jesse Gumm + gumm at sigma-star.com +
+ Tue Aug 5 17:56:25 CEST 2014 +

+
+ +
Congrats Loic!
+
+--
+Jesse Gumm
+Owner, Sigma Star Systems
+414.940.4866 || sigma-star.com || @jessegumm
+On Aug 5, 2014 7:43 AM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+> Hello!
+>
+> Cowboy 1.0 has been released.
+>
+> Cowboy is a small and fast HTTP server for Erlang with support for
+> Webmachine-like REST, Websocket and more.
+>
+>   https://github.com/ninenines/cowboy
+>
+> Cowboy is the work of more than 80 people. I would like to congratulate
+> everyone for the great work done so far. Thank you!
+>
+> Please see the CHANGELOG for details on what's changed.
+>
+>   https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md
+>
+> This release marks the beginning of the 1.0.x branch which will contain
+> backward compatible fixes. This branch will be maintained at least until
+> Cowboy 2.0 gets released (longer if sponsors request it). It is highly
+> recommended that you follow this branch if you were following master
+> before, as master will receive backward incompatible changes starting
+> tomorrow.
+>
+> Cowboy is now fully documented. It has a user guide, a function reference
+> manual, and a wealth of examples. You can also install man pages as
+> explained in the README of the project.
+>
+>   http://ninenines.eu/docs/en/cowboy/1.0/guide/
+>   http://ninenines.eu/docs/en/cowboy/1.0/manual/
+>   https://github.com/ninenines/cowboy/tree/master/examples
+>
+> Following a discussion on the Erlang mailing lists the Getting Started
+> chapter was reworked and greatly simplified, in parts due to the
+> improvements made to erlang.mk. Feedback is of course always welcome.
+>
+>   http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/
+>
+> Starting tomorrow the master branch will receive backward incompatible
+> changes. Most of the planned changes are detailed in the ROADMAP. You are
+> welcome to suggest additional changes.
+>
+>   https://github.com/ninenines/cowboy/blob/master/ROADMAP.md
+>
+> Cowboy 2.0 is planned to be released at around the same time Erlang/OTP
+> 18.0 comes out. There are no plans for a Cowboy 1.1 at this time, although
+> that may change in the coming months if there is interest in new features.
+>
+> Ranch also got upgraded to 1.0, although there was no changes from the
+> previous release.
+>
+>   https://github.com/ninenines/ranch
+>
+> Thanks to everyone who made this project what it is today!
+>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> _______________________________________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/listinfo/erlang-questions
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/fb1bc75c/attachment.html>
+
+ + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000429.html b/_build/static/archives/extend/2014-August/000429.html new file mode 100644 index 00000000..935d2482 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000429.html @@ -0,0 +1,143 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Tue Aug 5 19:34:33 CEST 2014 +

+
+ +
Tip of the hat, Loïc et. al.
+
+Outstanding and much appreciated work.
+
+Best to all,
+
+Lloyd
+
+-----Original Message-----
+From: "Loïc Hoguin" <essen at ninenines.eu>
+Sent: Tuesday, August 5, 2014 8:43am
+To: "Erlang" <erlang-questions at erlang.org>, Extend at lists.ninenines.eu
+Subject: [erlang-questions] [ANN] Cowboy 1.0
+
+Hello!
+
+Cowboy 1.0 has been released.
+
+Cowboy is a small and fast HTTP server for Erlang with support for 
+Webmachine-like REST, Websocket and more.
+
+   https://github.com/ninenines/cowboy
+
+Cowboy is the work of more than 80 people. I would like to congratulate 
+everyone for the great work done so far. Thank you!
+
+Please see the CHANGELOG for details on what's changed.
+
+   https://github.com/ninenines/cowboy/blob/master/CHANGELOG.md
+
+This release marks the beginning of the 1.0.x branch which will contain 
+backward compatible fixes. This branch will be maintained at least until 
+Cowboy 2.0 gets released (longer if sponsors request it). It is highly 
+recommended that you follow this branch if you were following master 
+before, as master will receive backward incompatible changes starting 
+tomorrow.
+
+Cowboy is now fully documented. It has a user guide, a function 
+reference manual, and a wealth of examples. You can also install man 
+pages as explained in the README of the project.
+
+   http://ninenines.eu/docs/en/cowboy/1.0/guide/
+   http://ninenines.eu/docs/en/cowboy/1.0/manual/
+   https://github.com/ninenines/cowboy/tree/master/examples
+
+Following a discussion on the Erlang mailing lists the Getting Started 
+chapter was reworked and greatly simplified, in parts due to the 
+improvements made to erlang.mk. Feedback is of course always welcome.
+
+   http://ninenines.eu/docs/en/cowboy/1.0/guide/getting_started/
+
+Starting tomorrow the master branch will receive backward incompatible 
+changes. Most of the planned changes are detailed in the ROADMAP. You 
+are welcome to suggest additional changes.
+
+   https://github.com/ninenines/cowboy/blob/master/ROADMAP.md
+
+Cowboy 2.0 is planned to be released at around the same time Erlang/OTP 
+18.0 comes out. There are no plans for a Cowboy 1.1 at this time, 
+although that may change in the coming months if there is interest in 
+new features.
+
+Ranch also got upgraded to 1.0, although there was no changes from the 
+previous release.
+
+   https://github.com/ninenines/ranch
+
+Thanks to everyone who made this project what it is today!
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+_______________________________________________
+erlang-questions mailing list
+erlang-questions at erlang.org
+http://erlang.org/mailman/listinfo/erlang-questions
+
+
+
+ + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000430.html b/_build/static/archives/extend/2014-August/000430.html new file mode 100644 index 00000000..2b79d150 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000430.html @@ -0,0 +1,119 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Aug 5 22:33:17 CEST 2014 +

+
+ +
Hi, Federico.
+
+Check this out for the "why" regarding your question:
+https://github.com/ninenines/cowboy/issues/715
+
+It's one of the reasons (I haven't detected others yet) stopping me from
+moving to 1.0, unfortunately (I have some projects depending on these
+status codes already), but as soon as I have some time and look at all the
+_major_ differences between 0.9.0 and 1.0 I think I'll make the move. For
+the time being, I have found no issues with the REST part of cowboy (the
+one I use).
+
+Thank you, Loïc et all for the effort and for keeping it open source.
+
+Regards.
+
+- Paulo F. Oliveira
+
+
+On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com> wrote:
+
+> Congratulations Loic. I really love cowboy.
+>
+> I got only one question: Why did you change the reply with 400 instead of
+> 422 in cowboy_rest for unprocessable entities?
+>
+> Regards,
+> Federico.
+>
+>
+>
+> On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com>
+> wrote:
+>
+>> Loic, it is very cool!
+>>
+>> Thanks.
+>>
+>> _______________________________________________
+>> erlang-questions mailing list
+>> erlang-questions at erlang.org
+>> http://erlang.org/mailman/listinfo/erlang-questions
+>>
+>>
+>
+>
+> --
+> http://federicocarrone.com/
+>
+> _______________________________________________
+> erlang-questions mailing list
+> erlang-questions at erlang.org
+> http://erlang.org/mailman/listinfo/erlang-questions
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/f3705f7b/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000431.html b/_build/static/archives/extend/2014-August/000431.html new file mode 100644 index 00000000..ec87a528 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000431.html @@ -0,0 +1,132 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Aug 5 22:55:34 CEST 2014 +

+
+ +
You can easily send 422 and return halt instead of returning false if 
+you need to keep that, it'll just be 2 lines instead of 1. :)
+
+On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote:
+> Hi, Federico.
+>
+> Check this out for the "why" regarding your question:
+> https://github.com/ninenines/cowboy/issues/715
+>
+> It's one of the reasons (I haven't detected others yet) stopping me from
+> moving to 1.0, unfortunately (I have some projects depending on these
+> status codes already), but as soon as I have some time and look at all
+> the _major_ differences between 0.9.0 and 1.0 I think I'll make the
+> move. For the time being, I have found no issues with the REST part of
+> cowboy (the one I use).
+>
+> Thank you, Loïc et all for the effort and for keeping it open source.
+>
+> Regards.
+>
+> - Paulo F. Oliveira
+>
+>
+> On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com
+> <mailto:federico.carrone at gmail.com>> wrote:
+>
+>     Congratulations Loic. I really love cowboy.
+>
+>     I got only one question: Why did you change the reply with 400
+>     instead of 422 in cowboy_rest for unprocessable entities?
+>
+>     Regards,
+>     Federico.
+>
+>
+>
+>     On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com
+>     <mailto:max.lapshin at gmail.com>> wrote:
+>
+>         Loic, it is very cool!
+>
+>         Thanks.
+>
+>         _______________________________________________
+>         erlang-questions mailing list
+>         erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>         http://erlang.org/mailman/listinfo/erlang-questions
+>
+>
+>
+>
+>     --
+>     http://federicocarrone.com/
+>
+>     _______________________________________________
+>     erlang-questions mailing list
+>     erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>     http://erlang.org/mailman/listinfo/erlang-questions
+>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000432.html b/_build/static/archives/extend/2014-August/000432.html new file mode 100644 index 00000000..3e6982cd --- /dev/null +++ b/_build/static/archives/extend/2014-August/000432.html @@ -0,0 +1,155 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Aug 5 23:01:38 CEST 2014 +

+
+ +
Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only
+important difference I should be aware of, then? I haven't written any real
+tests, for the time being, to guarantee backward compatibility for
+dependants...
+
+In any case, I'm thinking about updating the dependencies in the future (I
+own one of them and the other one is an internal project, for the time
+being).
+
+Thanks for the tip.
+
+Cheers.
+
+- Paulo F. Oliveira
+
+
+On 5 August 2014 21:55, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> You can easily send 422 and return halt instead of returning false if you
+> need to keep that, it'll just be 2 lines instead of 1. :)
+>
+> On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote:
+>
+>> Hi, Federico.
+>>
+>> Check this out for the "why" regarding your question:
+>> https://github.com/ninenines/cowboy/issues/715
+>>
+>> It's one of the reasons (I haven't detected others yet) stopping me from
+>> moving to 1.0, unfortunately (I have some projects depending on these
+>> status codes already), but as soon as I have some time and look at all
+>> the _major_ differences between 0.9.0 and 1.0 I think I'll make the
+>> move. For the time being, I have found no issues with the REST part of
+>> cowboy (the one I use).
+>>
+>> Thank you, Loïc et all for the effort and for keeping it open source.
+>>
+>> Regards.
+>>
+>> - Paulo F. Oliveira
+>>
+>>
+>> On 5 August 2014 15:18, Federico Carrone <federico.carrone at gmail.com
+>> <mailto:federico.carrone at gmail.com>> wrote:
+>>
+>>     Congratulations Loic. I really love cowboy.
+>>
+>>     I got only one question: Why did you change the reply with 400
+>>     instead of 422 in cowboy_rest for unprocessable entities?
+>>
+>>     Regards,
+>>     Federico.
+>>
+>>
+>>
+>>     On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin <max.lapshin at gmail.com
+>>     <mailto:max.lapshin at gmail.com>> wrote:
+>>
+>>         Loic, it is very cool!
+>>
+>>         Thanks.
+>>
+>>         _______________________________________________
+>>         erlang-questions mailing list
+>>         erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>         http://erlang.org/mailman/listinfo/erlang-questions
+>>
+>>
+>>
+>>
+>>     --
+>>     http://federicocarrone.com/
+>>
+>>     _______________________________________________
+>>     erlang-questions mailing list
+>>     erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>>     http://erlang.org/mailman/listinfo/erlang-questions
+>>
+>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140805/34528764/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000433.html b/_build/static/archives/extend/2014-August/000433.html new file mode 100644 index 00000000..3cb256ea --- /dev/null +++ b/_build/static/archives/extend/2014-August/000433.html @@ -0,0 +1,181 @@ + + + + [99s-extend] [erlang-questions] [ANN] Cowboy 1.0 + + + + + + + + + + +

[99s-extend] [erlang-questions] [ANN] Cowboy 1.0

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Aug 5 23:06:19 CEST 2014 +

+
+ +
If you were already at the previous version (0.10) then that plus a 400 
+instead of 500 when header parsing fails are pretty much the only changes.
+
+There's some more if you were at 0.9, mostly the body reading interface 
+changed to prevent annoying timeout issues.
+
+On 08/05/2014 11:01 PM, Paulo F. Oliveira wrote:
+> Yes, it should be _that_ easy for the 400 > 422 :D, but is that the only
+> important difference I should be aware of, then? I haven't written any
+> real tests, for the time being, to guarantee backward compatibility for
+> dependants...
+>
+> In any case, I'm thinking about updating the dependencies in the future
+> (I own one of them and the other one is an internal project, for the
+> time being).
+>
+> Thanks for the tip.
+>
+> Cheers.
+>
+> - Paulo F. Oliveira
+>
+>
+> On 5 August 2014 21:55, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     You can easily send 422 and return halt instead of returning false
+>     if you need to keep that, it'll just be 2 lines instead of 1. :)
+>
+>     On 08/05/2014 10:33 PM, Paulo F. Oliveira wrote:
+>
+>         Hi, Federico.
+>
+>         Check this out for the "why" regarding your question:
+>         https://github.com/ninenines/__cowboy/issues/715
+>         <https://github.com/ninenines/cowboy/issues/715>
+>
+>         It's one of the reasons (I haven't detected others yet) stopping
+>         me from
+>         moving to 1.0, unfortunately (I have some projects depending on
+>         these
+>         status codes already), but as soon as I have some time and look
+>         at all
+>         the _major_ differences between 0.9.0 and 1.0 I think I'll make the
+>         move. For the time being, I have found no issues with the REST
+>         part of
+>         cowboy (the one I use).
+>
+>         Thank you, Loïc et all for the effort and for keeping it open
+>         source.
+>
+>         Regards.
+>
+>         - Paulo F. Oliveira
+>
+>
+>         On 5 August 2014 15:18, Federico Carrone
+>         <federico.carrone at gmail.com <mailto:federico.carrone at gmail.com>
+>         <mailto:federico.carrone at __gmail.com
+>         <mailto:federico.carrone at gmail.com>>> wrote:
+>
+>              Congratulations Loic. I really love cowboy.
+>
+>              I got only one question: Why did you change the reply with 400
+>              instead of 422 in cowboy_rest for unprocessable entities?
+>
+>              Regards,
+>              Federico.
+>
+>
+>
+>              On Tue, Aug 5, 2014 at 10:33 AM, Max Lapshin
+>         <max.lapshin at gmail.com <mailto:max.lapshin at gmail.com>
+>              <mailto:max.lapshin at gmail.com
+>         <mailto:max.lapshin at gmail.com>>__> wrote:
+>
+>                  Loic, it is very cool!
+>
+>                  Thanks.
+>
+>                  _________________________________________________
+>                  erlang-questions mailing list
+>         erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>         <mailto:erlang-questions at __erlang.org
+>         <mailto:erlang-questions at erlang.org>>
+>         http://erlang.org/mailman/__listinfo/erlang-questions
+>         <http://erlang.org/mailman/listinfo/erlang-questions>
+>
+>
+>
+>
+>              --
+>         http://federicocarrone.com/
+>
+>              _________________________________________________
+>              erlang-questions mailing list
+>         erlang-questions at erlang.org <mailto:erlang-questions at erlang.org>
+>         <mailto:erlang-questions at __erlang.org
+>         <mailto:erlang-questions at erlang.org>>
+>         http://erlang.org/mailman/__listinfo/erlang-questions
+>         <http://erlang.org/mailman/listinfo/erlang-questions>
+>
+>
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         https://lists.ninenines.eu/__listinfo/extend
+>         <https://lists.ninenines.eu/listinfo/extend>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000434.html b/_build/static/archives/extend/2014-August/000434.html new file mode 100644 index 00000000..36bae6c2 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000434.html @@ -0,0 +1,72 @@ + + + + [99s-extend] eunit suppoort in erlang.mk? + + + + + + + + + + +

[99s-extend] eunit suppoort in erlang.mk?

+ Michael Wittig + michael.wittig at tullius-walden.com +
+ Wed Aug 13 11:17:51 CEST 2014 +

+
+ +
hi,
+
+is it possible to run eunit tests when executing make tests?
+I have my tests directly in the modules (e.g. xyz_server)
+
+Regards,
+
+Michael
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140813/7903a29a/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000435.html b/_build/static/archives/extend/2014-August/000435.html new file mode 100644 index 00000000..c1d359f5 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000435.html @@ -0,0 +1,100 @@ + + + + [99s-extend] couldn't quit in Erlang 17.1 + + + + + + + + + + +

[99s-extend] couldn't quit in Erlang 17.1

+ chaehb + chaehb at gmail.com +
+ Thu Aug 14 03:20:05 CEST 2014 +

+
+ +
+On 2014. 7. 27., at 오후 6:25, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Does it happen with ssl_hello_world?
+> 
+> On 07/26/2014 09:06 AM, chaehb wrote:
+>> Hi, everybody.
+>> 
+>> After Erlang updated to 17.1,
+>> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages..
+>> 
+>> (after ok signal printed)
+>> 
+>> …...
+>> =ERROR REPORT==== 26-Jul-2014::15:23:33 ===
+>> Error in process <0.334.0> on node ‘...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+>> ….
+>> 
+>> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments.
+>> 
+>> This is only appeared when I only use ssl(https).
+>> But when use only http with same dispatch rules, cowboy normally quitted.
+>> 
+
+I’ve try to do more tests with ssl_hello_world in cowboy(v1.0)  and various Erlang/OTP versions.
+
+If ErlangOTP < 17.0, http/https works fine.
+If ErlangOTP >= 17.1(17.1.x,17.2 in github), http works fine but with https the same errors appeared.
+
+*****
+When I edited ranch_accepter.erl > line 40 
+	{error, Reason} when Reason =/= closed -> 
+	to
+	{error, Reason} ->
+,
+https work and app was normally quitted.
+
+When I printed, Reason == closed.
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000436.html b/_build/static/archives/extend/2014-August/000436.html new file mode 100644 index 00000000..b4c2d29d --- /dev/null +++ b/_build/static/archives/extend/2014-August/000436.html @@ -0,0 +1,73 @@ + + + + [99s-extend] cowboy_rest and response headers + + + + + + + + + + +

[99s-extend] cowboy_rest and response headers

+ Camille Troillard + lists at tuli.pe +
+ Thu Aug 14 17:44:25 CEST 2014 +

+
+ +
Hello,
+
+I would like to set a Content-Range header in the response of a HEAD request.
+Can I do that within the context of a cowboy_rest handler?
+Ideally, I wish to let cowboy_rest reply and just specify this additional header.
+
+
+Best,
+Camille
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140814/64f862ef/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000437.html b/_build/static/archives/extend/2014-August/000437.html new file mode 100644 index 00000000..2face141 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000437.html @@ -0,0 +1,86 @@ + + + + [99s-extend] cowboy_rest and response headers + + + + + + + + + + +

[99s-extend] cowboy_rest and response headers

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Aug 14 17:50:09 CEST 2014 +

+
+ +
Use cowboy_req:set_resp_header and return the Req this function gives you.
+
+On 08/14/2014 05:44 PM, Camille Troillard wrote:
+> Hello,
+>
+> I would like to set a Content-Range header in the response of a HEAD
+> request.
+> Can I do that within the context of a cowboy_rest handler?
+> Ideally, I wish to let cowboy_rest reply and just specify this
+> additional header.
+>
+>
+> Best,
+> Camille
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000438.html b/_build/static/archives/extend/2014-August/000438.html new file mode 100644 index 00000000..dd24c8ba --- /dev/null +++ b/_build/static/archives/extend/2014-August/000438.html @@ -0,0 +1,84 @@ + + + + [99s-extend] How to use the PUT verb with Cowboy_Rest ? + + + + + + + + + + +

[99s-extend] How to use the PUT verb with Cowboy_Rest ?

+ Stéphane Wirtel + stephane at wirtel.be +
+ Sun Aug 24 01:58:12 CEST 2014 +

+
+ +
Hi all,
+
+1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I 
+have a small crash.
+
+Here is my code:
+
+https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4
+
+Could you tell me if I correctly use cowboy_rest for the PUT verb? I 
+have seen is_conflict/2, but I don't know how to use it.
+
+2. I would like to change the response code, but I get the error. Is it 
+possible?
+
+Thank you.
+
+Regards,
+
+Stephane
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000439.html b/_build/static/archives/extend/2014-August/000439.html new file mode 100644 index 00000000..c9839bc6 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000439.html @@ -0,0 +1,103 @@ + + + + [99s-extend] How to use the PUT verb with Cowboy_Rest ? + + + + + + + + + + +

[99s-extend] How to use the PUT verb with Cowboy_Rest ?

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Sun Aug 24 02:16:02 CEST 2014 +

+
+ +
You should implement the resource_exists() callback; this will let the rest
+module pick a 200 vs 201.  If the db name was incorrect, I think you are
+just supposed to return false from the put callback.  I can't remember the
+http code for that case.
+
+Regards,
+Dan.
+
+
+On Sat, Aug 23, 2014 at 6:58 PM, Stéphane Wirtel <stephane at wirtel.be> wrote:
+
+> Hi all,
+>
+> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have
+> a small crash.
+>
+> Here is my code:
+>
+> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4
+>
+> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have
+> seen is_conflict/2, but I don't know how to use it.
+>
+> 2. I would like to change the response code, but I get the error. Is it
+> possible?
+>
+> Thank you.
+>
+> Regards,
+>
+> Stephane
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140823/51e1d345/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000440.html b/_build/static/archives/extend/2014-August/000440.html new file mode 100644 index 00000000..0e83b7ce --- /dev/null +++ b/_build/static/archives/extend/2014-August/000440.html @@ -0,0 +1,120 @@ + + + + [99s-extend] How to use the PUT verb with Cowboy_Rest ? + + + + + + + + + + +

[99s-extend] How to use the PUT verb with Cowboy_Rest ?

+ Stéphane Wirtel + stephane at wirtel.be +
+ Sun Aug 24 02:22:22 CEST 2014 +

+
+ +
resource_exists is used by POST
+is_conflict is used by PUT (from the code)
+but in the case where my database already exists, I need to return 412 
+and not 409.
+
+and I know I don't respect the default value returned by Cowboy_rest.
+
+On 24 Aug 2014, at 2:16, Daniel Goertzen wrote:
+
+> You should implement the resource_exists() callback; this will let the 
+> rest
+> module pick a 200 vs 201.  If the db name was incorrect, I think you 
+> are
+> just supposed to return false from the put callback.  I can't remember 
+> the
+> http code for that case.
+>
+> Regards,
+> Dan.
+>
+>
+> On Sat, Aug 23, 2014 at 6:58 PM, Stéphane Wirtel <stephane at wirtel.be> 
+> wrote:
+>
+>> Hi all,
+>>
+>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I 
+>> have
+>> a small crash.
+>>
+>> Here is my code:
+>>
+>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4
+>>
+>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I 
+>> have
+>> seen is_conflict/2, but I don't know how to use it.
+>>
+>> 2. I would like to change the response code, but I get the error. Is 
+>> it
+>> possible?
+>>
+>> Thank you.
+>>
+>> Regards,
+>>
+>> Stephane
+>>
+>> --
+>> Stéphane Wirtel - http://wirtel.be - @matrixise
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000441.html b/_build/static/archives/extend/2014-August/000441.html new file mode 100644 index 00000000..8d0063bb --- /dev/null +++ b/_build/static/archives/extend/2014-August/000441.html @@ -0,0 +1,139 @@ + + + + [99s-extend] How to use the PUT verb with Cowboy_Rest ? + + + + + + + + + + +

[99s-extend] How to use the PUT verb with Cowboy_Rest ?

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Sun Aug 24 02:25:54 CEST 2014 +

+
+ +
I think you can always halt the processing and do the reply by yourself:
+
+{ok, Req2} = cowboy_req:reply(412, Req),
+{halt, Req2, State}.
+
+
+On Sun, Aug 24, 2014 at 12:22 PM, Stéphane Wirtel <stephane at wirtel.be>
+wrote:
+
+> resource_exists is used by POST
+> is_conflict is used by PUT (from the code)
+> but in the case where my database already exists, I need to return 412 and
+> not 409.
+>
+> and I know I don't respect the default value returned by Cowboy_rest.
+>
+>
+> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote:
+>
+>  You should implement the resource_exists() callback; this will let the
+>> rest
+>> module pick a 200 vs 201.  If the db name was incorrect, I think you are
+>> just supposed to return false from the put callback.  I can't remember the
+>> http code for that case.
+>>
+>> Regards,
+>> Dan.
+>>
+>>
+>> On Sat, Aug 23, 2014 at 6:58 PM, Stéphane Wirtel <stephane at wirtel.be>
+>> wrote:
+>>
+>>  Hi all,
+>>>
+>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I
+>>> have
+>>> a small crash.
+>>>
+>>> Here is my code:
+>>>
+>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4
+>>>
+>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have
+>>> seen is_conflict/2, but I don't know how to use it.
+>>>
+>>> 2. I would like to change the response code, but I get the error. Is it
+>>> possible?
+>>>
+>>> Thank you.
+>>>
+>>> Regards,
+>>>
+>>> Stephane
+>>>
+>>> --
+>>> Stéphane Wirtel - http://wirtel.be - @matrixise
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>>
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140824/89d3a7f6/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000442.html b/_build/static/archives/extend/2014-August/000442.html new file mode 100644 index 00000000..5c15d766 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000442.html @@ -0,0 +1,135 @@ + + + + [99s-extend] How to use the PUT verb with Cowboy_Rest ? + + + + + + + + + + +

[99s-extend] How to use the PUT verb with Cowboy_Rest ?

+ Stephane Wirtel + stephane at wirtel.be +
+ Sun Aug 24 02:52:58 CEST 2014 +

+
+ +
Ok I will try asap, thanks
+
+> On 24 août 2014, at 02:25 AM, Eduardo Gurgel <edgurgel at gmail.com> wrote:
+> 
+> I think you can always halt the processing and do the reply by yourself:
+> 
+> {ok, Req2} = cowboy_req:reply(412, Req),
+> {halt, Req2, State}.
+> 
+> 
+>> On Sun, Aug 24, 2014 at 12:22 PM, Stéphane Wirtel <stephane at wirtel.be> wrote:
+>> resource_exists is used by POST
+>> is_conflict is used by PUT (from the code)
+>> but in the case where my database already exists, I need to return 412 and not 409.
+>> 
+>> and I know I don't respect the default value returned by Cowboy_rest.
+>> 
+>> 
+>> On 24 Aug 2014, at 2:16, Daniel Goertzen wrote:
+>> 
+>>> You should implement the resource_exists() callback; this will let the rest
+>>> module pick a 200 vs 201.  If the db name was incorrect, I think you are
+>>> just supposed to return false from the put callback.  I can't remember the
+>>> http code for that case.
+>>> 
+>>> Regards,
+>>> Dan.
+>>> 
+>>> 
+>>> On Sat, Aug 23, 2014 at 6:58 PM, Stéphane Wirtel <stephane at wirtel.be> wrote:
+>>> 
+>>>> Hi all,
+>>>> 
+>>>> 1. I would like to use the cowboy_rest protocol with cowboy 1.0 but I have
+>>>> a small crash.
+>>>> 
+>>>> Here is my code:
+>>>> 
+>>>> https://www.friendpaste.com/7O3X4fG4u31gBg9MgW5xg4
+>>>> 
+>>>> Could you tell me if I correctly use cowboy_rest for the PUT verb? I have
+>>>> seen is_conflict/2, but I don't know how to use it.
+>>>> 
+>>>> 2. I would like to change the response code, but I get the error. Is it
+>>>> possible?
+>>>> 
+>>>> Thank you.
+>>>> 
+>>>> Regards,
+>>>> 
+>>>> Stephane
+>>>> 
+>>>> --
+>>>> Stéphane Wirtel - http://wirtel.be - @matrixise
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> https://lists.ninenines.eu/listinfo/extend
+>> 
+>> 
+>> --
+>> Stéphane Wirtel - http://wirtel.be - @matrixise
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+> 
+> 
+> 
+> -- 
+> Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140824/f35e1e51/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000443.html b/_build/static/archives/extend/2014-August/000443.html new file mode 100644 index 00000000..d36a6858 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000443.html @@ -0,0 +1,85 @@ + + + + [99s-extend] Full example of cowboy_rest? + + + + + + + + + + +

[99s-extend] Full example of cowboy_rest?

+ Stéphane Wirtel + stephane at wirtel.be +
+ Sun Aug 24 11:54:58 CEST 2014 +

+
+ +
Hi all,
+
+Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, 
+PUT and DELETE ?
+
+POST will use resource_exists and allow_missing_post
+PUT will use is_conflict
+DELETE delete_resource, etc...
+
+Currently, I started with the example with put_json and get_json and in 
+the functions, I fetch the Method and I use the pattern matching with 
+the Method, but I think it's not the right solution.
+
+What are the best practices?
+
+The examples in the repository of cowboy don't cover all the 
+possibilities of a simple rest api with these verbs.
+
+Thanks in advance,
+
+Stephane
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000444.html b/_build/static/archives/extend/2014-August/000444.html new file mode 100644 index 00000000..036f90f6 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000444.html @@ -0,0 +1,126 @@ + + + + [99s-extend] Full example of cowboy_rest? + + + + + + + + + + +

[99s-extend] Full example of cowboy_rest?

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Aug 26 01:11:44 CEST 2014 +

+
+ +
Hello, Stéphane.
+
+On 24 August 2014 10:54, Stéphane Wirtel <stephane at wirtel.be> wrote:
+>
+> Hi all,
+>
+> Do you have a concrete example of cowboy_rest ? with POST, GET, HEAD, PUT and DELETE ?
+
+AFAIK, from the official examples, the correct answer is "no", there
+is no "complete" example (does it even make sense to have one?).
+
+On the other hand, I've been using Cowboy for a couple of months now,
+and find these docs (REST flowcharts -
+http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/) to be
+very useful, and they might also help you. You should find the time to
+read the complete REST guide/manual as a lot of useful information can
+be found there and a very nice effort was put into not wasting words
+and going straight to the point.
+
+...
+
+> What are the best practices?
+
+For what specifically?
+
+> The examples in the repository of cowboy don't cover all the possibilities of a simple rest api with these verbs.
+
+That is a fact. I, for one, tend to have a _template_ source code file
+from where I get the functions that I need (only not to have to write
+2/3 lines of code every time), and that I "chain" looking at the
+flowcharts. [I also have a lib for JSON parsing and validating, query
+string validation, etc...] This might not always be very easy (to
+"chain" it all together, but it shouldn't be that hard either"), but
+my approach is usually "OK, so I want a route to have GET, PUT and
+DELETE... what are the related methods that I'll most probably
+require? resource_exists (serves all methods), is_conflict (serves
+PUT), delete_resource (serves DELETE), delete_completed (serves
+DELETE)" and then I think about replying with a body or not (in the
+case of GET there will almost always be a body, in the case of PUT
+your method call might result in a 204 and in the case of DELETE there
+may or not be a body). I then code the methods, test the API, checking
+that the codes I get make sense (404, 200, 409, 204, 202, ...
+depending on the conditions I want set) and then slightly document
+this for the users of the API (if the API is complicated and requires
+a lot of documentation there might be something wrong with it). For
+documentation purposes you can either go with a "[VERB] route
+accepts...?..., serves...?..., and the result codes are...?..." simple
+doc or something more elaborate like
+https://helloreverb.com/developers/swagger.
+
+Hope it helps.
+
+- Paulo F. Oliveira
+
+>
+> Thanks in advance,
+>
+> Stephane
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000445.html b/_build/static/archives/extend/2014-August/000445.html new file mode 100644 index 00000000..766b45ae --- /dev/null +++ b/_build/static/archives/extend/2014-August/000445.html @@ -0,0 +1,88 @@ + + + + [99s-extend] cowboy_rest and delete_completed and response + + + + + + + + + + +

[99s-extend] cowboy_rest and delete_completed and response

+ Stéphane Wirtel + stephane at wirtel.be +
+ Tue Aug 26 23:59:50 CEST 2014 +

+
+ +
Hi all,
+
+I work with two content-types (json, msgpack).
+
+In the DELETE verb, I need to return an object and in this case, I work 
+on delete_resource/2 and delete_completed/2.
+The problem is, how can I return a body in function of the content-type? 
+because after delete_completed, there is a call to the 
+cowboy_rest:has_resp_body function and I need to set the body of the 
+response.
+
+delete_completed(Req, State) ->
+	Body = Json or MsgPack ?  <-- Which content ?
+
+	Req2 = cowboy_req:set_resp_body(Body, Req),
+	{true, Req2, State}.
+
+Ok, but in this case, what's the reason of content_types_provided/2 and 
+content_types_accepted/2 ?
+
+Thank you,
+
+Stephane
+
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000446.html b/_build/static/archives/extend/2014-August/000446.html new file mode 100644 index 00000000..c5345323 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000446.html @@ -0,0 +1,99 @@ + + + + [99s-extend] cowboy_rest and delete_completed and response + + + + + + + + + + +

[99s-extend] cowboy_rest and delete_completed and response

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 27 00:03:45 CEST 2014 +

+
+ +
Call cowboy_req:meta(media_type, Req) to retrieve it.
+
+On 08/27/2014 12:59 AM, Stéphane Wirtel wrote:
+> Hi all,
+>
+> I work with two content-types (json, msgpack).
+>
+> In the DELETE verb, I need to return an object and in this case, I work
+> on delete_resource/2 and delete_completed/2.
+> The problem is, how can I return a body in function of the content-type?
+> because after delete_completed, there is a call to the
+> cowboy_rest:has_resp_body function and I need to set the body of the
+> response.
+>
+> delete_completed(Req, State) ->
+>      Body = Json or MsgPack ?  <-- Which content ?
+>
+>      Req2 = cowboy_req:set_resp_body(Body, Req),
+>      {true, Req2, State}.
+>
+> Ok, but in this case, what's the reason of content_types_provided/2 and
+> content_types_accepted/2 ?
+>
+> Thank you,
+>
+> Stephane
+>
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000447.html b/_build/static/archives/extend/2014-August/000447.html new file mode 100644 index 00000000..6feb64ff --- /dev/null +++ b/_build/static/archives/extend/2014-August/000447.html @@ -0,0 +1,130 @@ + + + + [99s-extend] cowboy_rest and delete_completed and response + + + + + + + + + + +

[99s-extend] cowboy_rest and delete_completed and response

+ Stéphane Wirtel + stephane at wirtel.be +
+ Wed Aug 27 00:12:00 CEST 2014 +

+
+ +
What's the purpose of the callbacks in content_types_accepted and 
+content_types_provided?
+
+I prefer set the response in the State to the callbacks and they convert 
+it to the right format.
+
+Example:
+
+delete_completed(Req, State) ->
+	Response = [{<<"ok">>, <<"dbname">>}],
+	{true, Req, State#state{response=Response}}.
+
+get_json(Req, #{response=Response}=State) ->
+	Body = jsx:encode(Response),
+	{Body, Req, State}.
+
+get_msgpack(Req, #{response=Response}=State) ->
+	Body = msgpack:pack(Response, [{format, jsx}],
+	{Body, Req, State}.
+
+
+
+On 27 Aug 2014, at 0:03, Loïc Hoguin wrote:
+
+> Call cowboy_req:meta(media_type, Req) to retrieve it.
+>
+> On 08/27/2014 12:59 AM, Stéphane Wirtel wrote:
+>> Hi all,
+>>
+>> I work with two content-types (json, msgpack).
+>>
+>> In the DELETE verb, I need to return an object and in this case, I 
+>> work
+>> on delete_resource/2 and delete_completed/2.
+>> The problem is, how can I return a body in function of the 
+>> content-type?
+>> because after delete_completed, there is a call to the
+>> cowboy_rest:has_resp_body function and I need to set the body of the
+>> response.
+>>
+>> delete_completed(Req, State) ->
+>>   Body = Json or MsgPack ?  <-- Which content ?
+>>
+>>   Req2 = cowboy_req:set_resp_body(Body, Req),
+>>   {true, Req2, State}.
+>>
+>> Ok, but in this case, what's the reason of content_types_provided/2 
+>> and
+>> content_types_accepted/2 ?
+>>
+>> Thank you,
+>>
+>> Stephane
+>>
+>>
+>> --
+>> Stéphane Wirtel - http://wirtel.be - @matrixise
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000448.html b/_build/static/archives/extend/2014-August/000448.html new file mode 100644 index 00000000..8197f220 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000448.html @@ -0,0 +1,142 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Stéphane Wirtel + stephane at wirtel.be +
+ Wed Aug 27 11:29:46 CEST 2014 +

+
+ +
Hi all,
+
+This night, I wrote an example because I wanted to show you my work.
+
+I have one handler for the concept of collections (in this case, tasks).
+
+In this handler, I want these following methods:
+
+POST /:collection
+GET /:collection
+DELETE /:collection
+PUT /:collection
+HEAD /:collection
+
+:collection is a string, example: /tasks1
+
+HEAD /:collection (/tasks1)
+StatusCode:
+	* 200 ok
+	* 404 not found
+
+GET /:collection (/tasks1)
+Gets information about the collection
+StatusCode:
+	* 200 ok
+	* 404 not found
+
+PUT /:collection (/tasks1)
+Create a new collection of tasks
+Status_Code:
+	* 201 created
+	Response: an object, in msgpack or json and I need to had a location 
+header
+	* 412 precondition failed, the collection name already exists
+	Response: an object, in msgpack or json with the error (already exists)
+
+POST /:collection (/tasks1)
+Add a new item in the collection, a new task
+StatusCode:
+	* 201 created
+	* 202 accepted
+	* 404 not found (error in the collection name)
+Response: need to add a location header and return an object in msgpack 
+or json.
+
+DELETE /:collection (/tasks1)
+Delete all the tasks
+Status_Code:
+	* 200 ok.
+	* 404 not found
+In the case of 200, we need to return an object in msgpack or json.
+
+
+I provided a code and If you can help me, because I think cowboy_rest is 
+a good solution, but I also think I will have some problems with my 
+service.
+
+Examples:
+* delete_completed, I need to write the serialisation in the 
+delete_completed function and not with the help of the defined callbacks 
+of content_types_provided.
+* for PUT, I need to return a location header, should I add it in the 
+is_conflict
+function?
+* for PUT, how I have a 201? I have read the rest_flowchart and I need 
+to specify the location header ok, but where? in the is_conflict 
+function?
+
+So, do you have time to help me, because with this example, I can 
+propose it to the cowboy repository.
+https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl
+
+You can propose your PR, comments or remarks, but I would like to use 
+cowboy_rest.
+
+Regards,
+
+Stephane
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000449.html b/_build/static/archives/extend/2014-August/000449.html new file mode 100644 index 00000000..059b0783 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000449.html @@ -0,0 +1,167 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 27 12:03:41 CEST 2014 +

+
+ +
Hey,
+
+On 08/27/2014 12:29 PM, Stéphane Wirtel wrote:
+> Hi all,
+>
+> This night, I wrote an example because I wanted to show you my work.
+>
+> I have one handler for the concept of collections (in this case, tasks).
+>
+> In this handler, I want these following methods:
+>
+> POST /:collection
+> GET /:collection
+> DELETE /:collection
+> PUT /:collection
+> HEAD /:collection
+>
+> :collection is a string, example: /tasks1
+>
+> HEAD /:collection (/tasks1)
+> StatusCode:
+>      * 200 ok
+>      * 404 not found
+>
+> GET /:collection (/tasks1)
+> Gets information about the collection
+> StatusCode:
+>      * 200 ok
+>      * 404 not found
+>
+> PUT /:collection (/tasks1)
+> Create a new collection of tasks
+> Status_Code:
+>      * 201 created
+>      Response: an object, in msgpack or json and I need to had a
+> location header
+>      * 412 precondition failed, the collection name already exists
+>      Response: an object, in msgpack or json with the error (already
+> exists)
+>
+> POST /:collection (/tasks1)
+> Add a new item in the collection, a new task
+> StatusCode:
+>      * 201 created
+>      * 202 accepted
+>      * 404 not found (error in the collection name)
+> Response: need to add a location header and return an object in msgpack
+> or json.
+>
+> DELETE /:collection (/tasks1)
+> Delete all the tasks
+> Status_Code:
+>      * 200 ok.
+>      * 404 not found
+> In the case of 200, we need to return an object in msgpack or json.
+>
+>
+> I provided a code and If you can help me, because I think cowboy_rest is
+> a good solution, but I also think I will have some problems with my
+> service.
+>
+> Examples:
+> * delete_completed, I need to write the serialisation in the
+> delete_completed function and not with the help of the defined callbacks
+> of content_types_provided.
+
+What's the problem? The callbacks you set in content_types_provided are 
+there to provide the *resource*. If you set a body in response to the 
+DELETE method you are not sending the resource but information about the 
+result of the operation.
+
+> * for PUT, I need to return a location header, should I add it in the
+> is_conflict
+> function?
+
+I would say in the callback you set in content_types_accepted. But...
+
+> * for PUT, how I have a 201? I have read the rest_flowchart and I need
+> to specify the location header ok, but where? in the is_conflict function?
+
+Why do you need a 201? If you PUT a collection to /:collection then this 
+is already the location of the collection. I am not sure what you are 
+trying to do there exactly?
+
+> So, do you have time to help me, because with this example, I can
+> propose it to the cowboy repository.
+> https://github.com/matrixise/demo_rest/blob/master/src/collection_handler.erl
+>
+>
+> You can propose your PR, comments or remarks, but I would like to use
+> cowboy_rest.
+>
+> Regards,
+>
+> Stephane
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000450.html b/_build/static/archives/extend/2014-August/000450.html new file mode 100644 index 00000000..d1b5de08 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000450.html @@ -0,0 +1,168 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Stéphane Wirtel + stephane at wirtel.be +
+ Wed Aug 27 12:35:33 CEST 2014 +

+
+ +
On 27 Aug 2014, at 12:03, Loïc Hoguin wrote:
+
+> Hey,
+>
+> On 08/27/2014 12:29 PM, Stéphane Wirtel wrote:
+>> Hi all,
+>>
+>> This night, I wrote an example because I wanted to show you my work.
+>>
+>> I have one handler for the concept of collections (in this case, 
+>> tasks).
+>>
+>> In this handler, I want these following methods:
+>>
+>> POST /:collection
+>> GET /:collection
+>> DELETE /:collection
+>> PUT /:collection
+>> HEAD /:collection
+>>
+>> :collection is a string, example: /tasks1
+>>
+>> HEAD /:collection (/tasks1)
+>> StatusCode:
+>>  * 200 ok
+>>  * 404 not found
+>>
+>> GET /:collection (/tasks1)
+>> Gets information about the collection
+>> StatusCode:
+>>  * 200 ok
+>>  * 404 not found
+>>
+>> PUT /:collection (/tasks1)
+>> Create a new collection of tasks
+>> Status_Code:
+>>  * 201 created
+>>  Response: an object, in msgpack or json and I need to had a
+>> location header
+>>  * 412 precondition failed, the collection name already exists
+>>  Response: an object, in msgpack or json with the error (already
+>> exists)
+>>
+>> POST /:collection (/tasks1)
+>> Add a new item in the collection, a new task
+>> StatusCode:
+>>  * 201 created
+>>  * 202 accepted
+>>  * 404 not found (error in the collection name)
+>> Response: need to add a location header and return an object in 
+>> msgpack
+>> or json.
+>>
+>> DELETE /:collection (/tasks1)
+>> Delete all the tasks
+>> Status_Code:
+>>  * 200 ok.
+>>  * 404 not found
+>> In the case of 200, we need to return an object in msgpack or json.
+>>
+>>
+>> I provided a code and If you can help me, because I think cowboy_rest 
+>> is
+>> a good solution, but I also think I will have some problems with my
+>> service.
+>>
+>> Examples:
+>> * delete_completed, I need to write the serialisation in the
+>> delete_completed function and not with the help of the defined 
+>> callbacks
+>> of content_types_provided.
+>
+> What's the problem? The callbacks you set in content_types_provided 
+> are there to provide the *resource*. If you set a body in response to 
+> the DELETE method you are not sending the resource but information 
+> about the result of the operation.
+Ok, in this case, I understand. thanks
+>
+>> * for PUT, I need to return a location header, should I add it in the
+>> is_conflict
+>> function?
+>
+> I would say in the callback you set in content_types_accepted. But...
+Works fine in the is_conflict function.
+>
+>> * for PUT, how I have a 201? I have read the rest_flowchart and I 
+>> need
+>> to specify the location header ok, but where? in the is_conflict 
+>> function?
+>
+> Why do you need a 201? If you PUT a collection to /:collection then 
+> this is already the location of the collection. I am not sure what you 
+> are trying to do there exactly?
+In this case, the PUT method is used for the creation of the resource 
+and not for the update. This is the reason of the 201 status code.
+
+In the rest_flowchart graph for the PUT/POST methods, what is the node 
+"new resource" ? Is it just the {true, Req, State} from the callback 
+defined in the content_types_accepted?
+
+PS: I retested and now, I have my 201 with PUT, just resource_exists has 
+to return false and not true ;-)
+
+Thanks
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000451.html b/_build/static/archives/extend/2014-August/000451.html new file mode 100644 index 00000000..4920b429 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000451.html @@ -0,0 +1,86 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 27 12:53:19 CEST 2014 +

+
+ +
>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need
+>>> to specify the location header ok, but where? in the is_conflict
+>>> function?
+>>
+>> Why do you need a 201? If you PUT a collection to /:collection then
+>> this is already the location of the collection. I am not sure what you
+>> are trying to do there exactly?
+> In this case, the PUT method is used for the creation of the resource
+> and not for the update. This is the reason of the 201 status code.
+>
+> In the rest_flowchart graph for the PUT/POST methods, what is the node
+> "new resource" ? Is it just the {true, Req, State} from the callback
+> defined in the content_types_accepted?
+>
+> PS: I retested and now, I have my 201 with PUT, just resource_exists has
+> to return false and not true ;-)
+
+My bad I was a little confusing in my previous answer. You are right, if 
+the resource doesn't exist and PUT is used we get a 201 automatically. 
+The location header must only be provided if the resource was created 
+elsewhere.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000452.html b/_build/static/archives/extend/2014-August/000452.html new file mode 100644 index 00000000..02b6f225 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000452.html @@ -0,0 +1,96 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Stéphane Wirtel + stephane at wirtel.be +
+ Wed Aug 27 15:26:11 CEST 2014 +

+
+ +
On 27 Aug 2014, at 12:53, Loïc Hoguin wrote:
+
+>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I 
+>>>> need
+>>>> to specify the location header ok, but where? in the is_conflict
+>>>> function?
+>>>
+>>> Why do you need a 201? If you PUT a collection to /:collection then
+>>> this is already the location of the collection. I am not sure what 
+>>> you
+>>> are trying to do there exactly?
+>> In this case, the PUT method is used for the creation of the resource
+>> and not for the update. This is the reason of the 201 status code.
+>>
+>> In the rest_flowchart graph for the PUT/POST methods, what is the 
+>> node
+>> "new resource" ? Is it just the {true, Req, State} from the callback
+>> defined in the content_types_accepted?
+>>
+>> PS: I retested and now, I have my 201 with PUT, just resource_exists 
+>> has
+>> to return false and not true ;-)
+>
+> My bad I was a little confusing in my previous answer. You are right, 
+> if the resource doesn't exist and PUT is used we get a 201 
+> automatically. The location header must only be provided if the 
+> resource was created elsewhere.
+
+Don't worry and thank you for your answers.
+
+Stephane
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000453.html b/_build/static/archives/extend/2014-August/000453.html new file mode 100644 index 00000000..02c722fa --- /dev/null +++ b/_build/static/archives/extend/2014-August/000453.html @@ -0,0 +1,90 @@ + + + + [99s-extend] Which erlang.mk? + + + + + + + + + + +

[99s-extend] Which erlang.mk?

+ Brandon Clark + a.brandon.clark at gmail.com +
+ Wed Aug 27 21:06:25 CEST 2014 +

+
+ +
Greetings!
+
+I'm trying to resurrect one of my neglected ranch applications.  It uses
+Common Test, erlang.mk, and relx all in the usual way.  When I run make
+tests with all fresh dependencies, I get this:
+
+Doing /home/brandon/src/my_proj/deps/ranch...
+
+make[1]: *** No rule to make target `build-tests'.  Stop.
+
+make: *** [build-deps-tests] Error 2
+
+
+A diff of my erlang.mk and deps/ranch/erlang.mk shows they are dramatically
+different.  Mine came from here just this morning:
+
+https://raw.*github.com <http://github.com>*/extend/
+erlang.mk/master/erlang.mk
+
+Which one is the "right" one for creating new apps?
+
+
+Thank you!
+
+~BC
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140827/91c1e017/attachment.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000454.html b/_build/static/archives/extend/2014-August/000454.html new file mode 100644 index 00000000..ce31faf5 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000454.html @@ -0,0 +1,114 @@ + + + + [99s-extend] Which erlang.mk? + + + + + + + + + + +

[99s-extend] Which erlang.mk?

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 27 23:26:26 CEST 2014 +

+
+ +
The one you downloaded from github is the correct one. It's a new 
+version compared to the older one. A few small things changed, 
+including, in this case, that build-tests was renamed to something like 
+ct-build-tests (please open it to make sure of the name).
+
+The new version allows greater customization and has a better package 
+index feature and other things, but breaking compatibility with older 
+Makefiles. The new version is labeled 1 (beginning of erlang.mk file) 
+while the older one has no such label.
+
+On 08/27/2014 10:06 PM, Brandon Clark wrote:
+> Greetings!
+>
+> I'm trying to resurrect one of my neglected ranch applications.  It uses
+> Common Test, erlang.mk <http://erlang.mk>, and relx all in the usual
+> way.  When I run make tests with all fresh dependencies, I get this:
+>
+> Doing /home/brandon/src/my_proj/deps/ranch...
+>
+> make[1]: *** No rule to make target `build-tests'.  Stop.
+>
+> make: *** [build-deps-tests] Error 2
+>
+>
+> A diff of my erlang.mk <http://erlang.mk> and deps/ranch/erlang.mk
+> <http://erlang.mk> shows they are dramatically different.  Mine came
+> from here just this morning:
+>
+> https://raw._github.com
+> <http://github.com>_/extend/erlang.mk/master/erlang.mk
+> <http://erlang.mk/master/erlang.mk>
+>
+> Which one is the "right" one for creating new apps?
+>
+>
+> Thank you!
+>
+> ~BC
+>
+>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000455.html b/_build/static/archives/extend/2014-August/000455.html new file mode 100644 index 00000000..0e2c3653 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000455.html @@ -0,0 +1,78 @@ + + + + [99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ? + + + + + + + + + + +

[99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ?

+ Stéphane Wirtel + stephane at wirtel.be +
+ Wed Aug 27 23:41:25 CEST 2014 +

+
+ +
Hi all,
+
+For the PUT method, the flow is 
+
+resource_exists
+if method == PUT then go to the is_conflict function.
+In each function, we need to check if the resource already exists or not.
+
+I think we check twice, is it normal?
+
+Thank you,
+
+Stephane
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000456.html b/_build/static/archives/extend/2014-August/000456.html new file mode 100644 index 00000000..2d6772e6 --- /dev/null +++ b/_build/static/archives/extend/2014-August/000456.html @@ -0,0 +1,94 @@ + + + + [99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ? + + + + + + + + + + +

[99s-extend] cowboy_rest : PUT and resource_exists vs is_conflict ?

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Aug 27 23:48:41 CEST 2014 +

+
+ +
For some callbacks you may need to check but only if you need to perform 
+a different operation when it does/doesn't. For example if you write to 
+files a PUT is the same operation either way, but if you write to an SQL 
+DB you will want to do INSERT/UPDATE depending on that. Same goes for 
+is_conflict and others, it depends.
+
+So sometimes you need to keep that info around in the state and 
+sometimes you don't.
+
+On 08/28/2014 12:41 AM, Stéphane Wirtel wrote:
+> Hi all,
+>
+> For the PUT method, the flow is
+>
+> resource_exists
+> if method == PUT then go to the is_conflict function.
+> In each function, we need to check if the resource already exists or not.
+>
+> I think we check twice, is it normal?
+>
+> Thank you,
+>
+> Stephane
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/000457.html b/_build/static/archives/extend/2014-August/000457.html new file mode 100644 index 00000000..24b17abc --- /dev/null +++ b/_build/static/archives/extend/2014-August/000457.html @@ -0,0 +1,111 @@ + + + + [99s-extend] I need your feedback about this cowboy_rest handler. + + + + + + + + + + +

[99s-extend] I need your feedback about this cowboy_rest handler.

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Sat Aug 30 00:15:56 CEST 2014 +

+
+ +
PUT _should_ (there is no police here though) be used to either create
+a resource or completely update it (it's refered to as "upsert" by
+some; in Redis, for example, a similar concept would be "set").
+Partial modifications should be made using PATCH. POST is what is
+commonly used to create a resource. According to
+http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html 412 is used
+when "[t]he precondition given in one or more of the request-header
+fields evaluated to false when it was tested on the server." (also:
+http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24).
+
+- Paulo F. Oliveira
+
+On 27 August 2014 14:26, Stéphane Wirtel <stephane at wirtel.be> wrote:
+> On 27 Aug 2014, at 12:53, Loïc Hoguin wrote:
+>
+>>>>> * for PUT, how I have a 201? I have read the rest_flowchart and I need
+>>>>> to specify the location header ok, but where? in the is_conflict
+>>>>> function?
+>>>>
+>>>>
+>>>> Why do you need a 201? If you PUT a collection to /:collection then
+>>>> this is already the location of the collection. I am not sure what you
+>>>> are trying to do there exactly?
+>>>
+>>> In this case, the PUT method is used for the creation of the resource
+>>> and not for the update. This is the reason of the 201 status code.
+>>>
+>>> In the rest_flowchart graph for the PUT/POST methods, what is the node
+>>> "new resource" ? Is it just the {true, Req, State} from the callback
+>>> defined in the content_types_accepted?
+>>>
+>>> PS: I retested and now, I have my 201 with PUT, just resource_exists has
+>>> to return false and not true ;-)
+>>
+>>
+>> My bad I was a little confusing in my previous answer. You are right, if
+>> the resource doesn't exist and PUT is used we get a 201 automatically. The
+>> location header must only be provided if the resource was created elsewhere.
+>
+>
+> Don't worry and thank you for your answers.
+>
+> Stephane
+>
+>
+> --
+> Stéphane Wirtel - http://wirtel.be - @matrixise
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-August/author.html b/_build/static/archives/extend/2014-August/author.html new file mode 100644 index 00000000..c661620f --- /dev/null +++ b/_build/static/archives/extend/2014-August/author.html @@ -0,0 +1,252 @@ + + + + The Extend August 2014 Archive by author + + + + + +

August 2014 Archives by author

+ +

Starting: Mon Aug 4 18:39:26 CEST 2014
+ Ending: Sat Aug 30 00:15:56 CEST 2014
+ Messages: 41

+

+

+ Last message date: + Sat Aug 30 00:15:56 CEST 2014
+ Archived on: Sat Aug 30 00:15:58 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-August/date.html b/_build/static/archives/extend/2014-August/date.html new file mode 100644 index 00000000..b985c425 --- /dev/null +++ b/_build/static/archives/extend/2014-August/date.html @@ -0,0 +1,252 @@ + + + + The Extend August 2014 Archive by date + + + + + +

August 2014 Archives by date

+ +

Starting: Mon Aug 4 18:39:26 CEST 2014
+ Ending: Sat Aug 30 00:15:56 CEST 2014
+ Messages: 41

+

+

+ Last message date: + Sat Aug 30 00:15:56 CEST 2014
+ Archived on: Sat Aug 30 00:15:58 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-August/index.html b/_build/static/archives/extend/2014-August/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-August/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-August/subject.html b/_build/static/archives/extend/2014-August/subject.html new file mode 100644 index 00000000..af9f381b --- /dev/null +++ b/_build/static/archives/extend/2014-August/subject.html @@ -0,0 +1,252 @@ + + + + The Extend August 2014 Archive by subject + + + + + +

August 2014 Archives by subject

+ +

Starting: Mon Aug 4 18:39:26 CEST 2014
+ Ending: Sat Aug 30 00:15:56 CEST 2014
+ Messages: 41

+

+

+ Last message date: + Sat Aug 30 00:15:56 CEST 2014
+ Archived on: Sat Aug 30 00:15:58 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-August/thread.html b/_build/static/archives/extend/2014-August/thread.html new file mode 100644 index 00000000..076e99dc --- /dev/null +++ b/_build/static/archives/extend/2014-August/thread.html @@ -0,0 +1,331 @@ + + + + The Extend August 2014 Archive by thread + + + + + +

August 2014 Archives by thread

+ +

Starting: Mon Aug 4 18:39:26 CEST 2014
+ Ending: Sat Aug 30 00:15:56 CEST 2014
+ Messages: 41

+

+

+ Last message date: + Sat Aug 30 00:15:56 CEST 2014
+ Archived on: Sat Aug 30 00:15:58 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-December.txt b/_build/static/archives/extend/2014-December.txt new file mode 100644 index 00000000..6296f55d --- /dev/null +++ b/_build/static/archives/extend/2014-December.txt @@ -0,0 +1,28 @@ +From tristan.sloughter at gmail.com Thu Dec 25 03:42:05 2014 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Wed, 25 Dec 2014 02:42:05 +0000 +Subject: [99s-extend] =?iso-8859-1?q?To=3Alebas_1?= +Message-ID: <6BD79E6D9F5F245BF6A056E4EF6AAB2A@smtp.online.net> + + + http://www.salaricevimenticiccarone.com/uxzx/flknraadbnipv.ohsuzvezlxsrhzgegyczlppiuxh + + + + + + + + + + + + + + + + Tristan Sloughter +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2014-December/000483.html b/_build/static/archives/extend/2014-December/000483.html new file mode 100644 index 00000000..ef5048ae --- /dev/null +++ b/_build/static/archives/extend/2014-December/000483.html @@ -0,0 +1,77 @@ + + + + [99s-extend] To:lebas 1 + + + + + + + + + + +

[99s-extend] To:lebas 1

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Thu Dec 25 03:42:05 CET 2014 +

+
+ +
+ http://www.salaricevimenticiccarone.com/uxzx/flknraadbnipv.ohsuzvezlxsrhzgegyczlppiuxh 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+  Tristan Sloughter
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141225/ff94953b/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-December/author.html b/_build/static/archives/extend/2014-December/author.html new file mode 100644 index 00000000..6b1f0c73 --- /dev/null +++ b/_build/static/archives/extend/2014-December/author.html @@ -0,0 +1,52 @@ + + + + The Extend December 2014 Archive by author + + + + + +

December 2014 Archives by author

+ +

Starting: Thu Dec 25 03:42:05 CET 2014
+ Ending: Thu Dec 25 03:42:05 CET 2014
+ Messages: 1

+

+

+ Last message date: + Thu Dec 25 03:42:05 CET 2014
+ Archived on: Thu Dec 25 02:42:13 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-December/date.html b/_build/static/archives/extend/2014-December/date.html new file mode 100644 index 00000000..d8f4c1d7 --- /dev/null +++ b/_build/static/archives/extend/2014-December/date.html @@ -0,0 +1,52 @@ + + + + The Extend December 2014 Archive by date + + + + + +

December 2014 Archives by date

+ +

Starting: Thu Dec 25 03:42:05 CET 2014
+ Ending: Thu Dec 25 03:42:05 CET 2014
+ Messages: 1

+

+

+ Last message date: + Thu Dec 25 03:42:05 CET 2014
+ Archived on: Thu Dec 25 02:42:13 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-December/index.html b/_build/static/archives/extend/2014-December/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-December/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-December/subject.html b/_build/static/archives/extend/2014-December/subject.html new file mode 100644 index 00000000..fcafdad2 --- /dev/null +++ b/_build/static/archives/extend/2014-December/subject.html @@ -0,0 +1,52 @@ + + + + The Extend December 2014 Archive by subject + + + + + +

December 2014 Archives by subject

+ +

Starting: Thu Dec 25 03:42:05 CET 2014
+ Ending: Thu Dec 25 03:42:05 CET 2014
+ Messages: 1

+

+

+ Last message date: + Thu Dec 25 03:42:05 CET 2014
+ Archived on: Thu Dec 25 02:42:13 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-December/thread.html b/_build/static/archives/extend/2014-December/thread.html new file mode 100644 index 00000000..742452e6 --- /dev/null +++ b/_build/static/archives/extend/2014-December/thread.html @@ -0,0 +1,53 @@ + + + + The Extend December 2014 Archive by thread + + + + + +

December 2014 Archives by thread

+ +

Starting: Thu Dec 25 03:42:05 CET 2014
+ Ending: Thu Dec 25 03:42:05 CET 2014
+ Messages: 1

+

+

+ Last message date: + Thu Dec 25 03:42:05 CET 2014
+ Archived on: Thu Dec 25 02:42:13 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-February.txt b/_build/static/archives/extend/2014-February.txt new file mode 100644 index 00000000..24900d19 --- /dev/null +++ b/_build/static/archives/extend/2014-February.txt @@ -0,0 +1,1332 @@ +From lukasz.biedrycki at gmail.com Mon Feb 3 19:13:04 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 3 Feb 2014 19:13:04 +0100 +Subject: [99s-extend] Accept header in POST request +Message-ID: + +Hi, +I have a rest handler that accepts POST and PUT requests with +?application/json? content type. + +I have content_types_accepted function defined as follows: + +content_types_accepted(Req, State) -> + {[{?application/json', from_json}], Req, State}. + + +The problem I have is within a request that has two headers: + +*Content-type*: application/json +*Accept*: application/json + +With this combination I receive *406*. + +You can repeat it with test: + +http_SUITE.erl: +1072 rest_postonly(Config) -> +1073 Client = ?config(client, Config), +1074 Headers = [ +1075 {<<"content-type">>, <<"text/plain">>}, +1076 {<<"accept">>, <<"text/plain">>} +1077 ], +1078 {ok, Client2} = cowboy_client:request(<<"POST">>, +1079 build_url("/postonly", Config), Headers, "12345", Client), +1080 {ok, 204, _, _} = cowboy_client:response(Client2). + +My solution to that was to add a content_types_provided function: + +content_types_provided(Req, State) -> + ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}], + {ContentTypes, Req, State}. + + +But it is useless as *to_json* callback registered is not called anyhow. + +Adding *content_types_provided* function is a correct solution in this case? +Or I am missing something here? +?Accept? header is not relevant only in case of GET requests? + +Thank for help, +?ukasz Biedrycki +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 3 19:23:32 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 03 Feb 2014 19:23:32 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: +References: +Message-ID: <52EFDEA4.6050004@ninenines.eu> + +The content-type provided is relevant for any response, not just +responses to GET requests. It defaults to text/html. If your client +doesn't send that content-type, you have to define the callback. + +I notice that the documentation is incorrect about the relevant methods +for this callback, I will open a ticket to fix it soon. + +On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +> Hi, +> I have a rest handler that accepts POST and PUT requests with +> ?application/json? content type. +> +> I have content_types_accepted function defined as follows: +> +> content_types_accepted(Req, State) -> +> +> +> {[{?application/json', from_json}], Req, State}. +> +> +> +> The problem I have is within a request that has two headers: +> +> *Content-type*: application/json +> *Accept*: application/json +> +> With this combination I receive *406*. +> +> You can repeat it with test: +> +> http_SUITE.erl: +> 1072 rest_postonly(Config) -> +> 1073 Client = ?config(client, Config), +> 1074 Headers = [ +> 1075 {<<"content-type">>, <<"text/plain">>}, +> 1076 {<<"accept">>, <<"text/plain">>} +> 1077 ], +> 1078 {ok, Client2} = cowboy_client:request(<<"POST">>, +> 1079 build_url("/postonly", Config), Headers, "12345", Client), +> 1080 {ok, 204, _, _} = cowboy_client:response(Client2). +> +> My solution to that was to add a content_types_provided function: +> +> +> content_types_provided(Req, State) -> +> +> +> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}], +> +> +> {ContentTypes, Req, State}. +> +> +> +> But it is useless as *to_json* callback registered is not called anyhow. +> +> Adding *content_types_provided* function is a correct solution in this case? +> Or I am missing something here? +> ?Accept? header is not relevant only in case of GET requests? +> +> Thank for help, +> ?ukasz Biedrycki +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lukasz.biedrycki at gmail.com Mon Feb 3 19:26:17 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 3 Feb 2014 19:26:17 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: <52EFDEA4.6050004@ninenines.eu> +References: + <52EFDEA4.6050004@ninenines.eu> +Message-ID: + +My application sends both headers: ?Content-type? and ?Accept? header using +POST method. + +For POST rest handler do I have to specify both: content_types_accepted and +content_types_provided to manage this kind of request? + + +On Mon, Feb 3, 2014 at 7:23 PM, Lo?c Hoguin wrote: + +> The content-type provided is relevant for any response, not just responses +> to GET requests. It defaults to text/html. If your client doesn't send that +> content-type, you have to define the callback. +> +> I notice that the documentation is incorrect about the relevant methods +> for this callback, I will open a ticket to fix it soon. +> +> +> On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +> +>> Hi, +>> I have a rest handler that accepts POST and PUT requests with +>> ?application/json? content type. +>> +>> I have content_types_accepted function defined as follows: +>> +>> content_types_accepted(Req, State) -> +>> +>> +>> {[{?application/json', from_json}], Req, State}. +>> +>> +>> +>> The problem I have is within a request that has two headers: +>> +>> *Content-type*: application/json +>> *Accept*: application/json +>> +>> With this combination I receive *406*. +>> +>> +>> You can repeat it with test: +>> +>> http_SUITE.erl: +>> 1072 rest_postonly(Config) -> +>> 1073 Client = ?config(client, Config), +>> 1074 Headers = [ +>> 1075 {<<"content-type">>, <<"text/plain">>}, +>> 1076 {<<"accept">>, <<"text/plain">>} +>> 1077 ], +>> 1078 {ok, Client2} = cowboy_client:request(<<"POST">>, +>> 1079 build_url("/postonly", Config), Headers, "12345", Client), +>> 1080 {ok, 204, _, _} = cowboy_client:response(Client2). +>> +>> My solution to that was to add a content_types_provided function: +>> +>> +>> content_types_provided(Req, State) -> +>> +>> +>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}], +>> +>> +>> {ContentTypes, Req, State}. +>> +>> +>> +>> But it is useless as *to_json* callback registered is not called anyhow. +>> +>> Adding *content_types_provided* function is a correct solution in this +>> case? +>> +>> Or I am missing something here? +>> ?Accept? header is not relevant only in case of GET requests? +>> +>> Thank for help, +>> ?ukasz Biedrycki +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 3 19:37:55 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 03 Feb 2014 19:37:55 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: +References: + <52EFDEA4.6050004@ninenines.eu> + +Message-ID: <52EFE203.4020702@ninenines.eu> + +If Accept is sent and is different than text/html, yes. + +This is how HTTP is defined. If the client says it speaks only +content-type X but you can only reply with content-type Y, you error out +early and stop processing the request. On the other hand if the client +doesn't say what content-type it speaks then the server can choose +whichever one it wants. + +On 02/03/2014 07:26 PM, ?ukasz Biedrycki wrote: +> My application sends both headers: ?Content-type? and ?Accept? header +> using POST method. +> +> For POST rest handler do I have to specify both: content_types_accepted +> and content_types_provided to manage this kind of request? +> +> +> On Mon, Feb 3, 2014 at 7:23 PM, Lo?c Hoguin > wrote: +> +> The content-type provided is relevant for any response, not just +> responses to GET requests. It defaults to text/html. If your client +> doesn't send that content-type, you have to define the callback. +> +> I notice that the documentation is incorrect about the relevant +> methods for this callback, I will open a ticket to fix it soon. +> +> +> On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +> +> Hi, +> I have a rest handler that accepts POST and PUT requests with +> ?application/json? content type. +> +> I have content_types_accepted function defined as follows: +> +> content_types_accepted(Req, State) -> +> +> +> {[{?application/json', from_json}], Req, State}. +> +> +> +> The problem I have is within a request that has two headers: +> +> *Content-type*: application/json +> *Accept*: application/json +> +> With this combination I receive *406*. +> +> +> You can repeat it with test: +> +> http_SUITE.erl: +> 1072 rest_postonly(Config) -> +> 1073 Client = ?config(client, Config), +> 1074 Headers = [ +> 1075 {<<"content-type">>, <<"text/plain">>}, +> 1076 {<<"accept">>, <<"text/plain">>} +> 1077 ], +> 1078 {ok, Client2} = cowboy_client:request(<<"POST"__>>, +> 1079 build_url("/postonly", Config), Headers, "12345", +> Client), +> 1080 {ok, 204, _, _} = cowboy_client:response(__Client2). +> +> My solution to that was to add a content_types_provided function: +> +> +> content_types_provided(Req, State) -> +> +> +> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}], +> +> +> {ContentTypes, Req, State}. +> +> +> +> But it is useless as *to_json* callback registered is not called +> anyhow. +> +> Adding *content_types_provided* function is a correct solution +> in this case? +> +> Or I am missing something here? +> ?Accept? header is not relevant only in case of GET requests? +> +> Thank for help, +> ?ukasz Biedrycki +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/__listinfo/extend +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lukasz.biedrycki at gmail.com Mon Feb 3 20:08:12 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 3 Feb 2014 20:08:12 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: <52EFE203.4020702@ninenines.eu> +References: + <52EFDEA4.6050004@ninenines.eu> + + <52EFE203.4020702@ninenines.eu> +Message-ID: + +Ok, +it is more clear for me. + +Last question I have is about content_types_provided function. + +Is it safe to define it like this? + +content_types_provided(R, S) -> + ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}], + {ContentTypes, Req, State}. + +Callback in content_types_provided is useless for POST requests, as it +won?t be called. +Is it safe to use *undefined *atom, to have a source code clearer? + + + + +On Mon, Feb 3, 2014 at 7:37 PM, Lo?c Hoguin wrote: + +> If Accept is sent and is different than text/html, yes. +> +> This is how HTTP is defined. If the client says it speaks only +> content-type X but you can only reply with content-type Y, you error out +> early and stop processing the request. On the other hand if the client +> doesn't say what content-type it speaks then the server can choose +> whichever one it wants. +> +> +> On 02/03/2014 07:26 PM, ?ukasz Biedrycki wrote: +> +>> My application sends both headers: ?Content-type? and ?Accept? header +>> using POST method. +>> +>> For POST rest handler do I have to specify both: content_types_accepted +>> and content_types_provided to manage this kind of request? +>> +>> +>> On Mon, Feb 3, 2014 at 7:23 PM, Lo?c Hoguin > > wrote: +>> +>> The content-type provided is relevant for any response, not just +>> responses to GET requests. It defaults to text/html. If your client +>> doesn't send that content-type, you have to define the callback. +>> +>> I notice that the documentation is incorrect about the relevant +>> methods for this callback, I will open a ticket to fix it soon. +>> +>> +>> On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +>> +>> Hi, +>> I have a rest handler that accepts POST and PUT requests with +>> ?application/json? content type. +>> +>> I have content_types_accepted function defined as follows: +>> +>> content_types_accepted(Req, State) -> +>> +>> +>> {[{?application/json', from_json}], Req, State}. +>> +>> +>> +>> The problem I have is within a request that has two headers: +>> +>> *Content-type*: application/json +>> *Accept*: application/json +>> +>> With this combination I receive *406*. +>> +>> +>> You can repeat it with test: +>> +>> http_SUITE.erl: +>> 1072 rest_postonly(Config) -> +>> 1073 Client = ?config(client, Config), +>> 1074 Headers = [ +>> 1075 {<<"content-type">>, <<"text/plain">>}, +>> 1076 {<<"accept">>, <<"text/plain">>} +>> 1077 ], +>> 1078 {ok, Client2} = cowboy_client:request(<<"POST"__>>, +>> +>> 1079 build_url("/postonly", Config), Headers, "12345", +>> Client), +>> 1080 {ok, 204, _, _} = cowboy_client:response(__Client2). +>> +>> +>> My solution to that was to add a content_types_provided function: +>> +>> +>> content_types_provided(Req, State) -> +>> +>> +>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}], +>> +>> +>> {ContentTypes, Req, State}. +>> +>> +>> +>> But it is useless as *to_json* callback registered is not called +>> anyhow. +>> +>> Adding *content_types_provided* function is a correct solution +>> in this case? +>> +>> Or I am missing something here? +>> ?Accept? header is not relevant only in case of GET requests? +>> +>> Thank for help, +>> ?ukasz Biedrycki +>> +>> +>> _________________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/__listinfo/extend +>> +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 3 20:15:44 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 03 Feb 2014 20:15:44 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: +References: + <52EFDEA4.6050004@ninenines.eu> + + <52EFE203.4020702@ninenines.eu> + +Message-ID: <52EFEAE0.7050804@ninenines.eu> + +Sure. It won't be called if not a GET or HEAD request so that's probably +the best value you can return in your case. + +On 02/03/2014 08:08 PM, ?ukasz Biedrycki wrote: +> Ok, +> it is more clear for me. +> +> Last question I have is about content_types_provided function. +> +> Is it safe to define it like this? +> +> content_types_provided(R, S) -> +> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}], +> {ContentTypes, Req, State}. +> +> Callback in content_types_provided is useless for POST requests, as it +> won?t be called. +> Is it safe to use *undefined *atom, to have a source code clearer? +> +> +> +> +> On Mon, Feb 3, 2014 at 7:37 PM, Lo?c Hoguin > wrote: +> +> If Accept is sent and is different than text/html, yes. +> +> This is how HTTP is defined. If the client says it speaks only +> content-type X but you can only reply with content-type Y, you error +> out early and stop processing the request. On the other hand if the +> client doesn't say what content-type it speaks then the server can +> choose whichever one it wants. +> +> +> On 02/03/2014 07:26 PM, ?ukasz Biedrycki wrote: +> +> My application sends both headers: ?Content-type? and ?Accept? +> header +> using POST method. +> +> For POST rest handler do I have to specify both: +> content_types_accepted +> and content_types_provided to manage this kind of request? +> +> +> On Mon, Feb 3, 2014 at 7:23 PM, Lo?c Hoguin +> >> wrote: +> +> The content-type provided is relevant for any response, not +> just +> responses to GET requests. It defaults to text/html. If +> your client +> doesn't send that content-type, you have to define the +> callback. +> +> I notice that the documentation is incorrect about the relevant +> methods for this callback, I will open a ticket to fix it soon. +> +> +> On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +> +> Hi, +> I have a rest handler that accepts POST and PUT +> requests with +> ?application/json? content type. +> +> I have content_types_accepted function defined as follows: +> +> content_types_accepted(Req, State) -> +> +> +> {[{?application/json', from_json}], Req, State}. +> +> +> +> The problem I have is within a request that has two +> headers: +> +> *Content-type*: application/json +> *Accept*: application/json +> +> With this combination I receive *406*. +> +> +> You can repeat it with test: +> +> http_SUITE.erl: +> 1072 rest_postonly(Config) -> +> 1073 Client = ?config(client, Config), +> 1074 Headers = [ +> 1075 {<<"content-type">>, <<"text/plain">>}, +> 1076 {<<"accept">>, <<"text/plain">>} +> 1077 ], +> 1078 {ok, Client2} = +> cowboy_client:request(<<"POST"____>>, +> +> 1079 build_url("/postonly", Config), Headers, +> "12345", +> Client), +> 1080 {ok, 204, _, _} = +> cowboy_client:response(____Client2). +> +> +> My solution to that was to add a content_types_provided +> function: +> +> +> content_types_provided(Req, State) -> +> +> +> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, +> to_json}], +> +> +> {ContentTypes, Req, State}. +> +> +> +> But it is useless as *to_json* callback registered is +> not called +> anyhow. +> +> Adding *content_types_provided* function is a correct +> solution +> in this case? +> +> Or I am missing something here? +> ?Accept? header is not relevant only in case of GET +> requests? +> +> Thank for help, +> ?ukasz Biedrycki +> +> +> ___________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> > +> https://lists.ninenines.eu/____listinfo/extend +> +> +> > +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lukasz.biedrycki at gmail.com Mon Feb 3 20:16:29 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 3 Feb 2014 20:16:29 +0100 +Subject: [99s-extend] Accept header in POST request +In-Reply-To: <52EFEAE0.7050804@ninenines.eu> +References: + <52EFDEA4.6050004@ninenines.eu> + + <52EFE203.4020702@ninenines.eu> + + <52EFEAE0.7050804@ninenines.eu> +Message-ID: + +Perfect, thanks a lot! +Cheers, +?. + + +On Mon, Feb 3, 2014 at 8:15 PM, Lo?c Hoguin wrote: + +> Sure. It won't be called if not a GET or HEAD request so that's probably +> the best value you can return in your case. +> +> +> On 02/03/2014 08:08 PM, ?ukasz Biedrycki wrote: +> +>> Ok, +>> it is more clear for me. +>> +>> Last question I have is about content_types_provided function. +>> +>> Is it safe to define it like this? +>> +>> content_types_provided(R, S) -> +>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}], +>> +>> {ContentTypes, Req, State}. +>> +>> Callback in content_types_provided is useless for POST requests, as it +>> won?t be called. +>> Is it safe to use *undefined *atom, to have a source code clearer? +>> +>> +>> +>> +>> +>> On Mon, Feb 3, 2014 at 7:37 PM, Lo?c Hoguin > > wrote: +>> +>> If Accept is sent and is different than text/html, yes. +>> +>> This is how HTTP is defined. If the client says it speaks only +>> content-type X but you can only reply with content-type Y, you error +>> out early and stop processing the request. On the other hand if the +>> client doesn't say what content-type it speaks then the server can +>> choose whichever one it wants. +>> +>> +>> On 02/03/2014 07:26 PM, ?ukasz Biedrycki wrote: +>> +>> My application sends both headers: ?Content-type? and ?Accept? +>> header +>> using POST method. +>> +>> For POST rest handler do I have to specify both: +>> content_types_accepted +>> and content_types_provided to manage this kind of request? +>> +>> +>> On Mon, Feb 3, 2014 at 7:23 PM, Lo?c Hoguin > +>> >> wrote: +>> +>> The content-type provided is relevant for any response, not +>> just +>> responses to GET requests. It defaults to text/html. If +>> your client +>> doesn't send that content-type, you have to define the +>> callback. +>> +>> I notice that the documentation is incorrect about the +>> relevant +>> methods for this callback, I will open a ticket to fix it +>> soon. +>> +>> +>> On 02/03/2014 07:13 PM, ?ukasz Biedrycki wrote: +>> +>> Hi, +>> I have a rest handler that accepts POST and PUT +>> requests with +>> ?application/json? content type. +>> +>> I have content_types_accepted function defined as +>> follows: +>> +>> content_types_accepted(Req, State) -> +>> +>> +>> {[{?application/json', from_json}], Req, State}. +>> +>> +>> +>> The problem I have is within a request that has two +>> headers: +>> +>> *Content-type*: application/json +>> *Accept*: application/json +>> +>> With this combination I receive *406*. +>> +>> +>> You can repeat it with test: +>> +>> http_SUITE.erl: +>> 1072 rest_postonly(Config) -> +>> 1073 Client = ?config(client, Config), +>> 1074 Headers = [ +>> 1075 {<<"content-type">>, <<"text/plain">>}, +>> 1076 {<<"accept">>, <<"text/plain">>} +>> 1077 ], +>> 1078 {ok, Client2} = +>> cowboy_client:request(<<"POST"____>>, +>> +>> +>> 1079 build_url("/postonly", Config), Headers, +>> "12345", +>> Client), +>> 1080 {ok, 204, _, _} = +>> cowboy_client:response(____Client2). +>> +>> +>> +>> My solution to that was to add a content_types_provided +>> function: +>> +>> +>> content_types_provided(Req, State) -> +>> +>> +>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, +>> to_json}], +>> +>> +>> {ContentTypes, Req, State}. +>> +>> +>> +>> But it is useless as *to_json* callback registered is +>> not called +>> anyhow. +>> +>> Adding *content_types_provided* function is a correct +>> solution +>> in this case? +>> +>> Or I am missing something here? +>> ?Accept? header is not relevant only in case of GET +>> requests? +>> +>> Thank for help, +>> ?ukasz Biedrycki +>> +>> +>> ___________________________________________________ +>> +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> > > +>> https://lists.ninenines.eu/____listinfo/extend +>> +>> +>> +>> > > +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lukasz.biedrycki at gmail.com Fri Feb 7 17:56:26 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Fri, 7 Feb 2014 17:56:26 +0100 +Subject: [99s-extend] Metrics per request and handler +Message-ID: + +Hi, +in my application I would like to add some metrics per handler and per +response http status code. + +One way is to add on response callback function, but there I do not have an +information about handler and handler opts. + +Second way is to add a middleware, but then I do not have an information +about response status code. + +Frankly, I like second way more. +How do like an idea to add response status code to request record similar +to: resp_headers or resp_body ? + +Cheers, +?ukasz Biedrycki +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lukasz.biedrycki at gmail.com Mon Feb 10 10:41:13 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 10 Feb 2014 10:41:13 +0100 +Subject: [99s-extend] Metrics per request and handler +In-Reply-To: +References: +Message-ID: + +Hi again, +another idea is to make environment (Env), which is passed between +middlewares, a part of Request record, so I could have an access to it in +onresponse callback. + +Any of that makes sense? + +Cheers, +?ukasz Biedrycki + + +On Fri, Feb 7, 2014 at 5:56 PM, ?ukasz Biedrycki wrote: + +> Hi, +> in my application I would like to add some metrics per handler and per +> response http status code. +> +> One way is to add on response callback function, but there I do not have +> an information about handler and handler opts. +> +> Second way is to add a middleware, but then I do not have an information +> about response status code. +> +> Frankly, I like second way more. +> How do like an idea to add response status code to request record similar +> to: resp_headers or resp_body ? +> +> Cheers, +> ?ukasz Biedrycki +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 10 10:49:24 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 10 Feb 2014 10:49:24 +0100 +Subject: [99s-extend] Metrics per request and handler +In-Reply-To: +References: + +Message-ID: <52F8A0A4.8030109@ninenines.eu> + +You have the meta values in Req which are passed everywhere. You can +easily set and retrieve them. + +On 02/10/2014 10:41 AM, ?ukasz Biedrycki wrote: +> Hi again, +> another idea is to make environment (Env), which is passed between +> middlewares, a part of Request record, so I could have an access to it in +> onresponse callback. +> +> Any of that makes sense? +> +> Cheers, +> ?ukasz Biedrycki +> +> +> On Fri, Feb 7, 2014 at 5:56 PM, ?ukasz Biedrycki > wrote: +> +>> Hi, +>> in my application I would like to add some metrics per handler and per +>> response http status code. +>> +>> One way is to add on response callback function, but there I do not have +>> an information about handler and handler opts. +>> +>> Second way is to add a middleware, but then I do not have an information +>> about response status code. +>> +>> Frankly, I like second way more. +>> How do like an idea to add response status code to request record similar +>> to: resp_headers or resp_body ? +>> +>> Cheers, +>> ?ukasz Biedrycki +>> +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lukasz.biedrycki at gmail.com Mon Feb 10 10:51:50 2014 +From: lukasz.biedrycki at gmail.com (=?ISO-8859-2?Q?=A3ukasz_Biedrycki?=) +Date: Mon, 10 Feb 2014 10:51:50 +0100 +Subject: [99s-extend] Metrics per request and handler +In-Reply-To: <52F8A0A4.8030109@ninenines.eu> +References: + + <52F8A0A4.8030109@ninenines.eu> +Message-ID: + +Hey, +I didn?t know about that. +That is exactly what I need! +Thank you! + +Cheers, +?ukasz Biedrycki + + +On Mon, Feb 10, 2014 at 10:49 AM, Lo?c Hoguin wrote: + +> You have the meta values in Req which are passed everywhere. You can +> easily set and retrieve them. +> +> +> On 02/10/2014 10:41 AM, ?ukasz Biedrycki wrote: +> +>> Hi again, +>> another idea is to make environment (Env), which is passed between +>> middlewares, a part of Request record, so I could have an access to it in +>> onresponse callback. +>> +>> Any of that makes sense? +>> +>> Cheers, +>> ?ukasz Biedrycki +>> +>> +>> On Fri, Feb 7, 2014 at 5:56 PM, ?ukasz Biedrycki < +>> lukasz.biedrycki at gmail.com +>> +>>> wrote: +>>> +>> +>> Hi, +>>> in my application I would like to add some metrics per handler and per +>>> response http status code. +>>> +>>> One way is to add on response callback function, but there I do not have +>>> an information about handler and handler opts. +>>> +>>> Second way is to add a middleware, but then I do not have an information +>>> about response status code. +>>> +>>> Frankly, I like second way more. +>>> How do like an idea to add response status code to request record similar +>>> to: resp_headers or resp_body ? +>>> +>>> Cheers, +>>> ?ukasz Biedrycki +>>> +>>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From psihonavt at gmail.com Mon Feb 10 19:44:54 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Mon, 10 Feb 2014 20:44:54 +0200 +Subject: [99s-extend] do not treat warnings as errors on make? +Message-ID: + +Hello, + +as I understand, by default `make all` performs compile with option +warnings_as_errors. How can I disable this option? +There are options described at +https://github.com/extend/erlang.mk#optionsand I believe that +ERLC_OPTS +should be filled with `-warnings_as_errors`. But it is unclear for me where +have I to add(put) that option? + +Thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Feb 10 19:48:01 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 10 Feb 2014 19:48:01 +0100 +Subject: [99s-extend] do not treat warnings as errors on make? +In-Reply-To: +References: +Message-ID: <52F91EE1.7040809@ninenines.eu> + +You can just define ERLC_OPTS before you include erlang.mk and it'll use +that instead. I'm not sure why you want to disable that though, warnings +usually alert you of bugs in your code. + +On 02/10/2014 07:44 PM, Anton Koval' wrote: +> Hello, +> +> as I understand, by default `make all` performs compile with +> option**warnings_as_errors.**How can I disable this option? +> There are options described at +> https://github.com/extend/erlang.mk#options and I believe that +> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is +> unclear for me where have I to add(put) that option? +> +> Thanks. +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From psihonavt at gmail.com Mon Feb 10 20:22:49 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Mon, 10 Feb 2014 21:22:49 +0200 +Subject: [99s-extend] do not treat warnings as errors on make? +In-Reply-To: <52F91EE1.7040809@ninenines.eu> +References: + <52F91EE1.7040809@ninenines.eu> +Message-ID: + +Thanks for explanation. +My situation: I'm developing some stuff in module. That module in some kind +of "draft' state (e.g. some functions are unused), but regardless that I +want to compile project in order to test some specific parts of that +module. + + +On Mon, Feb 10, 2014 at 8:48 PM, Lo?c Hoguin wrote: + +> You can just define ERLC_OPTS before you include erlang.mk and it'll use +> that instead. I'm not sure why you want to disable that though, warnings +> usually alert you of bugs in your code. +> +> +> On 02/10/2014 07:44 PM, Anton Koval' wrote: +> +>> Hello, +>> +>> as I understand, by default `make all` performs compile with +>> option**warnings_as_errors.**How can I disable this option? +>> +>> There are options described at +>> https://github.com/extend/erlang.mk#options and I believe that +>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is +>> +>> unclear for me where have I to add(put) that option? +>> +>> Thanks. +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ivan at llaisdy.com Mon Feb 10 20:46:54 2014 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Mon, 10 Feb 2014 19:46:54 +0000 +Subject: [99s-extend] do not treat warnings as errors on make? +In-Reply-To: +References: + <52F91EE1.7040809@ninenines.eu> + +Message-ID: <2424F399-12CA-455D-ACEE-45882873B1D4@llaisdy.com> + +I promise you, improving the code now to get rid of the warnings is worth it. + +Ivan + +-- +festina lente + + +> On 10 Feb 2014, at 19:22, "Anton Koval'" wrote: +> +> Thanks for explanation. +> My situation: I'm developing some stuff in module. That module in some kind of "draft' state (e.g. some functions are unused), but regardless that I want to compile project in order to test some specific parts of that module. +> +> +>> On Mon, Feb 10, 2014 at 8:48 PM, Lo?c Hoguin wrote: +>> You can just define ERLC_OPTS before you include erlang.mk and it'll use that instead. I'm not sure why you want to disable that though, warnings usually alert you of bugs in your code. +>> +>> +>>> On 02/10/2014 07:44 PM, Anton Koval' wrote: +>>> Hello, +>>> +>>> as I understand, by default `make all` performs compile with +>>> option**warnings_as_errors.**How can I disable this option? +>>> +>>> There are options described at +>>> https://github.com/extend/erlang.mk#options and I believe that +>>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is +>>> +>>> unclear for me where have I to add(put) that option? +>>> +>>> Thanks. +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From psihonavt at gmail.com Mon Feb 10 20:55:24 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Mon, 10 Feb 2014 21:55:24 +0200 +Subject: [99s-extend] do not treat warnings as errors on make? +In-Reply-To: <2424F399-12CA-455D-ACEE-45882873B1D4@llaisdy.com> +References: + <52F91EE1.7040809@ninenines.eu> + + <2424F399-12CA-455D-ACEE-45882873B1D4@llaisdy.com> +Message-ID: + +Got it! :) +fixed all warnings and removed ERLC_OPTS from Makefile. + + +On Mon, Feb 10, 2014 at 9:46 PM, Ivan Uemlianin wrote: + +> I promise you, improving the code now to get rid of the warnings is worth +> it. +> +> Ivan +> +> -- +> festina lente +> +> +> On 10 Feb 2014, at 19:22, "Anton Koval'" wrote: +> +> Thanks for explanation. +> My situation: I'm developing some stuff in module. That module in some +> kind of "draft' state (e.g. some functions are unused), but regardless that +> I want to compile project in order to test some specific parts of that +> module. +> +> +> On Mon, Feb 10, 2014 at 8:48 PM, Lo?c Hoguin wrote: +> +>> You can just define ERLC_OPTS before you include erlang.mk and it'll use +>> that instead. I'm not sure why you want to disable that though, warnings +>> usually alert you of bugs in your code. +>> +>> +>> On 02/10/2014 07:44 PM, Anton Koval' wrote: +>> +>>> Hello, +>>> +>>> as I understand, by default `make all` performs compile with +>>> option**warnings_as_errors.**How can I disable this option? +>>> +>>> There are options described at +>>> https://github.com/extend/erlang.mk#options and I believe that +>>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is +>>> +>>> unclear for me where have I to add(put) that option? +>>> +>>> Thanks. +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2014-February/000324.html b/_build/static/archives/extend/2014-February/000324.html new file mode 100644 index 00000000..6fc1fc47 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000324.html @@ -0,0 +1,106 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 3 19:13:04 CET 2014 +

+
+ +
Hi,
+I have a rest handler that accepts POST and PUT requests with
+“application/json” content type.
+
+I have content_types_accepted function defined as follows:
+
+content_types_accepted(Req, State) ->
+    {[{‘application/json', from_json}], Req, State}.
+
+
+The problem I have is within a request that has two headers:
+
+*Content-type*: application/json
+*Accept*: application/json
+
+With this combination I receive *406*.
+
+You can repeat it with test:
+
+http_SUITE.erl:
+1072 rest_postonly(Config) ->
+1073     Client = ?config(client, Config),
+1074     Headers = [
+1075         {<<"content-type">>, <<"text/plain">>},
+1076         {<<"accept">>, <<"text/plain">>}
+1077     ],
+1078     {ok, Client2} = cowboy_client:request(<<"POST">>,
+1079         build_url("/postonly", Config), Headers, "12345", Client),
+1080     {ok, 204, _, _} = cowboy_client:response(Client2).
+
+My solution to that was to add a content_types_provided function:
+
+content_types_provided(Req, State) ->
+    ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
+    {ContentTypes, Req, State}.
+
+
+But it is useless as *to_json* callback registered is not called anyhow.
+
+Adding *content_types_provided* function is a correct solution in this case?
+Or I am missing something here?
+“Accept” header is not relevant only in case of GET requests?
+
+Thank for help,
+Łukasz Biedrycki
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140203/104f8577/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000325.html b/_build/static/archives/extend/2014-February/000325.html new file mode 100644 index 00000000..784e1a10 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000325.html @@ -0,0 +1,134 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 3 19:23:32 CET 2014 +

+
+ +
The content-type provided is relevant for any response, not just 
+responses to GET requests. It defaults to text/html. If your client 
+doesn't send that content-type, you have to define the callback.
+
+I notice that the documentation is incorrect about the relevant methods 
+for this callback, I will open a ticket to fix it soon.
+
+On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+> Hi,
+> I have a rest handler that accepts POST and PUT requests with
+> “application/json” content type.
+>
+> I have content_types_accepted function defined as follows:
+>
+> content_types_accepted(Req, State) ->
+>
+>
+> {[{‘application/json', from_json}], Req, State}.
+>
+>
+>
+> The problem I have is within a request that has two headers:
+>
+> *Content-type*: application/json
+> *Accept*: application/json
+>
+> With this combination I receive *406*.
+>
+> You can repeat it with test:
+>
+> http_SUITE.erl:
+> 1072 rest_postonly(Config) ->
+> 1073     Client = ?config(client, Config),
+> 1074     Headers = [
+> 1075         {<<"content-type">>, <<"text/plain">>},
+> 1076         {<<"accept">>, <<"text/plain">>}
+> 1077     ],
+> 1078     {ok, Client2} = cowboy_client:request(<<"POST">>,
+> 1079         build_url("/postonly", Config), Headers, "12345", Client),
+> 1080     {ok, 204, _, _} = cowboy_client:response(Client2).
+>
+> My solution to that was to add a content_types_provided function:
+>
+>
+> content_types_provided(Req, State) ->
+>
+>
+> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
+>
+>
+> {ContentTypes, Req, State}.
+>
+>
+>
+> But it is useless as *to_json* callback registered is not called anyhow.
+>
+> Adding *content_types_provided* function is a correct solution in this case?
+> Or I am missing something here?
+> “Accept” header is not relevant only in case of GET requests?
+>
+> Thank for help,
+> Łukasz Biedrycki
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000326.html b/_build/static/archives/extend/2014-February/000326.html new file mode 100644 index 00000000..98ef5924 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000326.html @@ -0,0 +1,151 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 3 19:26:17 CET 2014 +

+
+ +
My application sends both headers: “Content-type” and “Accept” header using
+POST method.
+
+For POST rest handler do I have to specify both: content_types_accepted and
+content_types_provided to manage this kind of request?
+
+
+On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> The content-type provided is relevant for any response, not just responses
+> to GET requests. It defaults to text/html. If your client doesn't send that
+> content-type, you have to define the callback.
+>
+> I notice that the documentation is incorrect about the relevant methods
+> for this callback, I will open a ticket to fix it soon.
+>
+>
+> On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+>
+>> Hi,
+>> I have a rest handler that accepts POST and PUT requests with
+>> “application/json” content type.
+>>
+>> I have content_types_accepted function defined as follows:
+>>
+>> content_types_accepted(Req, State) ->
+>>
+>>
+>> {[{‘application/json', from_json}], Req, State}.
+>>
+>>
+>>
+>> The problem I have is within a request that has two headers:
+>>
+>> *Content-type*: application/json
+>> *Accept*: application/json
+>>
+>> With this combination I receive *406*.
+>>
+>>
+>> You can repeat it with test:
+>>
+>> http_SUITE.erl:
+>> 1072 rest_postonly(Config) ->
+>> 1073     Client = ?config(client, Config),
+>> 1074     Headers = [
+>> 1075         {<<"content-type">>, <<"text/plain">>},
+>> 1076         {<<"accept">>, <<"text/plain">>}
+>> 1077     ],
+>> 1078     {ok, Client2} = cowboy_client:request(<<"POST">>,
+>> 1079         build_url("/postonly", Config), Headers, "12345", Client),
+>> 1080     {ok, 204, _, _} = cowboy_client:response(Client2).
+>>
+>> My solution to that was to add a content_types_provided function:
+>>
+>>
+>> content_types_provided(Req, State) ->
+>>
+>>
+>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
+>>
+>>
+>> {ContentTypes, Req, State}.
+>>
+>>
+>>
+>> But it is useless as *to_json* callback registered is not called anyhow.
+>>
+>> Adding *content_types_provided* function is a correct solution in this
+>> case?
+>>
+>> Or I am missing something here?
+>> “Accept” header is not relevant only in case of GET requests?
+>>
+>> Thank for help,
+>> Łukasz Biedrycki
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140203/2982cff3/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000327.html b/_build/static/archives/extend/2014-February/000327.html new file mode 100644 index 00000000..d9e2859b --- /dev/null +++ b/_build/static/archives/extend/2014-February/000327.html @@ -0,0 +1,167 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 3 19:37:55 CET 2014 +

+
+ +
If Accept is sent and is different than text/html, yes.
+
+This is how HTTP is defined. If the client says it speaks only 
+content-type X but you can only reply with content-type Y, you error out 
+early and stop processing the request. On the other hand if the client 
+doesn't say what content-type it speaks then the server can choose 
+whichever one it wants.
+
+On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
+> My application sends both headers: “Content-type” and “Accept” header
+> using POST method.
+>
+> For POST rest handler do I have to specify both: content_types_accepted
+> and content_types_provided to manage this kind of request?
+>
+>
+> On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     The content-type provided is relevant for any response, not just
+>     responses to GET requests. It defaults to text/html. If your client
+>     doesn't send that content-type, you have to define the callback.
+>
+>     I notice that the documentation is incorrect about the relevant
+>     methods for this callback, I will open a ticket to fix it soon.
+>
+>
+>     On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+>
+>         Hi,
+>         I have a rest handler that accepts POST and PUT requests with
+>         “application/json” content type.
+>
+>         I have content_types_accepted function defined as follows:
+>
+>         content_types_accepted(Req, State) ->
+>
+>
+>         {[{‘application/json', from_json}], Req, State}.
+>
+>
+>
+>         The problem I have is within a request that has two headers:
+>
+>         *Content-type*: application/json
+>         *Accept*: application/json
+>
+>         With this combination I receive *406*.
+>
+>
+>         You can repeat it with test:
+>
+>         http_SUITE.erl:
+>         1072 rest_postonly(Config) ->
+>         1073     Client = ?config(client, Config),
+>         1074     Headers = [
+>         1075         {<<"content-type">>, <<"text/plain">>},
+>         1076         {<<"accept">>, <<"text/plain">>}
+>         1077     ],
+>         1078     {ok, Client2} = cowboy_client:request(<<"POST"__>>,
+>         1079         build_url("/postonly", Config), Headers, "12345",
+>         Client),
+>         1080     {ok, 204, _, _} = cowboy_client:response(__Client2).
+>
+>         My solution to that was to add a content_types_provided function:
+>
+>
+>         content_types_provided(Req, State) ->
+>
+>
+>         ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
+>
+>
+>         {ContentTypes, Req, State}.
+>
+>
+>
+>         But it is useless as *to_json* callback registered is not called
+>         anyhow.
+>
+>         Adding *content_types_provided* function is a correct solution
+>         in this case?
+>
+>         Or I am missing something here?
+>         “Accept” header is not relevant only in case of GET requests?
+>
+>         Thank for help,
+>         Łukasz Biedrycki
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         https://lists.ninenines.eu/__listinfo/extend
+>         <https://lists.ninenines.eu/listinfo/extend>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000328.html b/_build/static/archives/extend/2014-February/000328.html new file mode 100644 index 00000000..95c2b425 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000328.html @@ -0,0 +1,195 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 3 20:08:12 CET 2014 +

+
+ +
Ok,
+it is more clear for me.
+
+Last question I have is about content_types_provided function.
+
+Is it safe to define it like this?
+
+content_types_provided(R, S) ->
+   ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],
+   {ContentTypes, Req, State}.
+
+Callback in content_types_provided is useless for POST requests, as it
+won’t be called.
+Is it safe to use *undefined *atom, to have a source code clearer?
+
+
+
+
+On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> If Accept is sent and is different than text/html, yes.
+>
+> This is how HTTP is defined. If the client says it speaks only
+> content-type X but you can only reply with content-type Y, you error out
+> early and stop processing the request. On the other hand if the client
+> doesn't say what content-type it speaks then the server can choose
+> whichever one it wants.
+>
+>
+> On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
+>
+>> My application sends both headers: “Content-type” and “Accept” header
+>> using POST method.
+>>
+>> For POST rest handler do I have to specify both: content_types_accepted
+>> and content_types_provided to manage this kind of request?
+>>
+>>
+>> On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     The content-type provided is relevant for any response, not just
+>>     responses to GET requests. It defaults to text/html. If your client
+>>     doesn't send that content-type, you have to define the callback.
+>>
+>>     I notice that the documentation is incorrect about the relevant
+>>     methods for this callback, I will open a ticket to fix it soon.
+>>
+>>
+>>     On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+>>
+>>         Hi,
+>>         I have a rest handler that accepts POST and PUT requests with
+>>         “application/json” content type.
+>>
+>>         I have content_types_accepted function defined as follows:
+>>
+>>         content_types_accepted(Req, State) ->
+>>
+>>
+>>         {[{‘application/json', from_json}], Req, State}.
+>>
+>>
+>>
+>>         The problem I have is within a request that has two headers:
+>>
+>>         *Content-type*: application/json
+>>         *Accept*: application/json
+>>
+>>         With this combination I receive *406*.
+>>
+>>
+>>         You can repeat it with test:
+>>
+>>         http_SUITE.erl:
+>>         1072 rest_postonly(Config) ->
+>>         1073     Client = ?config(client, Config),
+>>         1074     Headers = [
+>>         1075         {<<"content-type">>, <<"text/plain">>},
+>>         1076         {<<"accept">>, <<"text/plain">>}
+>>         1077     ],
+>>         1078     {ok, Client2} = cowboy_client:request(<<"POST"__>>,
+>>
+>>         1079         build_url("/postonly", Config), Headers, "12345",
+>>         Client),
+>>         1080     {ok, 204, _, _} = cowboy_client:response(__Client2).
+>>
+>>
+>>         My solution to that was to add a content_types_provided function:
+>>
+>>
+>>         content_types_provided(Req, State) ->
+>>
+>>
+>>         ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],
+>>
+>>
+>>         {ContentTypes, Req, State}.
+>>
+>>
+>>
+>>         But it is useless as *to_json* callback registered is not called
+>>         anyhow.
+>>
+>>         Adding *content_types_provided* function is a correct solution
+>>         in this case?
+>>
+>>         Or I am missing something here?
+>>         “Accept” header is not relevant only in case of GET requests?
+>>
+>>         Thank for help,
+>>         Łukasz Biedrycki
+>>
+>>
+>>         _________________________________________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         https://lists.ninenines.eu/__listinfo/extend
+>>
+>>         <https://lists.ninenines.eu/listinfo/extend>
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140203/088e7e6a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000329.html b/_build/static/archives/extend/2014-February/000329.html new file mode 100644 index 00000000..7668623a --- /dev/null +++ b/_build/static/archives/extend/2014-February/000329.html @@ -0,0 +1,223 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 3 20:15:44 CET 2014 +

+
+ +
Sure. It won't be called if not a GET or HEAD request so that's probably 
+the best value you can return in your case.
+
+On 02/03/2014 08:08 PM, Łukasz Biedrycki wrote:
+> Ok,
+> it is more clear for me.
+>
+> Last question I have is about content_types_provided function.
+>
+> Is it safe to define it like this?
+>
+> content_types_provided(R, S) ->
+> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],
+>     {ContentTypes, Req, State}.
+>
+> Callback in content_types_provided is useless for POST requests, as it
+> won’t be called.
+> Is it safe to use *undefined *atom, to have a source code clearer?
+>
+>
+>
+>
+> On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     If Accept is sent and is different than text/html, yes.
+>
+>     This is how HTTP is defined. If the client says it speaks only
+>     content-type X but you can only reply with content-type Y, you error
+>     out early and stop processing the request. On the other hand if the
+>     client doesn't say what content-type it speaks then the server can
+>     choose whichever one it wants.
+>
+>
+>     On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
+>
+>         My application sends both headers: “Content-type” and “Accept”
+>         header
+>         using POST method.
+>
+>         For POST rest handler do I have to specify both:
+>         content_types_accepted
+>         and content_types_provided to manage this kind of request?
+>
+>
+>         On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>
+>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>
+>              The content-type provided is relevant for any response, not
+>         just
+>              responses to GET requests. It defaults to text/html. If
+>         your client
+>              doesn't send that content-type, you have to define the
+>         callback.
+>
+>              I notice that the documentation is incorrect about the relevant
+>              methods for this callback, I will open a ticket to fix it soon.
+>
+>
+>              On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+>
+>                  Hi,
+>                  I have a rest handler that accepts POST and PUT
+>         requests with
+>                  “application/json” content type.
+>
+>                  I have content_types_accepted function defined as follows:
+>
+>                  content_types_accepted(Req, State) ->
+>
+>
+>                  {[{‘application/json', from_json}], Req, State}.
+>
+>
+>
+>                  The problem I have is within a request that has two
+>         headers:
+>
+>                  *Content-type*: application/json
+>                  *Accept*: application/json
+>
+>                  With this combination I receive *406*.
+>
+>
+>                  You can repeat it with test:
+>
+>                  http_SUITE.erl:
+>                  1072 rest_postonly(Config) ->
+>                  1073     Client = ?config(client, Config),
+>                  1074     Headers = [
+>                  1075         {<<"content-type">>, <<"text/plain">>},
+>                  1076         {<<"accept">>, <<"text/plain">>}
+>                  1077     ],
+>                  1078     {ok, Client2} =
+>         cowboy_client:request(<<"POST"____>>,
+>
+>                  1079         build_url("/postonly", Config), Headers,
+>         "12345",
+>                  Client),
+>                  1080     {ok, 204, _, _} =
+>         cowboy_client:response(____Client2).
+>
+>
+>                  My solution to that was to add a content_types_provided
+>         function:
+>
+>
+>                  content_types_provided(Req, State) ->
+>
+>
+>                  ContentTypes = [{{<<"application">>, <<"json">>, '*'},
+>         to_json}],
+>
+>
+>                  {ContentTypes, Req, State}.
+>
+>
+>
+>                  But it is useless as *to_json* callback registered is
+>         not called
+>                  anyhow.
+>
+>                  Adding *content_types_provided* function is a correct
+>         solution
+>                  in this case?
+>
+>                  Or I am missing something here?
+>                  “Accept” header is not relevant only in case of GET
+>         requests?
+>
+>                  Thank for help,
+>                  Łukasz Biedrycki
+>
+>
+>                  ___________________________________________________
+>                  Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.__ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         https://lists.ninenines.eu/____listinfo/extend
+>         <https://lists.ninenines.eu/__listinfo/extend>
+>
+>                  <https://lists.ninenines.eu/__listinfo/extend
+>         <https://lists.ninenines.eu/listinfo/extend>>
+>
+>
+>              --
+>              Loïc Hoguin
+>         http://ninenines.eu
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000330.html b/_build/static/archives/extend/2014-February/000330.html new file mode 100644 index 00000000..dcc28287 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000330.html @@ -0,0 +1,244 @@ + + + + [99s-extend] Accept header in POST request + + + + + + + + + + +

[99s-extend] Accept header in POST request

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 3 20:16:29 CET 2014 +

+
+ +
Perfect, thanks a lot!
+Cheers,
+Ł.
+
+
+On Mon, Feb 3, 2014 at 8:15 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Sure. It won't be called if not a GET or HEAD request so that's probably
+> the best value you can return in your case.
+>
+>
+> On 02/03/2014 08:08 PM, Łukasz Biedrycki wrote:
+>
+>> Ok,
+>> it is more clear for me.
+>>
+>> Last question I have is about content_types_provided function.
+>>
+>> Is it safe to define it like this?
+>>
+>> content_types_provided(R, S) ->
+>> ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],
+>>
+>>     {ContentTypes, Req, State}.
+>>
+>> Callback in content_types_provided is useless for POST requests, as it
+>> won’t be called.
+>> Is it safe to use *undefined *atom, to have a source code clearer?
+>>
+>>
+>>
+>>
+>>
+>> On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     If Accept is sent and is different than text/html, yes.
+>>
+>>     This is how HTTP is defined. If the client says it speaks only
+>>     content-type X but you can only reply with content-type Y, you error
+>>     out early and stop processing the request. On the other hand if the
+>>     client doesn't say what content-type it speaks then the server can
+>>     choose whichever one it wants.
+>>
+>>
+>>     On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:
+>>
+>>         My application sends both headers: “Content-type” and “Accept”
+>>         header
+>>         using POST method.
+>>
+>>         For POST rest handler do I have to specify both:
+>>         content_types_accepted
+>>         and content_types_provided to manage this kind of request?
+>>
+>>
+>>         On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <essen at ninenines.eu
+>>         <mailto:essen at ninenines.eu>
+>>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>>
+>>              The content-type provided is relevant for any response, not
+>>         just
+>>              responses to GET requests. It defaults to text/html. If
+>>         your client
+>>              doesn't send that content-type, you have to define the
+>>         callback.
+>>
+>>              I notice that the documentation is incorrect about the
+>> relevant
+>>              methods for this callback, I will open a ticket to fix it
+>> soon.
+>>
+>>
+>>              On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:
+>>
+>>                  Hi,
+>>                  I have a rest handler that accepts POST and PUT
+>>         requests with
+>>                  “application/json” content type.
+>>
+>>                  I have content_types_accepted function defined as
+>> follows:
+>>
+>>                  content_types_accepted(Req, State) ->
+>>
+>>
+>>                  {[{‘application/json', from_json}], Req, State}.
+>>
+>>
+>>
+>>                  The problem I have is within a request that has two
+>>         headers:
+>>
+>>                  *Content-type*: application/json
+>>                  *Accept*: application/json
+>>
+>>                  With this combination I receive *406*.
+>>
+>>
+>>                  You can repeat it with test:
+>>
+>>                  http_SUITE.erl:
+>>                  1072 rest_postonly(Config) ->
+>>                  1073     Client = ?config(client, Config),
+>>                  1074     Headers = [
+>>                  1075         {<<"content-type">>, <<"text/plain">>},
+>>                  1076         {<<"accept">>, <<"text/plain">>}
+>>                  1077     ],
+>>                  1078     {ok, Client2} =
+>>         cowboy_client:request(<<"POST"____>>,
+>>
+>>
+>>                  1079         build_url("/postonly", Config), Headers,
+>>         "12345",
+>>                  Client),
+>>                  1080     {ok, 204, _, _} =
+>>         cowboy_client:response(____Client2).
+>>
+>>
+>>
+>>                  My solution to that was to add a content_types_provided
+>>         function:
+>>
+>>
+>>                  content_types_provided(Req, State) ->
+>>
+>>
+>>                  ContentTypes = [{{<<"application">>, <<"json">>, '*'},
+>>         to_json}],
+>>
+>>
+>>                  {ContentTypes, Req, State}.
+>>
+>>
+>>
+>>                  But it is useless as *to_json* callback registered is
+>>         not called
+>>                  anyhow.
+>>
+>>                  Adding *content_types_provided* function is a correct
+>>         solution
+>>                  in this case?
+>>
+>>                  Or I am missing something here?
+>>                  “Accept” header is not relevant only in case of GET
+>>         requests?
+>>
+>>                  Thank for help,
+>>                  Łukasz Biedrycki
+>>
+>>
+>>                  ___________________________________________________
+>>
+>>                  Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         <mailto:Extend at lists.__ninenines.eu
+>>         <mailto:Extend at lists.ninenines.eu>>
+>>         https://lists.ninenines.eu/____listinfo/extend
+>>         <https://lists.ninenines.eu/__listinfo/extend>
+>>
+>>
+>>                  <https://lists.ninenines.eu/__listinfo/extend
+>>         <https://lists.ninenines.eu/listinfo/extend>>
+>>
+>>
+>>              --
+>>              Loïc Hoguin
+>>         http://ninenines.eu
+>>
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140203/e84f6223/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000331.html b/_build/static/archives/extend/2014-February/000331.html new file mode 100644 index 00000000..d8ce154e --- /dev/null +++ b/_build/static/archives/extend/2014-February/000331.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Metrics per request and handler + + + + + + + + + + +

[99s-extend] Metrics per request and handler

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Fri Feb 7 17:56:26 CET 2014 +

+
+ +
Hi,
+in my application I would like to add some metrics per handler and per
+response http status code.
+
+One way is to add on response callback function, but there I do not have an
+information about handler and handler opts.
+
+Second way is to add a middleware, but then I do not have an information
+about response status code.
+
+Frankly, I like second way more.
+How do like an idea to add response status code to request record similar
+to: resp_headers or resp_body ?
+
+Cheers,
+Łukasz Biedrycki
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140207/904cc7bf/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000332.html b/_build/static/archives/extend/2014-February/000332.html new file mode 100644 index 00000000..544ef82c --- /dev/null +++ b/_build/static/archives/extend/2014-February/000332.html @@ -0,0 +1,94 @@ + + + + [99s-extend] Metrics per request and handler + + + + + + + + + + +

[99s-extend] Metrics per request and handler

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 10 10:41:13 CET 2014 +

+
+ +
Hi again,
+another idea is to make environment (Env), which is passed between
+middlewares, a part of Request record, so I could have an access to it in
+onresponse callback.
+
+Any of that makes sense?
+
+Cheers,
+Łukasz Biedrycki
+
+
+On Fri, Feb 7, 2014 at 5:56 PM, Łukasz Biedrycki <lukasz.biedrycki at gmail.com
+> wrote:
+
+> Hi,
+> in my application I would like to add some metrics per handler and per
+> response http status code.
+>
+> One way is to add on response callback function, but there I do not have
+> an information about handler and handler opts.
+>
+> Second way is to add a middleware, but then I do not have an information
+> about response status code.
+>
+> Frankly, I like second way more.
+> How do like an idea to add response status code to request record similar
+> to: resp_headers or resp_body ?
+>
+> Cheers,
+> Łukasz Biedrycki
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/b46e2bab/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000333.html b/_build/static/archives/extend/2014-February/000333.html new file mode 100644 index 00000000..3d277eba --- /dev/null +++ b/_build/static/archives/extend/2014-February/000333.html @@ -0,0 +1,108 @@ + + + + [99s-extend] Metrics per request and handler + + + + + + + + + + +

[99s-extend] Metrics per request and handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 10 10:49:24 CET 2014 +

+
+ +
You have the meta values in Req which are passed everywhere. You can 
+easily set and retrieve them.
+
+On 02/10/2014 10:41 AM, Łukasz Biedrycki wrote:
+> Hi again,
+> another idea is to make environment (Env), which is passed between
+> middlewares, a part of Request record, so I could have an access to it in
+> onresponse callback.
+>
+> Any of that makes sense?
+>
+> Cheers,
+> Łukasz Biedrycki
+>
+>
+> On Fri, Feb 7, 2014 at 5:56 PM, Łukasz Biedrycki <lukasz.biedrycki at gmail.com
+>> wrote:
+>
+>> Hi,
+>> in my application I would like to add some metrics per handler and per
+>> response http status code.
+>>
+>> One way is to add on response callback function, but there I do not have
+>> an information about handler and handler opts.
+>>
+>> Second way is to add a middleware, but then I do not have an information
+>> about response status code.
+>>
+>> Frankly, I like second way more.
+>> How do like an idea to add response status code to request record similar
+>> to: resp_headers or resp_body ?
+>>
+>> Cheers,
+>> Łukasz Biedrycki
+>>
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000334.html b/_build/static/archives/extend/2014-February/000334.html new file mode 100644 index 00000000..8f3b0da7 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000334.html @@ -0,0 +1,127 @@ + + + + [99s-extend] Metrics per request and handler + + + + + + + + + + +

[99s-extend] Metrics per request and handler

+ Łukasz Biedrycki + lukasz.biedrycki at gmail.com +
+ Mon Feb 10 10:51:50 CET 2014 +

+
+ +
Hey,
+I didn’t know about that.
+That is exactly what I need!
+Thank you!
+
+Cheers,
+Łukasz Biedrycki
+
+
+On Mon, Feb 10, 2014 at 10:49 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> You have the meta values in Req which are passed everywhere. You can
+> easily set and retrieve them.
+>
+>
+> On 02/10/2014 10:41 AM, Łukasz Biedrycki wrote:
+>
+>> Hi again,
+>> another idea is to make environment (Env), which is passed between
+>> middlewares, a part of Request record, so I could have an access to it in
+>> onresponse callback.
+>>
+>> Any of that makes sense?
+>>
+>> Cheers,
+>> Łukasz Biedrycki
+>>
+>>
+>> On Fri, Feb 7, 2014 at 5:56 PM, Łukasz Biedrycki <
+>> lukasz.biedrycki at gmail.com
+>>
+>>> wrote:
+>>>
+>>
+>>  Hi,
+>>> in my application I would like to add some metrics per handler and per
+>>> response http status code.
+>>>
+>>> One way is to add on response callback function, but there I do not have
+>>> an information about handler and handler opts.
+>>>
+>>> Second way is to add a middleware, but then I do not have an information
+>>> about response status code.
+>>>
+>>> Frankly, I like second way more.
+>>> How do like an idea to add response status code to request record similar
+>>> to: resp_headers or resp_body ?
+>>>
+>>> Cheers,
+>>> Łukasz Biedrycki
+>>>
+>>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/bf26d573/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000335.html b/_build/static/archives/extend/2014-February/000335.html new file mode 100644 index 00000000..7a2434df --- /dev/null +++ b/_build/static/archives/extend/2014-February/000335.html @@ -0,0 +1,74 @@ + + + + [99s-extend] do not treat warnings as errors on make? + + + + + + + + + + +

[99s-extend] do not treat warnings as errors on make?

+ Anton Koval' + psihonavt at gmail.com +
+ Mon Feb 10 19:44:54 CET 2014 +

+
+ +
Hello,
+
+as I understand, by default `make all` performs compile with option
+warnings_as_errors. How can I disable this option?
+There are options described at
+https://github.com/extend/erlang.mk#optionsand I believe that
+ERLC_OPTS
+should be filled with `-warnings_as_errors`. But it is unclear for me where
+have I to add(put) that option?
+
+Thanks.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/a2b35e2f/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000336.html b/_build/static/archives/extend/2014-February/000336.html new file mode 100644 index 00000000..b3ce26a4 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000336.html @@ -0,0 +1,87 @@ + + + + [99s-extend] do not treat warnings as errors on make? + + + + + + + + + + +

[99s-extend] do not treat warnings as errors on make?

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Feb 10 19:48:01 CET 2014 +

+
+ +
You can just define ERLC_OPTS before you include erlang.mk and it'll use 
+that instead. I'm not sure why you want to disable that though, warnings 
+usually alert you of bugs in your code.
+
+On 02/10/2014 07:44 PM, Anton Koval' wrote:
+> Hello,
+>
+> as I understand, by default `make all` performs compile with
+> option**warnings_as_errors.**How can I disable this option?
+> There are options described at
+> https://github.com/extend/erlang.mk#options and I believe that
+> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is
+> unclear for me where have I to add(put) that option?
+>
+> Thanks.
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000337.html b/_build/static/archives/extend/2014-February/000337.html new file mode 100644 index 00000000..bb16e835 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000337.html @@ -0,0 +1,103 @@ + + + + [99s-extend] do not treat warnings as errors on make? + + + + + + + + + + +

[99s-extend] do not treat warnings as errors on make?

+ Anton Koval' + psihonavt at gmail.com +
+ Mon Feb 10 20:22:49 CET 2014 +

+
+ +
Thanks for explanation.
+My situation: I'm developing some stuff in module. That module in some kind
+of "draft' state (e.g. some functions are unused), but regardless that I
+want to compile project in order to test some specific parts of that
+module.
+
+
+On Mon, Feb 10, 2014 at 8:48 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> You can just define ERLC_OPTS before you include erlang.mk and it'll use
+> that instead. I'm not sure why you want to disable that though, warnings
+> usually alert you of bugs in your code.
+>
+>
+> On 02/10/2014 07:44 PM, Anton Koval' wrote:
+>
+>> Hello,
+>>
+>> as I understand, by default `make all` performs compile with
+>> option**warnings_as_errors.**How can I disable this option?
+>>
+>> There are options described at
+>> https://github.com/extend/erlang.mk#options and I believe that
+>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is
+>>
+>> unclear for me where have I to add(put) that option?
+>>
+>> Thanks.
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/2ae635a6/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000338.html b/_build/static/archives/extend/2014-February/000338.html new file mode 100644 index 00000000..a6d41866 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000338.html @@ -0,0 +1,109 @@ + + + + [99s-extend] do not treat warnings as errors on make? + + + + + + + + + + +

[99s-extend] do not treat warnings as errors on make?

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Mon Feb 10 20:46:54 CET 2014 +

+
+ +
I promise you, improving the code now to get rid of the warnings is worth it.
+
+Ivan
+
+--
+festina lente
+
+
+> On 10 Feb 2014, at 19:22, "Anton Koval'" <psihonavt at gmail.com> wrote:
+> 
+> Thanks for explanation. 
+> My situation: I'm developing some stuff in module. That module in some kind of "draft' state (e.g. some functions are unused), but regardless that I want to compile project in order to test some specific parts of that module. 
+> 
+> 
+>> On Mon, Feb 10, 2014 at 8:48 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> You can just define ERLC_OPTS before you include erlang.mk and it'll use that instead. I'm not sure why you want to disable that though, warnings usually alert you of bugs in your code.
+>> 
+>> 
+>>> On 02/10/2014 07:44 PM, Anton Koval' wrote:
+>>> Hello,
+>>> 
+>>> as I understand, by default `make all` performs compile with
+>>> option**warnings_as_errors.**How can I disable this option?
+>>> 
+>>> There are options described at
+>>> https://github.com/extend/erlang.mk#options and I believe that
+>>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is
+>>> 
+>>> unclear for me where have I to add(put) that option?
+>>> 
+>>> Thanks.
+>>> 
+>>> 
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>> 
+>> -- 
+>> Loïc Hoguin
+>> http://ninenines.eu
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/1781c9d2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/000339.html b/_build/static/archives/extend/2014-February/000339.html new file mode 100644 index 00000000..35469a91 --- /dev/null +++ b/_build/static/archives/extend/2014-February/000339.html @@ -0,0 +1,125 @@ + + + + [99s-extend] do not treat warnings as errors on make? + + + + + + + + + + +

[99s-extend] do not treat warnings as errors on make?

+ Anton Koval' + psihonavt at gmail.com +
+ Mon Feb 10 20:55:24 CET 2014 +

+
+ +
Got it! :)
+fixed all warnings and removed  ERLC_OPTS from Makefile.
+
+
+On Mon, Feb 10, 2014 at 9:46 PM, Ivan Uemlianin <ivan at llaisdy.com> wrote:
+
+> I promise you, improving the code now to get rid of the warnings is worth
+> it.
+>
+> Ivan
+>
+> --
+> festina lente
+>
+>
+> On 10 Feb 2014, at 19:22, "Anton Koval'" <psihonavt at gmail.com> wrote:
+>
+> Thanks for explanation.
+> My situation: I'm developing some stuff in module. That module in some
+> kind of "draft' state (e.g. some functions are unused), but regardless that
+> I want to compile project in order to test some specific parts of that
+> module.
+>
+>
+> On Mon, Feb 10, 2014 at 8:48 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> You can just define ERLC_OPTS before you include erlang.mk and it'll use
+>> that instead. I'm not sure why you want to disable that though, warnings
+>> usually alert you of bugs in your code.
+>>
+>>
+>> On 02/10/2014 07:44 PM, Anton Koval' wrote:
+>>
+>>> Hello,
+>>>
+>>> as I understand, by default `make all` performs compile with
+>>> option**warnings_as_errors.**How can I disable this option?
+>>>
+>>> There are options described at
+>>> https://github.com/extend/erlang.mk#options and I believe that
+>>> |ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is
+>>>
+>>> unclear for me where have I to add(put) that option?
+>>>
+>>> Thanks.
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140210/fa72e2ba/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-February/author.html b/_build/static/archives/extend/2014-February/author.html new file mode 100644 index 00000000..374894cd --- /dev/null +++ b/_build/static/archives/extend/2014-February/author.html @@ -0,0 +1,127 @@ + + + + The Extend February 2014 Archive by author + + + + + +

February 2014 Archives by author

+ +

Starting: Mon Feb 3 19:13:04 CET 2014
+ Ending: Mon Feb 10 20:55:24 CET 2014
+ Messages: 16

+

+

+ Last message date: + Mon Feb 10 20:55:24 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-February/date.html b/_build/static/archives/extend/2014-February/date.html new file mode 100644 index 00000000..156b37ba --- /dev/null +++ b/_build/static/archives/extend/2014-February/date.html @@ -0,0 +1,127 @@ + + + + The Extend February 2014 Archive by date + + + + + +

February 2014 Archives by date

+ +

Starting: Mon Feb 3 19:13:04 CET 2014
+ Ending: Mon Feb 10 20:55:24 CET 2014
+ Messages: 16

+

+

+ Last message date: + Mon Feb 10 20:55:24 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-February/index.html b/_build/static/archives/extend/2014-February/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-February/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-February/subject.html b/_build/static/archives/extend/2014-February/subject.html new file mode 100644 index 00000000..3247635a --- /dev/null +++ b/_build/static/archives/extend/2014-February/subject.html @@ -0,0 +1,127 @@ + + + + The Extend February 2014 Archive by subject + + + + + +

February 2014 Archives by subject

+ +

Starting: Mon Feb 3 19:13:04 CET 2014
+ Ending: Mon Feb 10 20:55:24 CET 2014
+ Messages: 16

+

+

+ Last message date: + Mon Feb 10 20:55:24 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-February/thread.html b/_build/static/archives/extend/2014-February/thread.html new file mode 100644 index 00000000..493c7783 --- /dev/null +++ b/_build/static/archives/extend/2014-February/thread.html @@ -0,0 +1,161 @@ + + + + The Extend February 2014 Archive by thread + + + + + +

February 2014 Archives by thread

+ +

Starting: Mon Feb 3 19:13:04 CET 2014
+ Ending: Mon Feb 10 20:55:24 CET 2014
+ Messages: 16

+

+

+ Last message date: + Mon Feb 10 20:55:24 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-January.txt b/_build/static/archives/extend/2014-January.txt new file mode 100644 index 00000000..1c01655c --- /dev/null +++ b/_build/static/archives/extend/2014-January.txt @@ -0,0 +1,99 @@ +From me at xiao-jia.com Wed Jan 15 06:42:46 2014 +From: me at xiao-jia.com (Xiao Jia) +Date: Wed, 15 Jan 2014 13:42:46 +0800 +Subject: [99s-extend] Parsing binary example in ranch guide +Message-ID: + +Hi, + +I am learning how to use ranch and reading this page: + + http://ninenines.eu/docs/en/ranch/HEAD/guide/parsers + + +<< Size:32, _/bits >> = Buffer, +case Buffer of + << Frame:Size/binary, Rest/bits >> -> + handle_frame(Frame, Buffer); + _ -> + get_more_data(Buffer) +end. + + +Shouldn't it be + + handle_frame(Frame, Rest); + +instead? + +-- +Regards, +Xiao Jia + + +From essen at ninenines.eu Wed Jan 15 08:51:32 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 15 Jan 2014 08:51:32 +0100 +Subject: [99s-extend] Parsing binary example in ranch guide +In-Reply-To: +References: +Message-ID: <52D63E04.5090300@ninenines.eu> + +Yes. + +Feel free to open a PR, thanks! + +On 01/15/2014 06:42 AM, Xiao Jia wrote: +> Hi, +> +> I am learning how to use ranch and reading this page: +> +> http://ninenines.eu/docs/en/ranch/HEAD/guide/parsers +> +> +> << Size:32, _/bits >> = Buffer, +> case Buffer of +> << Frame:Size/binary, Rest/bits >> -> +> handle_frame(Frame, Buffer); +> _ -> +> get_more_data(Buffer) +> end. +> +> +> Shouldn't it be +> +> handle_frame(Frame, Rest); +> +> instead? +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From me at xiao-jia.com Fri Jan 17 03:15:24 2014 +From: me at xiao-jia.com (Xiao Jia) +Date: Fri, 17 Jan 2014 10:15:24 +0800 +Subject: [99s-extend] Restart listeners if ranch_sup fails +Message-ID: + +>From http://ninenines.eu/docs/en/ranch/HEAD/guide/embedded/ + + "It is recommended that your architecture makes sure that all +listeners are restarted if ranch_supfails." + +Does it imply that we should use rest_for_one instead of one_for_one +in the example code below? + + {ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}} + +=> + + {ok, {{rest_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}} + +-- +Regards, +Xiao Jia + + diff --git a/_build/static/archives/extend/2014-January/000321.html b/_build/static/archives/extend/2014-January/000321.html new file mode 100644 index 00000000..308f7a8d --- /dev/null +++ b/_build/static/archives/extend/2014-January/000321.html @@ -0,0 +1,84 @@ + + + + [99s-extend] Parsing binary example in ranch guide + + + + + + + + + + +

[99s-extend] Parsing binary example in ranch guide

+ Xiao Jia + me at xiao-jia.com +
+ Wed Jan 15 06:42:46 CET 2014 +

+
+ +
Hi,
+
+I am learning how to use ranch and reading this page:
+
+    http://ninenines.eu/docs/en/ranch/HEAD/guide/parsers
+
+
+<< Size:32, _/bits >> = Buffer,
+case Buffer of
+    << Frame:Size/binary, Rest/bits >> ->
+        handle_frame(Frame, Buffer);
+    _ ->
+        get_more_data(Buffer)
+end.
+
+
+Shouldn't it be
+
+    handle_frame(Frame, Rest);
+
+instead?
+
+-- 
+Regards,
+Xiao Jia
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-January/000322.html b/_build/static/archives/extend/2014-January/000322.html new file mode 100644 index 00000000..76eb33c2 --- /dev/null +++ b/_build/static/archives/extend/2014-January/000322.html @@ -0,0 +1,92 @@ + + + + [99s-extend] Parsing binary example in ranch guide + + + + + + + + + + +

[99s-extend] Parsing binary example in ranch guide

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jan 15 08:51:32 CET 2014 +

+
+ +
Yes.
+
+Feel free to open a PR, thanks!
+
+On 01/15/2014 06:42 AM, Xiao Jia wrote:
+> Hi,
+>
+> I am learning how to use ranch and reading this page:
+>
+>      http://ninenines.eu/docs/en/ranch/HEAD/guide/parsers
+>
+>
+> << Size:32, _/bits >> = Buffer,
+> case Buffer of
+>      << Frame:Size/binary, Rest/bits >> ->
+>          handle_frame(Frame, Buffer);
+>      _ ->
+>          get_more_data(Buffer)
+> end.
+>
+>
+> Shouldn't it be
+>
+>      handle_frame(Frame, Rest);
+>
+> instead?
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-January/000323.html b/_build/static/archives/extend/2014-January/000323.html new file mode 100644 index 00000000..5c3a0008 --- /dev/null +++ b/_build/static/archives/extend/2014-January/000323.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Restart listeners if ranch_sup fails + + + + + + + + + + +

[99s-extend] Restart listeners if ranch_sup fails

+ Xiao Jia + me at xiao-jia.com +
+ Fri Jan 17 03:15:24 CET 2014 +

+
+ +
>From http://ninenines.eu/docs/en/ranch/HEAD/guide/embedded/
+
+    "It is recommended that your architecture makes sure that all
+listeners are restarted if ranch_supfails."
+
+Does it imply that we should use rest_for_one instead of one_for_one
+in the example code below?
+
+    {ok, {{one_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}
+
+=>
+
+    {ok, {{rest_for_one, 10, 10}, [RanchSupSpec, ListenerSpec]}}
+
+-- 
+Regards,
+Xiao Jia
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-January/author.html b/_build/static/archives/extend/2014-January/author.html new file mode 100644 index 00000000..b3a05d55 --- /dev/null +++ b/_build/static/archives/extend/2014-January/author.html @@ -0,0 +1,62 @@ + + + + The Extend January 2014 Archive by author + + + + + +

January 2014 Archives by author

+ +

Starting: Wed Jan 15 06:42:46 CET 2014
+ Ending: Fri Jan 17 03:15:24 CET 2014
+ Messages: 3

+

+

+ Last message date: + Fri Jan 17 03:15:24 CET 2014
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-January/date.html b/_build/static/archives/extend/2014-January/date.html new file mode 100644 index 00000000..b2eec822 --- /dev/null +++ b/_build/static/archives/extend/2014-January/date.html @@ -0,0 +1,62 @@ + + + + The Extend January 2014 Archive by date + + + + + +

January 2014 Archives by date

+ +

Starting: Wed Jan 15 06:42:46 CET 2014
+ Ending: Fri Jan 17 03:15:24 CET 2014
+ Messages: 3

+

+

+ Last message date: + Fri Jan 17 03:15:24 CET 2014
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-January/index.html b/_build/static/archives/extend/2014-January/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-January/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-January/subject.html b/_build/static/archives/extend/2014-January/subject.html new file mode 100644 index 00000000..3d0610ac --- /dev/null +++ b/_build/static/archives/extend/2014-January/subject.html @@ -0,0 +1,62 @@ + + + + The Extend January 2014 Archive by subject + + + + + +

January 2014 Archives by subject

+ +

Starting: Wed Jan 15 06:42:46 CET 2014
+ Ending: Fri Jan 17 03:15:24 CET 2014
+ Messages: 3

+

+

+ Last message date: + Fri Jan 17 03:15:24 CET 2014
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-January/thread.html b/_build/static/archives/extend/2014-January/thread.html new file mode 100644 index 00000000..bfa94e9b --- /dev/null +++ b/_build/static/archives/extend/2014-January/thread.html @@ -0,0 +1,67 @@ + + + + The Extend January 2014 Archive by thread + + + + + +

January 2014 Archives by thread

+ +

Starting: Wed Jan 15 06:42:46 CET 2014
+ Ending: Fri Jan 17 03:15:24 CET 2014
+ Messages: 3

+

+

+ Last message date: + Fri Jan 17 03:15:24 CET 2014
+ Archived on: Wed May 28 18:41:46 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-July.txt b/_build/static/archives/extend/2014-July.txt new file mode 100644 index 00000000..c6ff98a3 --- /dev/null +++ b/_build/static/archives/extend/2014-July.txt @@ -0,0 +1,545 @@ +From adelzhang at qq.com Thu Jul 3 09:40:12 2014 +From: adelzhang at qq.com (Adel Zhang) +Date: Thu, 03 Jul 2014 15:40:12 +0800 +Subject: [99s-extend] tring to understand ranch_conns_sup +Message-ID: + +Ranch uses a tcp acceptor pool to accept connections concurrently. But the +acceptor process +needs to wait for the *only one* ranch_conns_sup spawning the protocol +process. + +Is ranch_conns_sup maybe a bottleneck? + +Thanks. + +From essen at ninenines.eu Thu Jul 3 09:55:13 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 03 Jul 2014 09:55:13 +0200 +Subject: [99s-extend] tring to understand ranch_conns_sup +In-Reply-To: +References: +Message-ID: <53B50C61.9050601@ninenines.eu> + +Have you observed ranch_conns_sup be a bottleneck? In practice it +shouldn't be. + +On 07/03/2014 09:40 AM, Adel Zhang wrote: +> Ranch uses a tcp acceptor pool to accept connections concurrently. But +> the acceptor process +> needs to wait for the *only one* ranch_conns_sup spawning the protocol +> process. +> +> Is ranch_conns_sup maybe a bottleneck? +> +> Thanks. +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From samuelrivas at gmail.com Tue Jul 8 09:12:43 2014 +From: samuelrivas at gmail.com (Samuel) +Date: Tue, 8 Jul 2014 09:12:43 +0200 +Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT +Message-ID: + +Hi, + +According to the documentation I should be able to return a new +location when handling a PUT request when using cowboy_rest protocol: + + The AcceptResource value is the name of the callback that will be +called if the + content-type matches. It is defined as follow. + + Value type: true | {true, URL} | false + +That works for "true" and "false" but not for "{true, URL}", in that +case the Ranch listener crashes badly[1]. + +Looking into cowboy_rest.erl I see that the {true, URL} form is +restricted to POST requests: +https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784 + +Is that intentional or should I submit a patch to add at least PUT and +PATCH to that condition (or remove all of them if that is not guarding +against something horrible)? + +Regards + +[1] Ranch crash log: +Ranch listener http_acceptor had connection process started with +cowboy_protocol:start_link/4 at <0.2660.0> exit with reason: +{{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0 +(x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 +libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} +-- +Samuel + +From essen at ninenines.eu Tue Jul 8 11:57:12 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 08 Jul 2014 11:57:12 +0200 +Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT +In-Reply-To: +References: +Message-ID: <53BBC078.80006@ninenines.eu> + +It's not enabled for PATCH or PUT because it makes little sense for +them. PATCH and PUT are typically used directly on the URI of the +resource, even when creating it. While you can return a "better URI" for +the created resource for them, this should be seen as a special case +rather than the norm. You can still do it by setting the location header +manually and Cowboy will react accordingly. + +On 07/08/2014 09:12 AM, Samuel wrote: +> Hi, +> +> According to the documentation I should be able to return a new +> location when handling a PUT request when using cowboy_rest protocol: +> +> The AcceptResource value is the name of the callback that will be +> called if the +> content-type matches. It is defined as follow. +> +> Value type: true | {true, URL} | false +> +> That works for "true" and "false" but not for "{true, URL}", in that +> case the Ranch listener crashes badly[1]. +> +> Looking into cowboy_rest.erl I see that the {true, URL} form is +> restricted to POST requests: +> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784 +> +> Is that intentional or should I submit a patch to add at least PUT and +> PATCH to that condition (or remove all of them if that is not guarding +> against something horrible)? +> +> Regards +> +> [1] Ranch crash log: +> Ranch listener http_acceptor had connection process started with +> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason: +> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0 +> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 +> libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samuelrivas at gmail.com Tue Jul 8 13:32:45 2014 +From: samuelrivas at gmail.com (Samuel) +Date: Tue, 8 Jul 2014 13:32:45 +0200 +Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT +In-Reply-To: <53BBC078.80006@ninenines.eu> +References: + <53BBC078.80006@ninenines.eu> +Message-ID: + +Ok, thanks. That should probably be mentioned in the documentation of +content_types_accepted, as it says {true, URI} is a valid output for +the provided function. + +Just out of curiosity from a non-so-expert in REST. The API spec +(which I am not the author of) says the PUT call should create a +resource with a unique id and return the URI of the created resource +in the Location header. That is something like PUT /some/resource +should return /some/resource/1234 in the Location. some/resource is +fixed but 1234 would be generated for each instance of /some/resource. +Is that considered nonsensical? + +On 8 July 2014 11:57, Lo?c Hoguin wrote: +> It's not enabled for PATCH or PUT because it makes little sense for them. +> PATCH and PUT are typically used directly on the URI of the resource, even +> when creating it. While you can return a "better URI" for the created +> resource for them, this should be seen as a special case rather than the +> norm. You can still do it by setting the location header manually and Cowboy +> will react accordingly. +> +> +> On 07/08/2014 09:12 AM, Samuel wrote: +>> +>> Hi, +>> +>> According to the documentation I should be able to return a new +>> location when handling a PUT request when using cowboy_rest protocol: +>> +>> The AcceptResource value is the name of the callback that will be +>> called if the +>> content-type matches. It is defined as follow. +>> +>> Value type: true | {true, URL} | false +>> +>> That works for "true" and "false" but not for "{true, URL}", in that +>> case the Ranch listener crashes badly[1]. +>> +>> Looking into cowboy_rest.erl I see that the {true, URL} form is +>> restricted to POST requests: +>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784 +>> +>> Is that intentional or should I submit a patch to add at least PUT and +>> PATCH to that condition (or remove all of them if that is not guarding +>> against something horrible)? +>> +>> Regards +>> +>> [1] Ranch crash log: +>> Ranch listener http_acceptor had connection process started with +>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason: +>> +>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0 +>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 +>> libidn/1.23 +>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + + +-- +Samuel + +From essen at ninenines.eu Tue Jul 8 13:42:00 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 08 Jul 2014 13:42:00 +0200 +Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT +In-Reply-To: +References: + <53BBC078.80006@ninenines.eu> + +Message-ID: <53BBD908.6020909@ninenines.eu> + +That's what POST should do. + +Compare: + +PUT /some/resource/1234 -> no redirect needed +POST /some/resource -> creates /some/resource/1234, redirects + +If /some/resource is a collection then PUT on that collection is +supposed to replace it entirely. + +Again it's possible for PUT to create a resource elsewhere, but +typically the redirect would be from something like +http://api.yourservice.com/resource/1234 to +http://cloudthingy.server137.yourservice.com/whatever/resource/1234 and +not to do what POST is intended for. + +On 07/08/2014 01:32 PM, Samuel wrote: +> Ok, thanks. That should probably be mentioned in the documentation of +> content_types_accepted, as it says {true, URI} is a valid output for +> the provided function. +> +> Just out of curiosity from a non-so-expert in REST. The API spec +> (which I am not the author of) says the PUT call should create a +> resource with a unique id and return the URI of the created resource +> in the Location header. That is something like PUT /some/resource +> should return /some/resource/1234 in the Location. some/resource is +> fixed but 1234 would be generated for each instance of /some/resource. +> Is that considered nonsensical? +> +> On 8 July 2014 11:57, Lo?c Hoguin wrote: +>> It's not enabled for PATCH or PUT because it makes little sense for them. +>> PATCH and PUT are typically used directly on the URI of the resource, even +>> when creating it. While you can return a "better URI" for the created +>> resource for them, this should be seen as a special case rather than the +>> norm. You can still do it by setting the location header manually and Cowboy +>> will react accordingly. +>> +>> +>> On 07/08/2014 09:12 AM, Samuel wrote: +>>> +>>> Hi, +>>> +>>> According to the documentation I should be able to return a new +>>> location when handling a PUT request when using cowboy_rest protocol: +>>> +>>> The AcceptResource value is the name of the callback that will be +>>> called if the +>>> content-type matches. It is defined as follow. +>>> +>>> Value type: true | {true, URL} | false +>>> +>>> That works for "true" and "false" but not for "{true, URL}", in that +>>> case the Ranch listener crashes badly[1]. +>>> +>>> Looking into cowboy_rest.erl I see that the {true, URL} form is +>>> restricted to POST requests: +>>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784 +>>> +>>> Is that intentional or should I submit a patch to add at least PUT and +>>> PATCH to that condition (or remove all of them if that is not guarding +>>> against something horrible)? +>>> +>>> Regards +>>> +>>> [1] Ranch crash log: +>>> Ranch listener http_acceptor had connection process started with +>>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason: +>>> +>>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0 +>>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 +>>> libidn/1.23 +>>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]} +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samuelrivas at gmail.com Tue Jul 8 13:49:35 2014 +From: samuelrivas at gmail.com (Samuel) +Date: Tue, 8 Jul 2014 13:49:35 +0200 +Subject: [99s-extend] [cowboy REST] returning {true, URL} to PUT +In-Reply-To: <53BBD908.6020909@ninenines.eu> +References: + <53BBC078.80006@ninenines.eu> + + <53BBD908.6020909@ninenines.eu> +Message-ID: + +> Compare: +> +> PUT /some/resource/1234 -> no redirect needed +> POST /some/resource -> creates /some/resource/1234, redirects +> +> If /some/resource is a collection then PUT on that collection is supposed to +> replace it entirely. + +Great, thanks for the explanation. I'll try to discuss that with the +authors of the API + +-- +Samuel + +From paulo.ferraz.oliveira at gmail.com Tue Jul 8 15:17:32 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 8 Jul 2014 14:17:32 +0100 +Subject: [99s-extend] HTTP Basic Auth base64 decode fails +Message-ID: + +Hello, y'all. + +I'm using HTTP Basic Auth in my API. While calling +cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_ +Authorization header such as "Authorization: Basic Test1" I get an error +500 back and an error log message on the server. + +1. Is this the expected behavior? [if I understand correctly, my request is +going through authorization(UserPass, Type = <<"basic">>) and this has no +check for the string being correctly encoded] + +2. what would be the best way to guard against this "error"? + +Thanks. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Jul 8 15:21:28 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 08 Jul 2014 15:21:28 +0200 +Subject: [99s-extend] HTTP Basic Auth base64 decode fails +In-Reply-To: +References: +Message-ID: <53BBF058.3090103@ninenines.eu> + +Parsing of any header may crash. Some may also return an error tuple, +though that behavior slowly changes and it will always crash in 2.0. So +just wrap the call around a try/catch if you need to handle the error. + +Note that at this exact moment I'm working on returning 400 instead of +500 automatically when parsing headers end up crashing (and possibly +other situations later on). + +On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote: +> Hello, y'all. +> +> I'm using HTTP Basic Auth in my API. While calling +> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_ +> Authorization header such as "Authorization: Basic Test1" I get an error +> 500 back and an error log message on the server. +> +> 1. Is this the expected behavior? [if I understand correctly, my request +> is going through authorization(UserPass, Type = <<"basic">>) and this +> has no check for the string being correctly encoded] +> +> 2. what would be the best way to guard against this "error"? +> +> Thanks. +> +> - Paulo F. Oliveira +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Tue Jul 8 15:25:58 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 8 Jul 2014 14:25:58 +0100 +Subject: [99s-extend] HTTP Basic Auth base64 decode fails +In-Reply-To: <53BBF058.3090103@ninenines.eu> +References: + <53BBF058.3090103@ninenines.eu> +Message-ID: + +Great, thanks. + +I saw some changes "from 422 to 400" in recent versions (PUT and POST). +Thanks for the heads up. As long as they're document, no harm shall come of +these changes. + +In any case, if I see it happen very often live I'll "protect" it agains +the _bad_ header :-). + +Cheers. + +- Paulo F. Oliveira + + +On 8 July 2014 14:21, Lo?c Hoguin wrote: + +> Parsing of any header may crash. Some may also return an error tuple, +> though that behavior slowly changes and it will always crash in 2.0. So +> just wrap the call around a try/catch if you need to handle the error. +> +> Note that at this exact moment I'm working on returning 400 instead of 500 +> automatically when parsing headers end up crashing (and possibly other +> situations later on). +> +> +> On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote: +> +>> Hello, y'all. +>> +>> I'm using HTTP Basic Auth in my API. While calling +>> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_ +>> Authorization header such as "Authorization: Basic Test1" I get an error +>> 500 back and an error log message on the server. +>> +>> 1. Is this the expected behavior? [if I understand correctly, my request +>> is going through authorization(UserPass, Type = <<"basic">>) and this +>> has no check for the string being correctly encoded] +>> +>> 2. what would be the best way to guard against this "error"? +>> +>> Thanks. +>> +>> - Paulo F. Oliveira +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From chaehb at gmail.com Sat Jul 26 09:06:15 2014 +From: chaehb at gmail.com (chaehb) +Date: Sat, 26 Jul 2014 16:06:15 +0900 +Subject: [99s-extend] couldn't quit in Erlang 17.1 +Message-ID: <5E6EEC48-13CF-48A9-BD48-DC339D93B75D@gmail.com> + +Hi, everybody. + +After Erlang updated to 17.1, +when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages.. + +(after ok signal printed) + +?... +=ERROR REPORT==== 26-Jul-2014::15:23:33 === +Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +?. + +Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments. + +This is only appeared when I only use ssl(https). +But when use only http with same dispatch rules, cowboy normally quitted. + +What?s wrong? or Normal ? + +my environment : +OS : Mac OS X Mavricks +Erlang/OTP : 17.1 from Homebrew +release tool : relx +Cowboy and others : latest + +From essen at ninenines.eu Sun Jul 27 11:25:50 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sun, 27 Jul 2014 11:25:50 +0200 +Subject: [99s-extend] couldn't quit in Erlang 17.1 +In-Reply-To: <5E6EEC48-13CF-48A9-BD48-DC339D93B75D@gmail.com> +References: <5E6EEC48-13CF-48A9-BD48-DC339D93B75D@gmail.com> +Message-ID: <53D4C59E.2010909@ninenines.eu> + +Does it happen with ssl_hello_world? + +On 07/26/2014 09:06 AM, chaehb wrote: +> Hi, everybody. +> +> After Erlang updated to 17.1, +> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages.. +> +> (after ok signal printed) +> +> ?... +> =ERROR REPORT==== 26-Jul-2014::15:23:33 === +> Error in process <0.334.0> on node ?...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +> ?. +> +> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments. +> +> This is only appeared when I only use ssl(https). +> But when use only http with same dispatch rules, cowboy normally quitted. +> +> What?s wrong? or Normal ? +> +> my environment : +> OS : Mac OS X Mavricks +> Erlang/OTP : 17.1 from Homebrew +> release tool : relx +> Cowboy and others : latest +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + diff --git a/_build/static/archives/extend/2014-July/000405.html b/_build/static/archives/extend/2014-July/000405.html new file mode 100644 index 00000000..5d219b5e --- /dev/null +++ b/_build/static/archives/extend/2014-July/000405.html @@ -0,0 +1,67 @@ + + + + [99s-extend] tring to understand ranch_conns_sup + + + + + + + + + + +

[99s-extend] tring to understand ranch_conns_sup

+ Adel Zhang + adelzhang at qq.com +
+ Thu Jul 3 09:40:12 CEST 2014 +

+
+ +
Ranch uses a tcp acceptor pool to accept connections concurrently. But the  
+acceptor process
+needs to wait for the *only one* ranch_conns_sup spawning the protocol  
+process.
+
+Is ranch_conns_sup maybe a bottleneck?
+
+Thanks.
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000406.html b/_build/static/archives/extend/2014-July/000406.html new file mode 100644 index 00000000..dc7d3c25 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000406.html @@ -0,0 +1,81 @@ + + + + [99s-extend] tring to understand ranch_conns_sup + + + + + + + + + + +

[99s-extend] tring to understand ranch_conns_sup

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jul 3 09:55:13 CEST 2014 +

+
+ +
Have you observed ranch_conns_sup be a bottleneck? In practice it 
+shouldn't be.
+
+On 07/03/2014 09:40 AM, Adel Zhang wrote:
+> Ranch uses a tcp acceptor pool to accept connections concurrently. But
+> the acceptor process
+> needs to wait for the *only one* ranch_conns_sup spawning the protocol
+> process.
+>
+> Is ranch_conns_sup maybe a bottleneck?
+>
+> Thanks.
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000407.html b/_build/static/archives/extend/2014-July/000407.html new file mode 100644 index 00000000..87466ece --- /dev/null +++ b/_build/static/archives/extend/2014-July/000407.html @@ -0,0 +1,93 @@ + + + + [99s-extend] [cowboy REST] returning {true, URL} to PUT + + + + + + + + + + +

[99s-extend] [cowboy REST] returning {true, URL} to PUT

+ Samuel + samuelrivas at gmail.com +
+ Tue Jul 8 09:12:43 CEST 2014 +

+
+ +
Hi,
+
+According to the documentation I should be able to return a new
+location when handling a PUT request when using cowboy_rest protocol:
+
+    The AcceptResource value is the name of the callback that will be
+called if the
+    content-type matches. It is defined as follow.
+
+    Value type: true | {true, URL} | false
+
+That works for "true" and "false" but not for "{true, URL}", in that
+case the Ranch listener crashes badly[1].
+
+Looking into cowboy_rest.erl I see that the {true, URL} form is
+restricted to POST requests:
+https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+
+Is that intentional or should I submit a patch to add at least PUT and
+PATCH to that condition (or remove all of them if that is not guarding
+against something horrible)?
+
+Regards
+
+[1] Ranch crash log:
+Ranch listener http_acceptor had connection process started with
+cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+{{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+(x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+-- 
+Samuel
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000408.html b/_build/static/archives/extend/2014-July/000408.html new file mode 100644 index 00000000..2edee0bc --- /dev/null +++ b/_build/static/archives/extend/2014-July/000408.html @@ -0,0 +1,104 @@ + + + + [99s-extend] [cowboy REST] returning {true, URL} to PUT + + + + + + + + + + +

[99s-extend] [cowboy REST] returning {true, URL} to PUT

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jul 8 11:57:12 CEST 2014 +

+
+ +
It's not enabled for PATCH or PUT because it makes little sense for 
+them. PATCH and PUT are typically used directly on the URI of the 
+resource, even when creating it. While you can return a "better URI" for 
+the created resource for them, this should be seen as a special case 
+rather than the norm. You can still do it by setting the location header 
+manually and Cowboy will react accordingly.
+
+On 07/08/2014 09:12 AM, Samuel wrote:
+> Hi,
+>
+> According to the documentation I should be able to return a new
+> location when handling a PUT request when using cowboy_rest protocol:
+>
+>      The AcceptResource value is the name of the callback that will be
+> called if the
+>      content-type matches. It is defined as follow.
+>
+>      Value type: true | {true, URL} | false
+>
+> That works for "true" and "false" but not for "{true, URL}", in that
+> case the Ranch listener crashes badly[1].
+>
+> Looking into cowboy_rest.erl I see that the {true, URL} form is
+> restricted to POST requests:
+> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>
+> Is that intentional or should I submit a patch to add at least PUT and
+> PATCH to that condition (or remove all of them if that is not guarding
+> against something horrible)?
+>
+> Regards
+>
+> [1] Ranch crash log:
+> Ranch listener http_acceptor had connection process started with
+> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+> libidn/1.23 librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000409.html b/_build/static/archives/extend/2014-July/000409.html new file mode 100644 index 00000000..5969aed9 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000409.html @@ -0,0 +1,126 @@ + + + + [99s-extend] [cowboy REST] returning {true, URL} to PUT + + + + + + + + + + +

[99s-extend] [cowboy REST] returning {true, URL} to PUT

+ Samuel + samuelrivas at gmail.com +
+ Tue Jul 8 13:32:45 CEST 2014 +

+
+ +
Ok, thanks. That should probably be mentioned in the documentation of
+content_types_accepted, as it says {true, URI} is a valid output for
+the provided function.
+
+Just out of curiosity from a non-so-expert in REST. The API spec
+(which I am not the author of) says the PUT call should create a
+resource with a unique id and return the URI of the created resource
+in the Location header. That is something like PUT /some/resource
+should return /some/resource/1234 in the Location. some/resource is
+fixed but 1234 would be generated for each instance of /some/resource.
+Is that considered nonsensical?
+
+On 8 July 2014 11:57, Loïc Hoguin <essen at ninenines.eu> wrote:
+> It's not enabled for PATCH or PUT because it makes little sense for them.
+> PATCH and PUT are typically used directly on the URI of the resource, even
+> when creating it. While you can return a "better URI" for the created
+> resource for them, this should be seen as a special case rather than the
+> norm. You can still do it by setting the location header manually and Cowboy
+> will react accordingly.
+>
+>
+> On 07/08/2014 09:12 AM, Samuel wrote:
+>>
+>> Hi,
+>>
+>> According to the documentation I should be able to return a new
+>> location when handling a PUT request when using cowboy_rest protocol:
+>>
+>>      The AcceptResource value is the name of the callback that will be
+>> called if the
+>>      content-type matches. It is defined as follow.
+>>
+>>      Value type: true | {true, URL} | false
+>>
+>> That works for "true" and "false" but not for "{true, URL}", in that
+>> case the Ranch listener crashes badly[1].
+>>
+>> Looking into cowboy_rest.erl I see that the {true, URL} form is
+>> restricted to POST requests:
+>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>>
+>> Is that intentional or should I submit a patch to add at least PUT and
+>> PATCH to that condition (or remove all of them if that is not guarding
+>> against something horrible)?
+>>
+>> Regards
+>>
+>> [1] Ranch crash log:
+>> Ranch listener http_acceptor had connection process started with
+>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+>>
+>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+>> libidn/1.23
+>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>>
+>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+
+-- 
+Samuel
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000410.html b/_build/static/archives/extend/2014-July/000410.html new file mode 100644 index 00000000..0d3af068 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000410.html @@ -0,0 +1,145 @@ + + + + [99s-extend] [cowboy REST] returning {true, URL} to PUT + + + + + + + + + + +

[99s-extend] [cowboy REST] returning {true, URL} to PUT

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jul 8 13:42:00 CEST 2014 +

+
+ +
That's what POST should do.
+
+Compare:
+
+PUT /some/resource/1234 -> no redirect needed
+POST /some/resource -> creates /some/resource/1234, redirects
+
+If /some/resource is a collection then PUT on that collection is 
+supposed to replace it entirely.
+
+Again it's possible for PUT to create a resource elsewhere, but 
+typically the redirect would be from something like 
+http://api.yourservice.com/resource/1234 to 
+http://cloudthingy.server137.yourservice.com/whatever/resource/1234 and 
+not to do what POST is intended for.
+
+On 07/08/2014 01:32 PM, Samuel wrote:
+> Ok, thanks. That should probably be mentioned in the documentation of
+> content_types_accepted, as it says {true, URI} is a valid output for
+> the provided function.
+>
+> Just out of curiosity from a non-so-expert in REST. The API spec
+> (which I am not the author of) says the PUT call should create a
+> resource with a unique id and return the URI of the created resource
+> in the Location header. That is something like PUT /some/resource
+> should return /some/resource/1234 in the Location. some/resource is
+> fixed but 1234 would be generated for each instance of /some/resource.
+> Is that considered nonsensical?
+>
+> On 8 July 2014 11:57, Loïc Hoguin <essen at ninenines.eu> wrote:
+>> It's not enabled for PATCH or PUT because it makes little sense for them.
+>> PATCH and PUT are typically used directly on the URI of the resource, even
+>> when creating it. While you can return a "better URI" for the created
+>> resource for them, this should be seen as a special case rather than the
+>> norm. You can still do it by setting the location header manually and Cowboy
+>> will react accordingly.
+>>
+>>
+>> On 07/08/2014 09:12 AM, Samuel wrote:
+>>>
+>>> Hi,
+>>>
+>>> According to the documentation I should be able to return a new
+>>> location when handling a PUT request when using cowboy_rest protocol:
+>>>
+>>>       The AcceptResource value is the name of the callback that will be
+>>> called if the
+>>>       content-type matches. It is defined as follow.
+>>>
+>>>       Value type: true | {true, URL} | false
+>>>
+>>> That works for "true" and "false" but not for "{true, URL}", in that
+>>> case the Ranch listener crashes badly[1].
+>>>
+>>> Looking into cowboy_rest.erl I see that the {true, URL} form is
+>>> restricted to POST requests:
+>>> https://github.com/extend/cowboy/blob/master/src/cowboy_rest.erl#L784
+>>>
+>>> Is that intentional or should I submit a patch to add at least PUT and
+>>> PATCH to that condition (or remove all of them if that is not guarding
+>>> against something horrible)?
+>>>
+>>> Regards
+>>>
+>>> [1] Ranch crash log:
+>>> Ranch listener http_acceptor had connection process started with
+>>> cowboy_protocol:start_link/4 at <0.2660.0> exit with reason:
+>>>
+>>> {{case_clause,{{true,"/url"},{http_req,#Port<0.15864>,ranch_tcp,keepalive,<0.2660.0>,<<"PUT">>,'HTTP/1.1',{{127,0,0,1},56983},<<"localhost">>,undefined,8080,<<"/order">>,undefined,<<>>,undefined,[],[{<<"user-agent">>,<<"curl/7.22.0
+>>> (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4
+>>> libidn/1.23
+>>> librtmp/2.3">>},{<<"host">>,<<"localhost:8080">>},{<<"accept">>,<<"*/*">>},{<<"content-type">>,<<"application/json">>}],[{<<"content-type">>,{<<"application">>,<<"json">>,[]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"*">>,<<"*">>,[]},1000,[]}]}],undefined,[{charset,undefined},{media_type,{<<"text">>,<<"html">>,[]}}],waiting,undefined,<<>>,false,waiting,[{<<"content-type">>,[<<"text">>,<<"/">>,<<"html">>,<<>>]}],<<>>,undefined},{state}}},[{cowboy_rest,process_content_type,3,[{file,"src/cowboy_rest.erl"},{line,780}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000411.html b/_build/static/archives/extend/2014-July/000411.html new file mode 100644 index 00000000..3e699a09 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000411.html @@ -0,0 +1,74 @@ + + + + [99s-extend] [cowboy REST] returning {true, URL} to PUT + + + + + + + + + + +

[99s-extend] [cowboy REST] returning {true, URL} to PUT

+ Samuel + samuelrivas at gmail.com +
+ Tue Jul 8 13:49:35 CEST 2014 +

+
+ +
> Compare:
+>
+> PUT /some/resource/1234 -> no redirect needed
+> POST /some/resource -> creates /some/resource/1234, redirects
+>
+> If /some/resource is a collection then PUT on that collection is supposed to
+> replace it entirely.
+
+Great, thanks for the explanation. I'll try to discuss that with the
+authors of the API
+
+-- 
+Samuel
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000412.html b/_build/static/archives/extend/2014-July/000412.html new file mode 100644 index 00000000..257bd622 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000412.html @@ -0,0 +1,80 @@ + + + + [99s-extend] HTTP Basic Auth base64 decode fails + + + + + + + + + + +

[99s-extend] HTTP Basic Auth base64 decode fails

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Jul 8 15:17:32 CEST 2014 +

+
+ +
Hello, y'all.
+
+I'm using HTTP Basic Auth in my API. While calling
+cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+Authorization header such as "Authorization: Basic Test1" I get an error
+500 back and an error log message on the server.
+
+1. Is this the expected behavior? [if I understand correctly, my request is
+going through authorization(UserPass, Type = <<"basic">>) and this has no
+check for the string being correctly encoded]
+
+2. what would be the best way to guard against this "error"?
+
+Thanks.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140708/35d8806d/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000413.html b/_build/static/archives/extend/2014-July/000413.html new file mode 100644 index 00000000..febfd6af --- /dev/null +++ b/_build/static/archives/extend/2014-July/000413.html @@ -0,0 +1,97 @@ + + + + [99s-extend] HTTP Basic Auth base64 decode fails + + + + + + + + + + +

[99s-extend] HTTP Basic Auth base64 decode fails

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jul 8 15:21:28 CEST 2014 +

+
+ +
Parsing of any header may crash. Some may also return an error tuple, 
+though that behavior slowly changes and it will always crash in 2.0. So 
+just wrap the call around a try/catch if you need to handle the error.
+
+Note that at this exact moment I'm working on returning 400 instead of 
+500 automatically when parsing headers end up crashing (and possibly 
+other situations later on).
+
+On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote:
+> Hello, y'all.
+>
+> I'm using HTTP Basic Auth in my API. While calling
+> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+> Authorization header such as "Authorization: Basic Test1" I get an error
+> 500 back and an error log message on the server.
+>
+> 1. Is this the expected behavior? [if I understand correctly, my request
+> is going through authorization(UserPass, Type = <<"basic">>) and this
+> has no check for the string being correctly encoded]
+>
+> 2. what would be the best way to guard against this "error"?
+>
+> Thanks.
+>
+> - Paulo F. Oliveira
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000414.html b/_build/static/archives/extend/2014-July/000414.html new file mode 100644 index 00000000..ff4a8266 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000414.html @@ -0,0 +1,119 @@ + + + + [99s-extend] HTTP Basic Auth base64 decode fails + + + + + + + + + + +

[99s-extend] HTTP Basic Auth base64 decode fails

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Jul 8 15:25:58 CEST 2014 +

+
+ +
Great, thanks.
+
+I saw some changes "from 422 to 400" in recent versions (PUT and POST).
+Thanks for the heads up. As long as they're document, no harm shall come of
+these changes.
+
+In any case, if I see it happen very often live I'll "protect" it agains
+the _bad_ header :-).
+
+Cheers.
+
+- Paulo F. Oliveira
+
+
+On 8 July 2014 14:21, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Parsing of any header may crash. Some may also return an error tuple,
+> though that behavior slowly changes and it will always crash in 2.0. So
+> just wrap the call around a try/catch if you need to handle the error.
+>
+> Note that at this exact moment I'm working on returning 400 instead of 500
+> automatically when parsing headers end up crashing (and possibly other
+> situations later on).
+>
+>
+> On 07/08/2014 03:17 PM, Paulo F. Oliveira wrote:
+>
+>> Hello, y'all.
+>>
+>> I'm using HTTP Basic Auth in my API. While calling
+>> cowboy_req:parse_header(<<"authorization>>", ... with an _invalid_
+>> Authorization header such as "Authorization: Basic Test1" I get an error
+>> 500 back and an error log message on the server.
+>>
+>> 1. Is this the expected behavior? [if I understand correctly, my request
+>> is going through authorization(UserPass, Type = <<"basic">>) and this
+>> has no check for the string being correctly encoded]
+>>
+>> 2. what would be the best way to guard against this "error"?
+>>
+>> Thanks.
+>>
+>> - Paulo F. Oliveira
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140708/497ef9a1/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000415.html b/_build/static/archives/extend/2014-July/000415.html new file mode 100644 index 00000000..a9760d05 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000415.html @@ -0,0 +1,85 @@ + + + + [99s-extend] couldn't quit in Erlang 17.1 + + + + + + + + + + +

[99s-extend] couldn't quit in Erlang 17.1

+ chaehb + chaehb at gmail.com +
+ Sat Jul 26 09:06:15 CEST 2014 +

+
+ +
Hi, everybody.
+
+After Erlang updated to 17.1,
+when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages..
+
+(after ok signal printed)
+
+…...
+=ERROR REPORT==== 26-Jul-2014::15:23:33 ===
+Error in process <0.334.0> on node ‘...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+….
+
+Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments.
+
+This is only appeared when I only use ssl(https).
+But when use only http with same dispatch rules, cowboy normally quitted.
+
+What’s wrong? or Normal ?
+
+my environment : 
+OS : Mac OS X Mavricks
+Erlang/OTP : 17.1 from Homebrew
+release tool : relx
+Cowboy and others : latest 
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/000416.html b/_build/static/archives/extend/2014-July/000416.html new file mode 100644 index 00000000..ec773f76 --- /dev/null +++ b/_build/static/archives/extend/2014-July/000416.html @@ -0,0 +1,94 @@ + + + + [99s-extend] couldn't quit in Erlang 17.1 + + + + + + + + + + +

[99s-extend] couldn't quit in Erlang 17.1

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Jul 27 11:25:50 CEST 2014 +

+
+ +
Does it happen with ssl_hello_world?
+
+On 07/26/2014 09:06 AM, chaehb wrote:
+> Hi, everybody.
+>
+> After Erlang updated to 17.1,
+> when I run q(). command on erlang console, cowboy couldn't quitted but print series of messages..
+>
+> (after ok signal printed)
+>
+> …...
+> =ERROR REPORT==== 26-Jul-2014::15:23:33 ===
+> Error in process <0.334.0> on node ‘...my node name...' with exit value: {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+> ….
+>
+> Before erlang updated (in 17.0), application could be normally quitted exactly same codes and environments.
+>
+> This is only appeared when I only use ssl(https).
+> But when use only http with same dispatch rules, cowboy normally quitted.
+>
+> What’s wrong? or Normal ?
+>
+> my environment :
+> OS : Mac OS X Mavricks
+> Erlang/OTP : 17.1 from Homebrew
+> release tool : relx
+> Cowboy and others : latest
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-July/author.html b/_build/static/archives/extend/2014-July/author.html new file mode 100644 index 00000000..45e5995a --- /dev/null +++ b/_build/static/archives/extend/2014-July/author.html @@ -0,0 +1,107 @@ + + + + The Extend July 2014 Archive by author + + + + + +

July 2014 Archives by author

+ +

Starting: Thu Jul 3 09:40:12 CEST 2014
+ Ending: Sun Jul 27 11:25:50 CEST 2014
+ Messages: 12

+

+

+ Last message date: + Sun Jul 27 11:25:50 CEST 2014
+ Archived on: Sun Jul 27 11:25:48 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-July/date.html b/_build/static/archives/extend/2014-July/date.html new file mode 100644 index 00000000..488e6784 --- /dev/null +++ b/_build/static/archives/extend/2014-July/date.html @@ -0,0 +1,107 @@ + + + + The Extend July 2014 Archive by date + + + + + +

July 2014 Archives by date

+ +

Starting: Thu Jul 3 09:40:12 CEST 2014
+ Ending: Sun Jul 27 11:25:50 CEST 2014
+ Messages: 12

+

+

+ Last message date: + Sun Jul 27 11:25:50 CEST 2014
+ Archived on: Sun Jul 27 11:25:48 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-July/index.html b/_build/static/archives/extend/2014-July/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-July/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-July/subject.html b/_build/static/archives/extend/2014-July/subject.html new file mode 100644 index 00000000..9b9f9086 --- /dev/null +++ b/_build/static/archives/extend/2014-July/subject.html @@ -0,0 +1,107 @@ + + + + The Extend July 2014 Archive by subject + + + + + +

July 2014 Archives by subject

+ +

Starting: Thu Jul 3 09:40:12 CEST 2014
+ Ending: Sun Jul 27 11:25:50 CEST 2014
+ Messages: 12

+

+

+ Last message date: + Sun Jul 27 11:25:50 CEST 2014
+ Archived on: Sun Jul 27 11:25:48 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-July/thread.html b/_build/static/archives/extend/2014-July/thread.html new file mode 100644 index 00000000..6a2c101c --- /dev/null +++ b/_build/static/archives/extend/2014-July/thread.html @@ -0,0 +1,133 @@ + + + + The Extend July 2014 Archive by thread + + + + + +

July 2014 Archives by thread

+ +

Starting: Thu Jul 3 09:40:12 CEST 2014
+ Ending: Sun Jul 27 11:25:50 CEST 2014
+ Messages: 12

+

+

+ Last message date: + Sun Jul 27 11:25:50 CEST 2014
+ Archived on: Sun Jul 27 11:25:48 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-June.txt b/_build/static/archives/extend/2014-June.txt new file mode 100644 index 00000000..38e87b0b --- /dev/null +++ b/_build/static/archives/extend/2014-June.txt @@ -0,0 +1,870 @@ +From daniel.goertzen at gmail.com Wed Jun 4 22:08:54 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Wed, 4 Jun 2014 15:08:54 -0500 +Subject: [99s-extend] cowboy client cert auth, basic auth +Message-ID: + +I am having very good luck with Cowboy so far, but I have some questions: + +1. There doesn't appear to be any way to do client certificate +authorization in Cowboy, although I see there is an example for doing +exactly that with Ranch. I think I could modify Cowboy to do what I want, +but I thought I would ask if there were other options before doing that. + +2. I am also looking at http basic auth. Would creating a middleware to +sit in between cowboy_router and cowboy_handler be a typical way to go +about it? + +Thanks, +Dan. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From paulo.ferraz.oliveira at gmail.com Wed Jun 4 23:37:14 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Wed, 4 Jun 2014 22:37:14 +0100 +Subject: [99s-extend] Mandatory init/3 and optional handle/2 and terminate/3 +Message-ID: + +Hello. + +You wrote here +that +"The only mandatory callback is init/3, needed to perform the protocol +upgrade." + +In my code I have only this function for the protocol upgrade: + +init({_TransportName, _ProtocolName}, _Req, []) -> + {upgrade, protocol, cowboy_rest}. + +On the other hand, when compiling, I get the following warnings: + +src/handler_transactions.erl:3: Warning: undefined callback function +handle/2 (behaviour 'cowboy_http_handler') +src/handler_transactions.erl:3: Warning: undefined callback function +terminate/3 (behaviour 'cowboy_http_handler') + +Is this the expected behavior? I know I _can_ ignore the warnings, but not +if I want to use Erlang compiler option warnings_as_errors, for example. + +Many thanks. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Jun 4 23:46:38 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 04 Jun 2014 23:46:38 +0200 +Subject: [99s-extend] Mandatory init/3 and optional handle/2 and + terminate/3 +In-Reply-To: +References: +Message-ID: <538F93BE.4080002@ninenines.eu> + +You shouldn't say -behavior(cowboy_http_handler) if you don't actually +implement it. + +On 06/04/2014 11:37 PM, Paulo F. Oliveira wrote: +> Hello. +> +> You wrote here +> that "The +> only mandatory callback is init/3, needed to perform the protocol upgrade." +> +> In my code I have only this function for the protocol upgrade: +> +> init({_TransportName, _ProtocolName}, _Req, []) -> +> {upgrade, protocol, cowboy_rest}. +> +> On the other hand, when compiling, I get the following warnings: +> +> src/handler_transactions.erl:3: Warning: undefined callback function +> handle/2 (behaviour 'cowboy_http_handler') +> src/handler_transactions.erl:3: Warning: undefined callback function +> terminate/3 (behaviour 'cowboy_http_handler') +> +> Is this the expected behavior? I know I _can_ ignore the warnings, but +> not if I want to use Erlang compiler option warnings_as_errors, for example. +> +> Many thanks. +> +> - Paulo F. Oliveira +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Wed Jun 4 23:48:01 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 04 Jun 2014 23:48:01 +0200 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: +References: +Message-ID: <538F9411.6070108@ninenines.eu> + +On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +> I am having very good luck with Cowboy so far, but I have some questions: +> +> 1. There doesn't appear to be any way to do client certificate +> authorization in Cowboy, although I see there is an example for doing +> exactly that with Ranch. I think I could modify Cowboy to do what I +> want, but I thought I would ask if there were other options before doing +> that. + +Same as Ranch really, you just gotta take the socket and then call the +ssl functions. + +> 2. I am also looking at http basic auth. Would creating a middleware to +> sit in between cowboy_router and cowboy_handler be a typical way to go +> about it? + +That's a common way to do it yes. + +-- +Lo?c Hoguin +http://ninenines.eu + +From daniel.goertzen at gmail.com Thu Jun 5 01:44:02 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Wed, 4 Jun 2014 18:44:02 -0500 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: <538F9411.6070108@ninenines.eu> +References: + <538F9411.6070108@ninenines.eu> +Message-ID: + +On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin wrote: + +> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +> +>> I am having very good luck with Cowboy so far, but I have some questions: +>> +>> 1. There doesn't appear to be any way to do client certificate +>> authorization in Cowboy, although I see there is an example for doing +>> exactly that with Ranch. I think I could modify Cowboy to do what I +>> want, but I thought I would ask if there were other options before doing +>> that. +>> +> +> Same as Ranch really, you just gotta take the socket and then call the ssl +> functions. +> +> +Yes, but in cowboy there's no API to get at the socket. + +I was thinking of adding a "onconnect" hook similar to how there are +"onrequest" and "onresponse" hooks. The hook would be called in +cowboy_protocol:init(), would accept Transport and Socket, and return a +"user connection state" term that gets stashed in the state record. The +user connection state would then be provided in the Req object to each +handler. With these features one could do whatever computation they want +on the socket and provide the result to all subsequent requests on that +socket. I want to use it for client cert checking, but it could be used +for other things such as an IP address security check. + +Dan. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From paulo.ferraz.oliveira at gmail.com Thu Jun 5 01:49:01 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Thu, 5 Jun 2014 00:49:01 +0100 +Subject: [99s-extend] Mandatory init/3 and optional handle/2 and + terminate/3 +In-Reply-To: <538F93BE.4080002@ninenines.eu> +References: + <538F93BE.4080002@ninenines.eu> +Message-ID: + +Got it, thanks. + +This here had +the fine print that I hadn't read apparently: "This module cannot be +described as a behaviour due to most of the callbacks it defines being +optional. It has the same semantics as a behaviour otherwise." + +- Paulo F. Oliveira + + +On 4 June 2014 22:46, Lo?c Hoguin wrote: + +> You shouldn't say -behavior(cowboy_http_handler) if you don't actually +> implement it. +> +> On 06/04/2014 11:37 PM, Paulo F. Oliveira wrote: +> +>> Hello. +>> +>> You wrote here +>> that "The +>> +>> only mandatory callback is init/3, needed to perform the protocol +>> upgrade." +>> +>> In my code I have only this function for the protocol upgrade: +>> +>> init({_TransportName, _ProtocolName}, _Req, []) -> +>> {upgrade, protocol, cowboy_rest}. +>> +>> On the other hand, when compiling, I get the following warnings: +>> +>> src/handler_transactions.erl:3: Warning: undefined callback function +>> handle/2 (behaviour 'cowboy_http_handler') +>> src/handler_transactions.erl:3: Warning: undefined callback function +>> terminate/3 (behaviour 'cowboy_http_handler') +>> +>> Is this the expected behavior? I know I _can_ ignore the warnings, but +>> not if I want to use Erlang compiler option warnings_as_errors, for +>> example. +>> +>> Many thanks. +>> +>> - Paulo F. Oliveira +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jun 5 10:04:08 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 05 Jun 2014 10:04:08 +0200 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: +References: <538F9411.6070108@ninenines.eu> + +Message-ID: <53902478.40303@ninenines.eu> + +On 06/05/2014 01:44 AM, Daniel Goertzen wrote: +> +> +> +> On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin > wrote: +> +> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +> +> I am having very good luck with Cowboy so far, but I have some +> questions: +> +> 1. There doesn't appear to be any way to do client certificate +> authorization in Cowboy, although I see there is an example for +> doing +> exactly that with Ranch. I think I could modify Cowboy to do what I +> want, but I thought I would ask if there were other options +> before doing +> that. +> +> +> Same as Ranch really, you just gotta take the socket and then call +> the ssl functions. +> +> +> Yes, but in cowboy there's no API to get at the socket. + +There is the undocumented function cowboy_req:get/1 which is meant for +that kind of "special" use. + +-- +Lo?c Hoguin +http://ninenines.eu + +From daniel.goertzen at gmail.com Thu Jun 5 23:01:12 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Thu, 5 Jun 2014 16:01:12 -0500 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: <53902478.40303@ninenines.eu> +References: + <538F9411.6070108@ninenines.eu> + + <53902478.40303@ninenines.eu> +Message-ID: + +But then I would have to check the client cert for each and every request. +I should have to check the cert only once at connect time and then be able +to pass the result of that check in the request to each handler. + +Anyway I've gone ahead and implemented what I need in a generic manner and +it seems to work well. I think it would be a useful addition to Cowboy. +If you agree I could write some more documentation for it. + +https://github.com/goertzenator/cowboy/tree/onconnect + +I added a "onconnect" hook and "connection metadata" to cowboy_req. The +connection metadata works like existing metadata, but is preserved from +request to request on the same connection. The onconnect hook provides +initial values for the connection metadata. + +Dan. + + + + +On Thu, Jun 5, 2014 at 3:04 AM, Lo?c Hoguin wrote: + +> On 06/05/2014 01:44 AM, Daniel Goertzen wrote: +> +>> +>> +>> +>> On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin > > wrote: +>> +>> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +>> +>> I am having very good luck with Cowboy so far, but I have some +>> questions: +>> +>> 1. There doesn't appear to be any way to do client certificate +>> authorization in Cowboy, although I see there is an example for +>> doing +>> exactly that with Ranch. I think I could modify Cowboy to do +>> what I +>> want, but I thought I would ask if there were other options +>> before doing +>> that. +>> +>> +>> Same as Ranch really, you just gotta take the socket and then call +>> the ssl functions. +>> +>> +>> Yes, but in cowboy there's no API to get at the socket. +>> +> +> There is the undocumented function cowboy_req:get/1 which is meant for +> that kind of "special" use. +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Jun 5 23:24:50 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 05 Jun 2014 23:24:50 +0200 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: +References: <538F9411.6070108@ninenines.eu> <53902478.40303@ninenines.eu> + +Message-ID: <5390E022.40403@ninenines.eu> + +Misunderstood what you needed then. + +Note that the services that are completely blocked from anyone who +doesn't have the right cert are virtually non-existent, it doesn't make +sense to add a feature for it. + +You can do that kind of thing by having custom code creating the +protocol process by the way. There's no need to patch Cowboy for that. + +On 06/05/2014 11:01 PM, Daniel Goertzen wrote: +> But then I would have to check the client cert for each and every +> request. I should have to check the cert only once at connect time and +> then be able to pass the result of that check in the request to each +> handler. +> +> Anyway I've gone ahead and implemented what I need in a generic manner +> and it seems to work well. I think it would be a useful addition to +> Cowboy. If you agree I could write some more documentation for it. +> +> https://github.com/goertzenator/cowboy/tree/onconnect +> +> I added a "onconnect" hook and "connection metadata" to cowboy_req. The +> connection metadata works like existing metadata, but is preserved from +> request to request on the same connection. The onconnect hook provides +> initial values for the connection metadata. +> +> Dan. +> +> +> +> +> On Thu, Jun 5, 2014 at 3:04 AM, Lo?c Hoguin > wrote: +> +> On 06/05/2014 01:44 AM, Daniel Goertzen wrote: +> +> +> +> +> On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin +> >> wrote: +> +> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +> +> I am having very good luck with Cowboy so far, but I +> have some +> questions: +> +> 1. There doesn't appear to be any way to do client +> certificate +> authorization in Cowboy, although I see there is an +> example for +> doing +> exactly that with Ranch. I think I could modify Cowboy +> to do what I +> want, but I thought I would ask if there were other options +> before doing +> that. +> +> +> Same as Ranch really, you just gotta take the socket and +> then call +> the ssl functions. +> +> +> Yes, but in cowboy there's no API to get at the socket. +> +> +> There is the undocumented function cowboy_req:get/1 which is meant +> for that kind of "special" use. +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From daniel.goertzen at gmail.com Fri Jun 6 15:59:43 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Fri, 6 Jun 2014 08:59:43 -0500 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: <5390E022.40403@ninenines.eu> +References: + <538F9411.6070108@ninenines.eu> + + <53902478.40303@ninenines.eu> + + <5390E022.40403@ninenines.eu> +Message-ID: + +Okay, I see how I can wrap cowboy_protocol:init() to perhaps add cert +information to env or stuff it in an ets table / gproc / process +dictionary. Is this what you mean? I think that will work for me. + +My immediate application is to provide a secure RESTful API for a network +appliance. Think securing the Web of Things. I really do want to get in +the client's face if they don't have the right certificate. + +I'm late in saying this, but thank you for making Cowboy so easy to read +and understand. + +Cheers, +Dan. + + + +On Thu, Jun 5, 2014 at 4:24 PM, Lo?c Hoguin wrote: + +> Misunderstood what you needed then. +> +> Note that the services that are completely blocked from anyone who doesn't +> have the right cert are virtually non-existent, it doesn't make sense to +> add a feature for it. +> +> You can do that kind of thing by having custom code creating the protocol +> process by the way. There's no need to patch Cowboy for that. +> +> +> On 06/05/2014 11:01 PM, Daniel Goertzen wrote: +> +>> But then I would have to check the client cert for each and every +>> request. I should have to check the cert only once at connect time and +>> then be able to pass the result of that check in the request to each +>> handler. +>> +>> Anyway I've gone ahead and implemented what I need in a generic manner +>> and it seems to work well. I think it would be a useful addition to +>> Cowboy. If you agree I could write some more documentation for it. +>> +>> https://github.com/goertzenator/cowboy/tree/onconnect +>> +>> I added a "onconnect" hook and "connection metadata" to cowboy_req. The +>> connection metadata works like existing metadata, but is preserved from +>> request to request on the same connection. The onconnect hook provides +>> initial values for the connection metadata. +>> +>> Dan. +>> +>> +>> +>> +>> On Thu, Jun 5, 2014 at 3:04 AM, Lo?c Hoguin > > wrote: +>> +>> On 06/05/2014 01:44 AM, Daniel Goertzen wrote: +>> +>> +>> +>> +>> On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin > +>> >> wrote: +>> +>> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +>> +>> I am having very good luck with Cowboy so far, but I +>> have some +>> questions: +>> +>> 1. There doesn't appear to be any way to do client +>> certificate +>> authorization in Cowboy, although I see there is an +>> example for +>> doing +>> exactly that with Ranch. I think I could modify Cowboy +>> to do what I +>> want, but I thought I would ask if there were other +>> options +>> before doing +>> that. +>> +>> +>> Same as Ranch really, you just gotta take the socket and +>> then call +>> the ssl functions. +>> +>> +>> Yes, but in cowboy there's no API to get at the socket. +>> +>> +>> There is the undocumented function cowboy_req:get/1 which is meant +>> for that kind of "special" use. +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Jun 6 16:09:56 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 06 Jun 2014 16:09:56 +0200 +Subject: [99s-extend] cowboy client cert auth, basic auth +In-Reply-To: +References: <538F9411.6070108@ninenines.eu> <53902478.40303@ninenines.eu> <5390E022.40403@ninenines.eu> + +Message-ID: <5391CBB4.7060606@ninenines.eu> + +On 06/06/2014 03:59 PM, Daniel Goertzen wrote: +> Okay, I see how I can wrap cowboy_protocol:init() to perhaps add cert +> information to env or stuff it in an ets table / gproc / process +> dictionary. Is this what you mean? I think that will work for me. + +Something like that, yes. Process dictionary is probably the quick and +dirty way, env would be cleaner but take more code as you then have to +move it from env to handler opts. + +> My immediate application is to provide a secure RESTful API for a +> network appliance. Think securing the Web of Things. I really do want +> to get in the client's face if they don't have the right certificate. +> +> I'm late in saying this, but thank you for making Cowboy so easy to read +> and understand. +> +> Cheers, +> Dan. +> +> +> +> On Thu, Jun 5, 2014 at 4:24 PM, Lo?c Hoguin > wrote: +> +> Misunderstood what you needed then. +> +> Note that the services that are completely blocked from anyone who +> doesn't have the right cert are virtually non-existent, it doesn't +> make sense to add a feature for it. +> +> You can do that kind of thing by having custom code creating the +> protocol process by the way. There's no need to patch Cowboy for that. +> +> +> On 06/05/2014 11:01 PM, Daniel Goertzen wrote: +> +> But then I would have to check the client cert for each and every +> request. I should have to check the cert only once at connect +> time and +> then be able to pass the result of that check in the request to each +> handler. +> +> Anyway I've gone ahead and implemented what I need in a generic +> manner +> and it seems to work well. I think it would be a useful addition to +> Cowboy. If you agree I could write some more documentation for it. +> +> https://github.com/__goertzenator/cowboy/tree/__onconnect +> +> +> I added a "onconnect" hook and "connection metadata" to +> cowboy_req. The +> connection metadata works like existing metadata, but is +> preserved from +> request to request on the same connection. The onconnect hook +> provides +> initial values for the connection metadata. +> +> Dan. +> +> +> +> +> On Thu, Jun 5, 2014 at 3:04 AM, Lo?c Hoguin +> >> wrote: +> +> On 06/05/2014 01:44 AM, Daniel Goertzen wrote: +> +> +> +> +> On Wed, Jun 4, 2014 at 4:48 PM, Lo?c Hoguin +> +> > +> +> >>> wrote: +> +> On 06/04/2014 10:08 PM, Daniel Goertzen wrote: +> +> I am having very good luck with Cowboy so far, +> but I +> have some +> questions: +> +> 1. There doesn't appear to be any way to do client +> certificate +> authorization in Cowboy, although I see there +> is an +> example for +> doing +> exactly that with Ranch. I think I could +> modify Cowboy +> to do what I +> want, but I thought I would ask if there were +> other options +> before doing +> that. +> +> +> Same as Ranch really, you just gotta take the +> socket and +> then call +> the ssl functions. +> +> +> Yes, but in cowboy there's no API to get at the socket. +> +> +> There is the undocumented function cowboy_req:get/1 which +> is meant +> for that kind of "special" use. +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Tue Jun 10 12:38:10 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 10 Jun 2014 12:38:10 +0200 +Subject: [99s-extend] [ANN] Cowboy and Ranch 0.10 +Message-ID: <5396E012.4070900@ninenines.eu> + +Hello! + +I just pushed Cowboy 0.10 and Ranch 0.10. + + https://github.com/extend/cowboy + https://github.com/extend/ranch + +The Cowboy changelog can be found here: +https://github.com/extend/cowboy/blob/master/CHANGELOG.md + +This release sees the addition of functions for reading multipart! (And +there are also functions for creating multipart bodies in the cowlib +library if you need them.) The old multipart interface got removed. + +The other big change is a rework of the body reading interface, again. +Users have reported having timeout issues sometimes so the new interface +allows you to configure read length/timeout so you can control the rate +of transfer *per body function call*. + +The functions init_stream, stream_body and skip_body have been +deprecated and will be removed in 1.0 (alongside one clause of the +body/2 and body_qs/2 functions). + +Current code *should* be compatible but you are really encouraged to +test and remove dead code introduced by this change. + +The changes in Ranch are mostly small so I won't bore you with the details. + +The next step will be to release 1.0 sometimes this summer. Work on 2.0 +will start immediately after that but 2.0 is planned to be released +after Erlang 18.0 is out. We'll have a new version bump for every Erlang +version basically. More details later. + +Hope you enjoy this release, and that I didn't break your code (too much)! + +Enjoy. + +-- +Lo?c Hoguin +http://ninenines.eu + +From roger at differentpla.net Wed Jun 11 14:38:59 2014 +From: roger at differentpla.net (Roger Lipscombe) +Date: Wed, 11 Jun 2014 13:38:59 +0100 +Subject: [99s-extend] Stop ranch listeners without dropping connections +Message-ID: + +Using ranch, is there any way to stop the listener (and acceptors) +without dropping the existing connections? + +I ask because I'd like to start another instance of my server on the +same box and have the old instance continue to handle its existing +connections for a while. + +It looks to me that if I call ranch:stop_listener, it'll kill the +ranch_listener_sup, which will also kill the ranch_conns_sup (and the +existing connections). + +If I manually do a supervisor:terminate_child(ListenerPid, +ranch_acceptors_sup), the acceptors go away, but the socket is still +open, which means that I can't start another instance of my server. + +Thoughts? + +From essen at ninenines.eu Mon Jun 23 13:36:50 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 23 Jun 2014 13:36:50 +0200 +Subject: [99s-extend] Stop ranch listeners without dropping connections +In-Reply-To: +References: +Message-ID: <53A81152.9020404@ninenines.eu> + +It is not possible at this point. Please open a ticket. + +On 06/11/2014 02:38 PM, Roger Lipscombe wrote: +> Using ranch, is there any way to stop the listener (and acceptors) +> without dropping the existing connections? +> +> I ask because I'd like to start another instance of my server on the +> same box and have the old instance continue to handle its existing +> connections for a while. +> +> It looks to me that if I call ranch:stop_listener, it'll kill the +> ranch_listener_sup, which will also kill the ranch_conns_sup (and the +> existing connections). +> +> If I manually do a supervisor:terminate_child(ListenerPid, +> ranch_acceptors_sup), the acceptors go away, but the socket is still +> open, which means that I can't start another instance of my server. +> +> Thoughts? +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From roger at differentpla.net Mon Jun 23 15:55:47 2014 +From: roger at differentpla.net (Roger Lipscombe) +Date: Mon, 23 Jun 2014 14:55:47 +0100 +Subject: [99s-extend] Stop ranch listeners without dropping connections +In-Reply-To: <53A81152.9020404@ninenines.eu> +References: + <53A81152.9020404@ninenines.eu> +Message-ID: + +Done: https://github.com/extend/ranch/issues/83 + +On 23 June 2014 12:36, Lo?c Hoguin wrote: +> It is not possible at this point. Please open a ticket. +> +> +> On 06/11/2014 02:38 PM, Roger Lipscombe wrote: +>> +>> Using ranch, is there any way to stop the listener (and acceptors) +>> without dropping the existing connections? +>> +>> I ask because I'd like to start another instance of my server on the +>> same box and have the old instance continue to handle its existing +>> connections for a while. +>> +>> It looks to me that if I call ranch:stop_listener, it'll kill the +>> ranch_listener_sup, which will also kill the ranch_conns_sup (and the +>> existing connections). +>> +>> If I manually do a supervisor:terminate_child(ListenerPid, +>> ranch_acceptors_sup), the acceptors go away, but the socket is still +>> open, which means that I can't start another instance of my server. +>> +>> Thoughts? +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + diff --git a/_build/static/archives/extend/2014-June/000390.html b/_build/static/archives/extend/2014-June/000390.html new file mode 100644 index 00000000..3c810f7c --- /dev/null +++ b/_build/static/archives/extend/2014-June/000390.html @@ -0,0 +1,76 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Wed Jun 4 22:08:54 CEST 2014 +

+
+ +
I am having very good luck with Cowboy so far, but I have some questions:
+
+1. There doesn't appear to be any way to do client certificate
+authorization in Cowboy, although I see there is an example for doing
+exactly that with Ranch.  I think I could modify Cowboy to do what I want,
+but I thought I would ask if there were other options before doing that.
+
+2. I am also looking at http basic auth.  Would creating a middleware to
+sit in between cowboy_router and cowboy_handler be a typical way to go
+about it?
+
+Thanks,
+Dan.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140604/269377d0/attachment.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000391.html b/_build/static/archives/extend/2014-June/000391.html new file mode 100644 index 00000000..5f42bab4 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000391.html @@ -0,0 +1,96 @@ + + + + [99s-extend] Mandatory init/3 and optional handle/2 and terminate/3 + + + + + + + + + + +

[99s-extend] Mandatory init/3 and optional handle/2 and terminate/3

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Wed Jun 4 23:37:14 CEST 2014 +

+
+ +
Hello.
+
+You wrote here <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest/>
+that
+"The only mandatory callback is init/3, needed to perform the protocol
+upgrade."
+
+In my code I have only this function for the protocol upgrade:
+
+init({_TransportName, _ProtocolName}, _Req, []) ->
+    {upgrade, protocol, cowboy_rest}.
+
+On the other hand, when compiling, I get the following warnings:
+
+src/handler_transactions.erl:3: Warning: undefined callback function
+handle/2 (behaviour 'cowboy_http_handler')
+src/handler_transactions.erl:3: Warning: undefined callback function
+terminate/3 (behaviour 'cowboy_http_handler')
+
+Is this the expected behavior? I know I _can_ ignore the warnings, but not
+if I want to use Erlang compiler option warnings_as_errors, for example.
+
+Many thanks.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140604/407d3443/attachment.html>
+
+ + + + + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000392.html b/_build/static/archives/extend/2014-June/000392.html new file mode 100644 index 00000000..ad195989 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000392.html @@ -0,0 +1,107 @@ + + + + [99s-extend] Mandatory init/3 and optional handle/2 and terminate/3 + + + + + + + + + + +

[99s-extend] Mandatory init/3 and optional handle/2 and terminate/3

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jun 4 23:46:38 CEST 2014 +

+
+ +
You shouldn't say -behavior(cowboy_http_handler) if you don't actually 
+implement it.
+
+On 06/04/2014 11:37 PM, Paulo F. Oliveira wrote:
+> Hello.
+>
+> You wrote here
+> <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest/> that "The
+> only mandatory callback is init/3, needed to perform the protocol upgrade."
+>
+> In my code I have only this function for the protocol upgrade:
+>
+> init({_TransportName, _ProtocolName}, _Req, []) ->
+>      {upgrade, protocol, cowboy_rest}.
+>
+> On the other hand, when compiling, I get the following warnings:
+>
+> src/handler_transactions.erl:3: Warning: undefined callback function
+> handle/2 (behaviour 'cowboy_http_handler')
+> src/handler_transactions.erl:3: Warning: undefined callback function
+> terminate/3 (behaviour 'cowboy_http_handler')
+>
+> Is this the expected behavior? I know I _can_ ignore the warnings, but
+> not if I want to use Erlang compiler option warnings_as_errors, for example.
+>
+> Many thanks.
+>
+> - Paulo F. Oliveira
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000393.html b/_build/static/archives/extend/2014-June/000393.html new file mode 100644 index 00000000..af91e497 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000393.html @@ -0,0 +1,82 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jun 4 23:48:01 CEST 2014 +

+
+ +
On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+> I am having very good luck with Cowboy so far, but I have some questions:
+>
+> 1. There doesn't appear to be any way to do client certificate
+> authorization in Cowboy, although I see there is an example for doing
+> exactly that with Ranch.  I think I could modify Cowboy to do what I
+> want, but I thought I would ask if there were other options before doing
+> that.
+
+Same as Ranch really, you just gotta take the socket and then call the 
+ssl functions.
+
+> 2. I am also looking at http basic auth.  Would creating a middleware to
+> sit in between cowboy_router and cowboy_handler be a typical way to go
+> about it?
+
+That's a common way to do it yes.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000394.html b/_build/static/archives/extend/2014-June/000394.html new file mode 100644 index 00000000..034d580f --- /dev/null +++ b/_build/static/archives/extend/2014-June/000394.html @@ -0,0 +1,94 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Thu Jun 5 01:44:02 CEST 2014 +

+
+ +
On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>
+>> I am having very good luck with Cowboy so far, but I have some questions:
+>>
+>> 1. There doesn't appear to be any way to do client certificate
+>> authorization in Cowboy, although I see there is an example for doing
+>> exactly that with Ranch.  I think I could modify Cowboy to do what I
+>> want, but I thought I would ask if there were other options before doing
+>> that.
+>>
+>
+> Same as Ranch really, you just gotta take the socket and then call the ssl
+> functions.
+>
+>
+Yes, but in cowboy there's no API to get at the socket.
+
+I was thinking of adding a "onconnect" hook similar to how there are
+"onrequest" and "onresponse" hooks.  The hook would be called in
+cowboy_protocol:init(), would accept Transport and Socket, and return a
+"user connection state" term that gets stashed in the state record.  The
+user connection state would then be provided in the Req object to each
+handler.  With these features one could do whatever computation they want
+on the socket and provide the result to all subsequent requests on that
+socket.  I want to use it for client cert checking, but it could be used
+for other things such as an IP address security check.
+
+Dan.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140604/2bce99e1/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000395.html b/_build/static/archives/extend/2014-June/000395.html new file mode 100644 index 00000000..52e04be4 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000395.html @@ -0,0 +1,125 @@ + + + + [99s-extend] Mandatory init/3 and optional handle/2 and terminate/3 + + + + + + + + + + +

[99s-extend] Mandatory init/3 and optional handle/2 and terminate/3

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Thu Jun 5 01:49:01 CEST 2014 +

+
+ +
Got it, thanks.
+
+This here <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest/> had
+the fine print that I hadn't read apparently: "This module cannot be
+described as a behaviour due to most of the callbacks it defines being
+optional. It has the same semantics as a behaviour otherwise."
+
+- Paulo F. Oliveira
+
+
+On 4 June 2014 22:46, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> You shouldn't say -behavior(cowboy_http_handler) if you don't actually
+> implement it.
+>
+> On 06/04/2014 11:37 PM, Paulo F. Oliveira wrote:
+>
+>> Hello.
+>>
+>> You wrote here
+>> <http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_rest/> that "The
+>>
+>> only mandatory callback is init/3, needed to perform the protocol
+>> upgrade."
+>>
+>> In my code I have only this function for the protocol upgrade:
+>>
+>> init({_TransportName, _ProtocolName}, _Req, []) ->
+>>      {upgrade, protocol, cowboy_rest}.
+>>
+>> On the other hand, when compiling, I get the following warnings:
+>>
+>> src/handler_transactions.erl:3: Warning: undefined callback function
+>> handle/2 (behaviour 'cowboy_http_handler')
+>> src/handler_transactions.erl:3: Warning: undefined callback function
+>> terminate/3 (behaviour 'cowboy_http_handler')
+>>
+>> Is this the expected behavior? I know I _can_ ignore the warnings, but
+>> not if I want to use Erlang compiler option warnings_as_errors, for
+>> example.
+>>
+>> Many thanks.
+>>
+>> - Paulo F. Oliveira
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140605/46eee3c0/attachment.html>
+
+ + + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000396.html b/_build/static/archives/extend/2014-June/000396.html new file mode 100644 index 00000000..c40ed995 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000396.html @@ -0,0 +1,94 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jun 5 10:04:08 CEST 2014 +

+
+ +
On 06/05/2014 01:44 AM, Daniel Goertzen wrote:
+>
+>
+>
+> On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>
+>         I am having very good luck with Cowboy so far, but I have some
+>         questions:
+>
+>         1. There doesn't appear to be any way to do client certificate
+>         authorization in Cowboy, although I see there is an example for
+>         doing
+>         exactly that with Ranch.  I think I could modify Cowboy to do what I
+>         want, but I thought I would ask if there were other options
+>         before doing
+>         that.
+>
+>
+>     Same as Ranch really, you just gotta take the socket and then call
+>     the ssl functions.
+>
+>
+> Yes, but in cowboy there's no API to get at the socket.
+
+There is the undocumented function cowboy_req:get/1 which is meant for 
+that kind of "special" use.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000397.html b/_build/static/archives/extend/2014-June/000397.html new file mode 100644 index 00000000..30d4a738 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000397.html @@ -0,0 +1,124 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Thu Jun 5 23:01:12 CEST 2014 +

+
+ +
But then I would have to check the client cert for each and every request.
+I should have to check the cert only once at connect time and then be able
+to pass the result of that check in the request to each handler.
+
+Anyway I've gone ahead and implemented what I need in a generic manner and
+it seems to work well.  I think it would be a useful addition to Cowboy.
+If you agree I could write some more documentation for it.
+
+https://github.com/goertzenator/cowboy/tree/onconnect
+
+I added a "onconnect" hook and "connection metadata" to cowboy_req.  The
+connection metadata works like existing metadata, but is preserved from
+request to request on the same connection.  The onconnect hook provides
+initial values for the connection metadata.
+
+Dan.
+
+
+
+
+On Thu, Jun 5, 2014 at 3:04 AM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> On 06/05/2014 01:44 AM, Daniel Goertzen wrote:
+>
+>>
+>>
+>>
+>> On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>>
+>>         I am having very good luck with Cowboy so far, but I have some
+>>         questions:
+>>
+>>         1. There doesn't appear to be any way to do client certificate
+>>         authorization in Cowboy, although I see there is an example for
+>>         doing
+>>         exactly that with Ranch.  I think I could modify Cowboy to do
+>> what I
+>>         want, but I thought I would ask if there were other options
+>>         before doing
+>>         that.
+>>
+>>
+>>     Same as Ranch really, you just gotta take the socket and then call
+>>     the ssl functions.
+>>
+>>
+>> Yes, but in cowboy there's no API to get at the socket.
+>>
+>
+> There is the undocumented function cowboy_req:get/1 which is meant for
+> that kind of "special" use.
+>
+>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140605/3ba15fb3/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000398.html b/_build/static/archives/extend/2014-June/000398.html new file mode 100644 index 00000000..32322b35 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000398.html @@ -0,0 +1,143 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jun 5 23:24:50 CEST 2014 +

+
+ +
Misunderstood what you needed then.
+
+Note that the services that are completely blocked from anyone who 
+doesn't have the right cert are virtually non-existent, it doesn't make 
+sense to add a feature for it.
+
+You can do that kind of thing by having custom code creating the 
+protocol process by the way. There's no need to patch Cowboy for that.
+
+On 06/05/2014 11:01 PM, Daniel Goertzen wrote:
+> But then I would have to check the client cert for each and every
+> request.  I should have to check the cert only once at connect time and
+> then be able to pass the result of that check in the request to each
+> handler.
+>
+> Anyway I've gone ahead and implemented what I need in a generic manner
+> and it seems to work well.  I think it would be a useful addition to
+> Cowboy.  If you agree I could write some more documentation for it.
+>
+> https://github.com/goertzenator/cowboy/tree/onconnect
+>
+> I added a "onconnect" hook and "connection metadata" to cowboy_req.  The
+> connection metadata works like existing metadata, but is preserved from
+> request to request on the same connection.  The onconnect hook provides
+> initial values for the connection metadata.
+>
+> Dan.
+>
+>
+>
+>
+> On Thu, Jun 5, 2014 at 3:04 AM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     On 06/05/2014 01:44 AM, Daniel Goertzen wrote:
+>
+>
+>
+>
+>         On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>
+>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>
+>              On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>
+>                  I am having very good luck with Cowboy so far, but I
+>         have some
+>                  questions:
+>
+>                  1. There doesn't appear to be any way to do client
+>         certificate
+>                  authorization in Cowboy, although I see there is an
+>         example for
+>                  doing
+>                  exactly that with Ranch.  I think I could modify Cowboy
+>         to do what I
+>                  want, but I thought I would ask if there were other options
+>                  before doing
+>                  that.
+>
+>
+>              Same as Ranch really, you just gotta take the socket and
+>         then call
+>              the ssl functions.
+>
+>
+>         Yes, but in cowboy there's no API to get at the socket.
+>
+>
+>     There is the undocumented function cowboy_req:get/1 which is meant
+>     for that kind of "special" use.
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000399.html b/_build/static/archives/extend/2014-June/000399.html new file mode 100644 index 00000000..a1d49efd --- /dev/null +++ b/_build/static/archives/extend/2014-June/000399.html @@ -0,0 +1,168 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Fri Jun 6 15:59:43 CEST 2014 +

+
+ +
Okay, I see how I can wrap cowboy_protocol:init() to perhaps add cert
+information to env or stuff it in an ets table / gproc / process
+dictionary.  Is this what you mean?  I think that will work for me.
+
+My immediate application is to provide a secure RESTful API for a network
+appliance.  Think securing the Web of Things.  I really do want to get in
+the client's face if they don't have the right certificate.
+
+I'm late in saying this, but thank you for making Cowboy so easy to read
+and understand.
+
+Cheers,
+Dan.
+
+
+
+On Thu, Jun 5, 2014 at 4:24 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Misunderstood what you needed then.
+>
+> Note that the services that are completely blocked from anyone who doesn't
+> have the right cert are virtually non-existent, it doesn't make sense to
+> add a feature for it.
+>
+> You can do that kind of thing by having custom code creating the protocol
+> process by the way. There's no need to patch Cowboy for that.
+>
+>
+> On 06/05/2014 11:01 PM, Daniel Goertzen wrote:
+>
+>> But then I would have to check the client cert for each and every
+>> request.  I should have to check the cert only once at connect time and
+>> then be able to pass the result of that check in the request to each
+>> handler.
+>>
+>> Anyway I've gone ahead and implemented what I need in a generic manner
+>> and it seems to work well.  I think it would be a useful addition to
+>> Cowboy.  If you agree I could write some more documentation for it.
+>>
+>> https://github.com/goertzenator/cowboy/tree/onconnect
+>>
+>> I added a "onconnect" hook and "connection metadata" to cowboy_req.  The
+>> connection metadata works like existing metadata, but is preserved from
+>> request to request on the same connection.  The onconnect hook provides
+>> initial values for the connection metadata.
+>>
+>> Dan.
+>>
+>>
+>>
+>>
+>> On Thu, Jun 5, 2014 at 3:04 AM, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     On 06/05/2014 01:44 AM, Daniel Goertzen wrote:
+>>
+>>
+>>
+>>
+>>         On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin <essen at ninenines.eu
+>>         <mailto:essen at ninenines.eu>
+>>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>>
+>>              On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>>
+>>                  I am having very good luck with Cowboy so far, but I
+>>         have some
+>>                  questions:
+>>
+>>                  1. There doesn't appear to be any way to do client
+>>         certificate
+>>                  authorization in Cowboy, although I see there is an
+>>         example for
+>>                  doing
+>>                  exactly that with Ranch.  I think I could modify Cowboy
+>>         to do what I
+>>                  want, but I thought I would ask if there were other
+>> options
+>>                  before doing
+>>                  that.
+>>
+>>
+>>              Same as Ranch really, you just gotta take the socket and
+>>         then call
+>>              the ssl functions.
+>>
+>>
+>>         Yes, but in cowboy there's no API to get at the socket.
+>>
+>>
+>>     There is the undocumented function cowboy_req:get/1 which is meant
+>>     for that kind of "special" use.
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140606/b992565e/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000400.html b/_build/static/archives/extend/2014-June/000400.html new file mode 100644 index 00000000..22d8dde0 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000400.html @@ -0,0 +1,189 @@ + + + + [99s-extend] cowboy client cert auth, basic auth + + + + + + + + + + +

[99s-extend] cowboy client cert auth, basic auth

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Jun 6 16:09:56 CEST 2014 +

+
+ +
On 06/06/2014 03:59 PM, Daniel Goertzen wrote:
+> Okay, I see how I can wrap cowboy_protocol:init() to perhaps add cert
+> information to env or stuff it in an ets table / gproc / process
+> dictionary.  Is this what you mean?  I think that will work for me.
+
+Something like that, yes. Process dictionary is probably the quick and 
+dirty way, env would be cleaner but take more code as you then have to 
+move it from env to handler opts.
+
+> My immediate application is to provide a secure RESTful API for a
+> network appliance.  Think securing the Web of Things.  I really do want
+> to get in the client's face if they don't have the right certificate.
+>
+> I'm late in saying this, but thank you for making Cowboy so easy to read
+> and understand.
+>
+> Cheers,
+> Dan.
+>
+>
+>
+> On Thu, Jun 5, 2014 at 4:24 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Misunderstood what you needed then.
+>
+>     Note that the services that are completely blocked from anyone who
+>     doesn't have the right cert are virtually non-existent, it doesn't
+>     make sense to add a feature for it.
+>
+>     You can do that kind of thing by having custom code creating the
+>     protocol process by the way. There's no need to patch Cowboy for that.
+>
+>
+>     On 06/05/2014 11:01 PM, Daniel Goertzen wrote:
+>
+>         But then I would have to check the client cert for each and every
+>         request.  I should have to check the cert only once at connect
+>         time and
+>         then be able to pass the result of that check in the request to each
+>         handler.
+>
+>         Anyway I've gone ahead and implemented what I need in a generic
+>         manner
+>         and it seems to work well.  I think it would be a useful addition to
+>         Cowboy.  If you agree I could write some more documentation for it.
+>
+>         https://github.com/__goertzenator/cowboy/tree/__onconnect
+>         <https://github.com/goertzenator/cowboy/tree/onconnect>
+>
+>         I added a "onconnect" hook and "connection metadata" to
+>         cowboy_req.  The
+>         connection metadata works like existing metadata, but is
+>         preserved from
+>         request to request on the same connection.  The onconnect hook
+>         provides
+>         initial values for the connection metadata.
+>
+>         Dan.
+>
+>
+>
+>
+>         On Thu, Jun 5, 2014 at 3:04 AM, Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>
+>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>
+>              On 06/05/2014 01:44 AM, Daniel Goertzen wrote:
+>
+>
+>
+>
+>                  On Wed, Jun 4, 2014 at 4:48 PM, Loïc Hoguin
+>         <essen at ninenines.eu <mailto:essen at ninenines.eu>
+>                  <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>
+>                  <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>
+>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>>> wrote:
+>
+>                       On 06/04/2014 10:08 PM, Daniel Goertzen wrote:
+>
+>                           I am having very good luck with Cowboy so far,
+>         but I
+>                  have some
+>                           questions:
+>
+>                           1. There doesn't appear to be any way to do client
+>                  certificate
+>                           authorization in Cowboy, although I see there
+>         is an
+>                  example for
+>                           doing
+>                           exactly that with Ranch.  I think I could
+>         modify Cowboy
+>                  to do what I
+>                           want, but I thought I would ask if there were
+>         other options
+>                           before doing
+>                           that.
+>
+>
+>                       Same as Ranch really, you just gotta take the
+>         socket and
+>                  then call
+>                       the ssl functions.
+>
+>
+>                  Yes, but in cowboy there's no API to get at the socket.
+>
+>
+>              There is the undocumented function cowboy_req:get/1 which
+>         is meant
+>              for that kind of "special" use.
+>
+>
+>              --
+>              Loïc Hoguin
+>         http://ninenines.eu
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000401.html b/_build/static/archives/extend/2014-June/000401.html new file mode 100644 index 00000000..352f86c2 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000401.html @@ -0,0 +1,101 @@ + + + + [99s-extend] [ANN] Cowboy and Ranch 0.10 + + + + + + + + + + +

[99s-extend] [ANN] Cowboy and Ranch 0.10

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jun 10 12:38:10 CEST 2014 +

+
+ +
Hello!
+
+I just pushed Cowboy 0.10 and Ranch 0.10.
+
+   https://github.com/extend/cowboy
+   https://github.com/extend/ranch
+
+The Cowboy changelog can be found here: 
+https://github.com/extend/cowboy/blob/master/CHANGELOG.md
+
+This release sees the addition of functions for reading multipart! (And 
+there are also functions for creating multipart bodies in the cowlib 
+library if you need them.) The old multipart interface got removed.
+
+The other big change is a rework of the body reading interface, again. 
+Users have reported having timeout issues sometimes so the new interface 
+allows you to configure read length/timeout so you can control the rate 
+of transfer *per body function call*.
+
+The functions init_stream, stream_body and skip_body have been 
+deprecated and will be removed in 1.0 (alongside one clause of the 
+body/2 and body_qs/2 functions).
+
+Current code *should* be compatible but you are really encouraged to 
+test and remove dead code introduced by this change.
+
+The changes in Ranch are mostly small so I won't bore you with the details.
+
+The next step will be to release 1.0 sometimes this summer. Work on 2.0 
+will start immediately after that but 2.0 is planned to be released 
+after Erlang 18.0 is out. We'll have a new version bump for every Erlang 
+version basically. More details later.
+
+Hope you enjoy this release, and that I didn't break your code (too much)!
+
+Enjoy.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000402.html b/_build/static/archives/extend/2014-June/000402.html new file mode 100644 index 00000000..e0dbcd16 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000402.html @@ -0,0 +1,77 @@ + + + + [99s-extend] Stop ranch listeners without dropping connections + + + + + + + + + + +

[99s-extend] Stop ranch listeners without dropping connections

+ Roger Lipscombe + roger at differentpla.net +
+ Wed Jun 11 14:38:59 CEST 2014 +

+
+ +
Using ranch, is there any way to stop the listener (and acceptors)
+without dropping the existing connections?
+
+I ask because I'd like to start another instance of my server on the
+same box and have the old instance continue to handle its existing
+connections for a while.
+
+It looks to me that if I call ranch:stop_listener, it'll kill the
+ranch_listener_sup, which will also kill the ranch_conns_sup (and the
+existing connections).
+
+If I manually do a supervisor:terminate_child(ListenerPid,
+ranch_acceptors_sup), the acceptors go away, but the socket is still
+open, which means that I can't start another instance of my server.
+
+Thoughts?
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000403.html b/_build/static/archives/extend/2014-June/000403.html new file mode 100644 index 00000000..9ce8747a --- /dev/null +++ b/_build/static/archives/extend/2014-June/000403.html @@ -0,0 +1,89 @@ + + + + [99s-extend] Stop ranch listeners without dropping connections + + + + + + + + + + +

[99s-extend] Stop ranch listeners without dropping connections

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Jun 23 13:36:50 CEST 2014 +

+
+ +
It is not possible at this point. Please open a ticket.
+
+On 06/11/2014 02:38 PM, Roger Lipscombe wrote:
+> Using ranch, is there any way to stop the listener (and acceptors)
+> without dropping the existing connections?
+>
+> I ask because I'd like to start another instance of my server on the
+> same box and have the old instance continue to handle its existing
+> connections for a while.
+>
+> It looks to me that if I call ranch:stop_listener, it'll kill the
+> ranch_listener_sup, which will also kill the ranch_conns_sup (and the
+> existing connections).
+>
+> If I manually do a supervisor:terminate_child(ListenerPid,
+> ranch_acceptors_sup), the acceptors go away, but the socket is still
+> open, which means that I can't start another instance of my server.
+>
+> Thoughts?
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/000404.html b/_build/static/archives/extend/2014-June/000404.html new file mode 100644 index 00000000..c07fc989 --- /dev/null +++ b/_build/static/archives/extend/2014-June/000404.html @@ -0,0 +1,91 @@ + + + + [99s-extend] Stop ranch listeners without dropping connections + + + + + + + + + + +

[99s-extend] Stop ranch listeners without dropping connections

+ Roger Lipscombe + roger at differentpla.net +
+ Mon Jun 23 15:55:47 CEST 2014 +

+
+ +
Done: https://github.com/extend/ranch/issues/83
+
+On 23 June 2014 12:36, Loïc Hoguin <essen at ninenines.eu> wrote:
+> It is not possible at this point. Please open a ticket.
+>
+>
+> On 06/11/2014 02:38 PM, Roger Lipscombe wrote:
+>>
+>> Using ranch, is there any way to stop the listener (and acceptors)
+>> without dropping the existing connections?
+>>
+>> I ask because I'd like to start another instance of my server on the
+>> same box and have the old instance continue to handle its existing
+>> connections for a while.
+>>
+>> It looks to me that if I call ranch:stop_listener, it'll kill the
+>> ranch_listener_sup, which will also kill the ranch_conns_sup (and the
+>> existing connections).
+>>
+>> If I manually do a supervisor:terminate_child(ListenerPid,
+>> ranch_acceptors_sup), the acceptors go away, but the socket is still
+>> open, which means that I can't start another instance of my server.
+>>
+>> Thoughts?
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-June/author.html b/_build/static/archives/extend/2014-June/author.html new file mode 100644 index 00000000..bb06272f --- /dev/null +++ b/_build/static/archives/extend/2014-June/author.html @@ -0,0 +1,122 @@ + + + + The Extend June 2014 Archive by author + + + + + +

June 2014 Archives by author

+ +

Starting: Wed Jun 4 22:08:54 CEST 2014
+ Ending: Mon Jun 23 15:55:47 CEST 2014
+ Messages: 15

+

+

+ Last message date: + Mon Jun 23 15:55:47 CEST 2014
+ Archived on: Mon Jun 23 15:55:49 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-June/date.html b/_build/static/archives/extend/2014-June/date.html new file mode 100644 index 00000000..6af7d531 --- /dev/null +++ b/_build/static/archives/extend/2014-June/date.html @@ -0,0 +1,122 @@ + + + + The Extend June 2014 Archive by date + + + + + +

June 2014 Archives by date

+ +

Starting: Wed Jun 4 22:08:54 CEST 2014
+ Ending: Mon Jun 23 15:55:47 CEST 2014
+ Messages: 15

+

+

+ Last message date: + Mon Jun 23 15:55:47 CEST 2014
+ Archived on: Mon Jun 23 15:55:49 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-June/index.html b/_build/static/archives/extend/2014-June/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-June/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-June/subject.html b/_build/static/archives/extend/2014-June/subject.html new file mode 100644 index 00000000..c6fa9670 --- /dev/null +++ b/_build/static/archives/extend/2014-June/subject.html @@ -0,0 +1,122 @@ + + + + The Extend June 2014 Archive by subject + + + + + +

June 2014 Archives by subject

+ +

Starting: Wed Jun 4 22:08:54 CEST 2014
+ Ending: Mon Jun 23 15:55:47 CEST 2014
+ Messages: 15

+

+

+ Last message date: + Mon Jun 23 15:55:47 CEST 2014
+ Archived on: Mon Jun 23 15:55:49 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-June/thread.html b/_build/static/archives/extend/2014-June/thread.html new file mode 100644 index 00000000..a4e02007 --- /dev/null +++ b/_build/static/archives/extend/2014-June/thread.html @@ -0,0 +1,151 @@ + + + + The Extend June 2014 Archive by thread + + + + + +

June 2014 Archives by thread

+ +

Starting: Wed Jun 4 22:08:54 CEST 2014
+ Ending: Mon Jun 23 15:55:47 CEST 2014
+ Messages: 15

+

+

+ Last message date: + Mon Jun 23 15:55:47 CEST 2014
+ Archived on: Mon Jun 23 15:55:49 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-March.txt b/_build/static/archives/extend/2014-March.txt new file mode 100644 index 00000000..f510662a --- /dev/null +++ b/_build/static/archives/extend/2014-March.txt @@ -0,0 +1,1740 @@ +From psihonavt at gmail.com Mon Mar 3 21:49:33 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Mon, 3 Mar 2014 22:49:33 +0200 +Subject: [99s-extend] usage of make_* command +Message-ID: + +Hello, + +I have next structure of my project: +. +??? deps +? ??? cowboy +? ??? cowlib +? ??? erlang_iconv +? ??? erlydtl +? ??? mochiweb_xpath +? ??? ranch +??? ebin +? ??? fetchers.beam +? ??? parsers.beam +? ??? wasearch_sup.beam +??? erlang.mk +??? Makefile +??? _rel +? ??? .... +??? relx +??? relx.config +??? src +? ??? fetchers.erl +? ??? main_handler.erl +? ??? parsers.erl +? ??? tests +? ? ??? parsers_SUITE_data +? ? ??? parsers_SUITE.erl +? ? ??? .... +? ??? wasearch_app.erl +? ??? wasearch.app.src +? ??? wasearch_sup.erl +??? templates + ??? index.dtl + +I would prefer to store tests not in `src` directory but rather in `tests` +subdirectory. +Erlang.mk README says: You can run an individual test suite by using the +special test_* targets. For example if you have a common_test suite named +spdy and you want to run only this suite and not the others, you can use +the make test_spdy command. +And of course `make test_parsers` returns `no rule to make target` error. +Is there a way to run suites from custom directory with +`make_` command? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mark.nijhof at cre8ivethought.com Thu Mar 6 00:47:08 2014 +From: mark.nijhof at cre8ivethought.com (Mark Nijhof) +Date: Thu, 6 Mar 2014 00:47:08 +0100 +Subject: [99s-extend] Cowboy pre request filter +Message-ID: + +Hi, + +I want to create a module that basically sits between the incoming request +and the http handler for that request to ensure a request is authenticated +(using a cookie), if the request is not authenticated then I like to +redirect to a specific login page (which should not be filtered). + +Is this possible with Cowboy? Should I use the onrequest hook (not sure if +I can force redirects from there) for that or is there a better way? + +Cheers, + +-Mark + +-- +Mark Nijhof +t: @MarkNijhof +s: marknijhof +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From mark.nijhof at cre8ivethought.com Thu Mar 6 10:52:01 2014 +From: mark.nijhof at cre8ivethought.com (Mark Nijhof) +Date: Thu, 6 Mar 2014 10:52:01 +0100 +Subject: [99s-extend] Cowboy pre request filter +In-Reply-To: +References: +Message-ID: + +I also found the answer to my own question: custom middleware + +I just created: + + 1 -module(authentication_middleware). + 2 + 3 -behaviour(cowboy_middleware). + 4 + 5 -export([execute/2]). + 6 + 7 execute(Req, Env) -> + 8 + 9 {Path, Req1} = cowboy_req:path(Req), + 10 + 11 case Path of + 12 <<"/login.html">> -> + 13 {ok, Req1, Env}; + 14 <<"/do_login">> -> + 15 {ok, Req1, Env}; + 16 _ -> + 17 case id3as_security:is_request_authenticated(Req1) of + 18 {error, eauth, Req2} -> + 19 {ok, Req4} = cowboy_req:reply(303, +[{<<"Location">>, <<"/login.html">>}], "", Req2), + 20 {halt, Req4}; + 21 {authenticated, _Id, Req2} -> + 22 {ok, Req2, Env} + 23 end + 24 end. + +And put this between the cowboy_router and cowboy_handler and life is all +good. + +-Mark + + + +On Thu, Mar 6, 2014 at 12:47 AM, Mark Nijhof wrote: + +> Hi, +> +> I want to create a module that basically sits between the incoming request +> and the http handler for that request to ensure a request is authenticated +> (using a cookie), if the request is not authenticated then I like to +> redirect to a specific login page (which should not be filtered). +> +> Is this possible with Cowboy? Should I use the onrequest hook (not sure if +> I can force redirects from there) for that or is there a better way? +> +> Cheers, +> +> -Mark +> +> -- +> Mark Nijhof +> t: @MarkNijhof +> s: marknijhof +> +> + + +-- +Mark Nijhof +t: @MarkNijhof +s: marknijhof +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Mar 6 15:40:59 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 06 Mar 2014 15:40:59 +0100 +Subject: [99s-extend] usage of make_* command +In-Reply-To: +References: +Message-ID: <531888FB.1020500@ninenines.eu> + +Tests should be in ./tests, not ./src/tests. + +If you put them in ./tests everything you mentioned will work. + +On 03/03/2014 09:49 PM, Anton Koval' wrote: +> Hello, +> +> I have next structure of my project: +> . +> ??? deps +> ? ??? cowboy +> ? ??? cowlib +> ? ??? erlang_iconv +> ? ??? erlydtl +> ? ??? mochiweb_xpath +> ? ??? ranch +> ??? ebin +> ? ??? fetchers.beam +> ? ??? parsers.beam +> ? ??? wasearch_sup.beam +> ??? erlang.mk +> ??? Makefile +> ??? _rel +> ? ??? .... +> ??? relx +> ??? relx.config +> ??? src +> ? ??? fetchers.erl +> ? ??? main_handler.erl +> ? ??? parsers.erl +> ? ??? tests +> ? ? ??? parsers_SUITE_data +> ? ? ??? parsers_SUITE.erl +> ? ? ??? .... +> ? ??? wasearch_app.erl +> ? ??? wasearch.app.src +> ? ??? wasearch_sup.erl +> ??? templates +> ??? index.dtl +> +> I would prefer to store tests not in `src` directory but rather in +> `tests` subdirectory. +> Erlang.mk README says: You can run an individual test suite by using the +> special |test_*| targets. For example if you have a common_test suite +> named |spdy| and you want to run only this suite and not the others, you +> can use the |make test_spdy| command. +> And of course `make test_parsers` returns `no rule to make target` error. +> Is there a way to run suites from custom directory with +> `make_` command? +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From psihonavt at gmail.com Thu Mar 6 15:50:01 2014 +From: psihonavt at gmail.com (Anton Koval') +Date: Thu, 6 Mar 2014 16:50:01 +0200 +Subject: [99s-extend] usage of make_* command +In-Reply-To: <531888FB.1020500@ninenines.eu> +References: + <531888FB.1020500@ninenines.eu> +Message-ID: + +Thank you for answer. +Is it common way (for OTP-based application) to store tests in `tests` +subdirectory rather then in `src/tests/`? + + +On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin wrote: + +> Tests should be in ./tests, not ./src/tests. +> +> If you put them in ./tests everything you mentioned will work. +> +> +> On 03/03/2014 09:49 PM, Anton Koval' wrote: +> +>> Hello, +>> +>> I have next structure of my project: +>> . +>> ??? deps +>> ? ??? cowboy +>> ? ??? cowlib +>> ? ??? erlang_iconv +>> ? ??? erlydtl +>> ? ??? mochiweb_xpath +>> ? ??? ranch +>> ??? ebin +>> ? ??? fetchers.beam +>> ? ??? parsers.beam +>> ? ??? wasearch_sup.beam +>> ??? erlang.mk +>> +>> ??? Makefile +>> ??? _rel +>> ? ??? .... +>> ??? relx +>> ??? relx.config +>> ??? src +>> ? ??? fetchers.erl +>> ? ??? main_handler.erl +>> ? ??? parsers.erl +>> ? ??? tests +>> ? ? ??? parsers_SUITE_data +>> ? ? ??? parsers_SUITE.erl +>> ? ? ??? .... +>> ? ??? wasearch_app.erl +>> ? ??? wasearch.app.src +>> ? ??? wasearch_sup.erl +>> ??? templates +>> ??? index.dtl +>> +>> I would prefer to store tests not in `src` directory but rather in +>> `tests` subdirectory. +>> Erlang.mk README says: You can run an individual test suite by using the +>> special |test_*| targets. For example if you have a common_test suite +>> named |spdy| and you want to run only this suite and not the others, you +>> can use the |make test_spdy| command. +>> And of course `make test_parsers` returns `no rule to make target` error. +>> Is there a way to run suites from custom directory with +>> `make_` command? +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Mar 6 15:51:58 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 06 Mar 2014 15:51:58 +0100 +Subject: [99s-extend] usage of make_* command +In-Reply-To: +References: <531888FB.1020500@ninenines.eu> + +Message-ID: <53188B8E.5010803@ninenines.eu> + +Sorry I meant ./test/ not ./tests/ + +But yes. That's how OTP does it. + +On 03/06/2014 03:50 PM, Anton Koval' wrote: +> Thank you for answer. +> Is it common way (for OTP-based application) to store tests in `tests` +> subdirectory rather then in `src/tests/`? +> +> +> On Thu, Mar 6, 2014 at 4:40 PM, Lo?c Hoguin > wrote: +> +> Tests should be in ./tests, not ./src/tests. +> +> If you put them in ./tests everything you mentioned will work. +> +> +> On 03/03/2014 09:49 PM, Anton Koval' wrote: +> +> Hello, +> +> I have next structure of my project: +> . +> ??? deps +> ? ??? cowboy +> ? ??? cowlib +> ? ??? erlang_iconv +> ? ??? erlydtl +> ? ??? mochiweb_xpath +> ? ??? ranch +> ??? ebin +> ? ??? fetchers.beam +> ? ??? parsers.beam +> ? ??? wasearch_sup.beam +> ??? erlang.mk +> +> ??? Makefile +> ??? _rel +> ? ??? .... +> ??? relx +> ??? relx.config +> ??? src +> ? ??? fetchers.erl +> ? ??? main_handler.erl +> ? ??? parsers.erl +> ? ??? tests +> ? ? ??? parsers_SUITE_data +> ? ? ??? parsers_SUITE.erl +> ? ? ??? .... +> ? ??? wasearch_app.erl +> ? ??? wasearch.app.src +> ? ??? wasearch_sup.erl +> ??? templates +> ??? index.dtl +> +> I would prefer to store tests not in `src` directory but rather in +> `tests` subdirectory. +> Erlang.mk README says: You can run an individual test suite by +> using the +> special |test_*| targets. For example if you have a common_test +> suite +> named |spdy| and you want to run only this suite and not the +> others, you +> can use the |make test_spdy| command. +> And of course `make test_parsers` returns `no rule to make +> target` error. +> Is there a way to run suites from custom directory with +> `make_` command? +> +> +> _________________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/__listinfo/extend +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Thu Mar 6 21:29:59 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Thu, 6 Mar 2014 15:29:59 -0500 (EST) +Subject: [99s-extend] Trying to grok erlang.mk +Message-ID: <1394137799.268930068@apps.rackspace.com> + +Hello, + +To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this: + +min + erlang.mk + Makefile + src + min.app.src + min.erl + +*** Where Makefile is: + +PROJECT = min + +include erlang.mk + +*** min.app.src is: + +{application, min, + [{description,[]}, + {vsn,"0.1.0"}, + {registered,[]}, + {applications,[kernel,stdlib]}, + {env,[]}, + {modules,[]}]}. + +*** and min.erl is: + +-module(min). + +-export([hello/0]). + +hello() -> + io:format("Hello min!~n~n"). + +*** But when I call make, I get this: + +/min$ make + ERLC min.erl + APP min .app.src +cat: src/min: No such file or directory +cat: .app.src: No such file or directory +sed: can't read .app: No such file or directory +make: *** [app] Error 2 + +*** Observations + +min.erl compiles just fine +min.app.src breaks the compile + +*** Questions: + +1) How can I correct this? +2) How can I structure directories and make files for a project that involves several applications? + +Many thanks, + +LRP + + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From ivan at llaisdy.com Fri Mar 7 13:37:27 2014 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Fri, 07 Mar 2014 12:37:27 +0000 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <1394137799.268930068@apps.rackspace.com> +References: <1394137799.268930068@apps.rackspace.com> +Message-ID: <5319BD87.2020109@llaisdy.com> + +Dear Lloyd + +I've just tried this with file layout and contents copied from your +email, and make works fine here I'm afraid. + +One odd thing I noticed in your make output ... + + > /min$ make + > ERLC min.erl + > APP min .app.src + > cat: src/min: No such file or directory + > cat: .app.src: No such file or directory + > sed: can't read .app: No such file or directory + > make: *** [app] Error 2 + +... is that in the APP line, the filename min.app.src has a space in it, +and it looks (in the cat lines) like it's broken down into src/min and +.app.src (ie ./.app.src). I can't imagine why that's happening, but +that's what's causing the problem I should think. + + > 2) How can I structure directories and make files for a project + > that involves several applications? + +I don't know if it's the "correct" way with erlang.mk but, as a refugee +from rebar, I have apps set out rebar-style and use old-school recursive +make. e.g.: + +max/ + erlang.mk + Makefile + apps/ + app1/ + Makefile + src/ + app2/ + Makefile + src/ + +Top level Makefile doesn't need to include erlang.mk, and has lines like: + +all: + $(MAKE) -C apps/app1 + $(MAKE) -C apps/app2 + +Lower level Makefiles include erlang.mk. + +Best wishes + +Ivan + + +On 06/03/2014 20:29, lloyd at writersglen.com wrote: +> Hello, +> +> To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this: +> +> min +> erlang.mk +> Makefile +> src +> min.app.src +> min.erl +> +> *** Where Makefile is: +> +> PROJECT = min +> +> include erlang.mk +> +> *** min.app.src is: +> +> {application, min, +> [{description,[]}, +> {vsn,"0.1.0"}, +> {registered,[]}, +> {applications,[kernel,stdlib]}, +> {env,[]}, +> {modules,[]}]}. +> +> *** and min.erl is: +> +> -module(min). +> +> -export([hello/0]). +> +> hello() -> +> io:format("Hello min!~n~n"). +> +> *** But when I call make, I get this: +> +> /min$ make +> ERLC min.erl +> APP min .app.src +> cat: src/min: No such file or directory +> cat: .app.src: No such file or directory +> sed: can't read .app: No such file or directory +> make: *** [app] Error 2 +> +> *** Observations +> +> min.erl compiles just fine +> min.app.src breaks the compile +> +> *** Questions: +> +> 1) How can I correct this? +> 2) How can I structure directories and make files for a project that involves several applications? +> +> Many thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From essen at ninenines.eu Fri Mar 7 17:56:01 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 07 Mar 2014 17:56:01 +0100 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <1394137799.268930068@apps.rackspace.com> +References: <1394137799.268930068@apps.rackspace.com> +Message-ID: <5319FA21.7090603@ninenines.eu> + +On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote: +> PROJECT = min + +You probably have an extra space at the end here, and erlang.mk doesn't +trim them I guess. Please open a ticket! + +-- +Lo?c Hoguin +http://ninenines.eu + + +From ivan at llaisdy.com Fri Mar 7 17:58:40 2014 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Fri, 07 Mar 2014 16:58:40 +0000 +Subject: [99s-extend] Trying to grok erlang.mk +In-Reply-To: <5319FA21.7090603@ninenines.eu> +References: <1394137799.268930068@apps.rackspace.com> + <5319FA21.7090603@ninenines.eu> +Message-ID: <5319FAC0.6090807@llaisdy.com> + +Yes, that's it! I've just tried it. + +Good old make :) + +On 07/03/2014 16:56, Lo?c Hoguin wrote: +> On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote: +>> PROJECT = min +> +> You probably have an extra space at the end here, and erlang.mk doesn't +> trim them I guess. Please open a ticket! +> + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + www.llaisdy.com + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From lloyd at writersglen.com Mon Mar 10 20:44:27 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Mon, 10 Mar 2014 15:44:27 -0400 (EDT) +Subject: [99s-extend] =?utf-8?q?Getting_started_error=3A___behaviour_cowbo?= + =?utf-8?q?y=5Fhttp=5Fhandler_undefined?= +Message-ID: <1394480667.69797138@apps.rackspace.com> + +Hello, + +I've slavishly emulated the "Getting started" example in the guide: + +http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ + +But, when I compile I get this error: + +yada yada + ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +compile: warnings being treated as errors +src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +make: *** [ebin/hello_erlang.app] Error 1 + +Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam + +However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. + +% -behavior(cowboy_http_handler). + +Could this be a bug in Getting started or some dunder-headed thing on my end? + +Thanks, + +LRP + + +********************************************* +My books: + +THE GOSPEL OF ASHES +http://thegospelofashes.com + +Strength is not enough. Do they have the courage +and the cunning? Can they survive long enough to +save the lives of millions? + +FREEIN' PANCHO +http://freeinpancho.com + +A community of misfits help a troubled boy find his way + +AYA TAKEO +http://ayatakeo.com + +Star-crossed love, war and power in an alternative +universe + +Available through Amazon or by request from your +favorite bookstore + + +********************************************** + + + +From essen at ninenines.eu Mon Mar 10 21:36:22 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 10 Mar 2014 21:36:22 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <1394480667.69797138@apps.rackspace.com> +References: <1394480667.69797138@apps.rackspace.com> +Message-ID: <531E2246.7040307@ninenines.eu> + +Try updating Erlang or Cowboy, this isn't the first time this happens +and I fixed something at some point. + +Also see if you have ERL_LIBS already defined, in which case there might +be a bug in Cowboy. + +On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +> Hello, +> +> I've slavishly emulated the "Getting started" example in the guide: +> +> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +> +> But, when I compile I get this error: +> +> yada yada +> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +> compile: warnings being treated as errors +> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +> make: *** [ebin/hello_erlang.app] Error 1 +> +> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +> +> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +> +> % -behavior(cowboy_http_handler). +> +> Could this be a bug in Getting started or some dunder-headed thing on my end? +> +> Thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Wed Mar 12 23:51:04 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Wed, 12 Mar 2014 18:51:04 -0400 (EDT) +Subject: [99s-extend] + =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?= + =?utf-8?q?=5Fhttp=5Fhandler_undefined?= +In-Reply-To: <531E2246.7040307@ninenines.eu> +References: <1394480667.69797138@apps.rackspace.com> + <531E2246.7040307@ninenines.eu> +Message-ID: <1394664664.82233997@apps.rackspace.com> + +Hi Lo?c, + +Thanks for help. + +I'm running cowboy master from GitHub and Erlang R16B02. + +$ echo $ERL_LIBS + +...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. + +E.g.: /home/lloyd/Programming/Erlang/zippity/apps + +I've looked in .erlang and tried $ export ERL_LIBS=. + +Thanks again, + +LRP + +-----Original Message----- +From: "Lo?c Hoguin" +Sent: Monday, March 10, 2014 4:36pm +To: lloyd at writersglen.com, extend at lists.ninenines.eu +Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + +Try updating Erlang or Cowboy, this isn't the first time this happens +and I fixed something at some point. + +Also see if you have ERL_LIBS already defined, in which case there might +be a bug in Cowboy. + +On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +> Hello, +> +> I've slavishly emulated the "Getting started" example in the guide: +> +> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +> +> But, when I compile I get this error: +> +> yada yada +> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +> compile: warnings being treated as errors +> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +> make: *** [ebin/hello_erlang.app] Error 1 +> +> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +> +> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +> +> % -behavior(cowboy_http_handler). +> +> Could this be a bug in Getting started or some dunder-headed thing on my end? +> +> Thanks, +> +> LRP +> +> +> ********************************************* +> My books: +> +> THE GOSPEL OF ASHES +> http://thegospelofashes.com +> +> Strength is not enough. Do they have the courage +> and the cunning? Can they survive long enough to +> save the lives of millions? +> +> FREEIN' PANCHO +> http://freeinpancho.com +> +> A community of misfits help a troubled boy find his way +> +> AYA TAKEO +> http://ayatakeo.com +> +> Star-crossed love, war and power in an alternative +> universe +> +> Available through Amazon or by request from your +> favorite bookstore +> +> +> ********************************************** +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + + + +From essen at ninenines.eu Wed Mar 12 23:57:16 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 12 Mar 2014 23:57:16 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <1394664664.82233997@apps.rackspace.com> +References: <1394480667.69797138@apps.rackspace.com> + <531E2246.7040307@ninenines.eu> <1394664664.82233997@apps.rackspace.com> +Message-ID: <5320E64C.7010000@ninenines.eu> + +Can you try again after running "unset ERL_LIBS"? + +On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +> Hi Lo?c, +> +> Thanks for help. +> +> I'm running cowboy master from GitHub and Erlang R16B02. +> +> $ echo $ERL_LIBS +> +> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +> +> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +> +> I've looked in .erlang and tried $ export ERL_LIBS=. +> +> Thanks again, +> +> LRP +> +> -----Original Message----- +> From: "Lo?c Hoguin" +> Sent: Monday, March 10, 2014 4:36pm +> To: lloyd at writersglen.com, extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Try updating Erlang or Cowboy, this isn't the first time this happens +> and I fixed something at some point. +> +> Also see if you have ERL_LIBS already defined, in which case there might +> be a bug in Cowboy. +> +> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>> Hello, +>> +>> I've slavishly emulated the "Getting started" example in the guide: +>> +>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>> +>> But, when I compile I get this error: +>> +>> yada yada +>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>> compile: warnings being treated as errors +>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>> make: *** [ebin/hello_erlang.app] Error 1 +>> +>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>> +>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>> +>> % -behavior(cowboy_http_handler). +>> +>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>> +>> Thanks, +>> +>> LRP +>> +>> +>> ********************************************* +>> My books: +>> +>> THE GOSPEL OF ASHES +>> http://thegospelofashes.com +>> +>> Strength is not enough. Do they have the courage +>> and the cunning? Can they survive long enough to +>> save the lives of millions? +>> +>> FREEIN' PANCHO +>> http://freeinpancho.com +>> +>> A community of misfits help a troubled boy find his way +>> +>> AYA TAKEO +>> http://ayatakeo.com +>> +>> Star-crossed love, war and power in an alternative +>> universe +>> +>> Available through Amazon or by request from your +>> favorite bookstore +>> +>> +>> ********************************************** +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From lloyd at writersglen.com Thu Mar 13 00:43:16 2014 +From: lloyd at writersglen.com (lloyd at writersglen.com) +Date: Wed, 12 Mar 2014 19:43:16 -0400 (EDT) +Subject: [99s-extend] + =?utf-8?q?Getting_started_error=3A_behaviour_cowboy?= + =?utf-8?q?=5Fhttp=5Fhandler_undefined?= +In-Reply-To: <5320E64C.7010000@ninenines.eu> +References: <1394480667.69797138@apps.rackspace.com> + <531E2246.7040307@ninenines.eu> + <1394664664.82233997@apps.rackspace.com> <5320E64C.7010000@ninenines.eu> +Message-ID: <1394667796.517915192@apps.rackspace.com> + +Hi, + +That fixed it! + +But where can I go to understand why and prevent it in future? + +I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system? + +Many thanks! + +Lloyd + +-----Original Message----- +From: "Lo?c Hoguin" +Sent: Wednesday, March 12, 2014 6:57pm +To: lloyd at writersglen.com +Cc: extend at lists.ninenines.eu +Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + +Can you try again after running "unset ERL_LIBS"? + +On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +> Hi Lo?c, +> +> Thanks for help. +> +> I'm running cowboy master from GitHub and Erlang R16B02. +> +> $ echo $ERL_LIBS +> +> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +> +> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +> +> I've looked in .erlang and tried $ export ERL_LIBS=. +> +> Thanks again, +> +> LRP +> +> -----Original Message----- +> From: "Lo?c Hoguin" +> Sent: Monday, March 10, 2014 4:36pm +> To: lloyd at writersglen.com, extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Try updating Erlang or Cowboy, this isn't the first time this happens +> and I fixed something at some point. +> +> Also see if you have ERL_LIBS already defined, in which case there might +> be a bug in Cowboy. +> +> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>> Hello, +>> +>> I've slavishly emulated the "Getting started" example in the guide: +>> +>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>> +>> But, when I compile I get this error: +>> +>> yada yada +>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>> compile: warnings being treated as errors +>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>> make: *** [ebin/hello_erlang.app] Error 1 +>> +>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>> +>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>> +>> % -behavior(cowboy_http_handler). +>> +>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>> +>> Thanks, +>> +>> LRP +>> +>> +>> ********************************************* +>> My books: +>> +>> THE GOSPEL OF ASHES +>> http://thegospelofashes.com +>> +>> Strength is not enough. Do they have the courage +>> and the cunning? Can they survive long enough to +>> save the lives of millions? +>> +>> FREEIN' PANCHO +>> http://freeinpancho.com +>> +>> A community of misfits help a troubled boy find his way +>> +>> AYA TAKEO +>> http://ayatakeo.com +>> +>> Star-crossed love, war and power in an alternative +>> universe +>> +>> Available through Amazon or by request from your +>> favorite bookstore +>> +>> +>> ********************************************** +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + + + +From essen at ninenines.eu Thu Mar 13 00:46:57 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 13 Mar 2014 00:46:57 +0100 +Subject: [99s-extend] Getting started error: behaviour + cowboy_http_handler undefined +In-Reply-To: <1394667796.517915192@apps.rackspace.com> +References: <1394480667.69797138@apps.rackspace.com> + <531E2246.7040307@ninenines.eu> <1394664664.82233997@apps.rackspace.com> + <5320E64C.7010000@ninenines.eu> <1394667796.517915192@apps.rackspace.com> +Message-ID: <5320F1F1.9000506@ninenines.eu> + +It's explained here: http://www.erlang.org/doc/man/code.html + +I am not sure why it caused issues on your system, possibly Erlang +ignored it because there was an invalid folder in there. I don't really +know. + +On 03/13/2014 12:43 AM, lloyd at writersglen.com wrote: +> Hi, +> +> That fixed it! +> +> But where can I go to understand why and prevent it in future? +> +> I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system? +> +> Many thanks! +> +> Lloyd +> +> -----Original Message----- +> From: "Lo?c Hoguin" +> Sent: Wednesday, March 12, 2014 6:57pm +> To: lloyd at writersglen.com +> Cc: extend at lists.ninenines.eu +> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +> +> Can you try again after running "unset ERL_LIBS"? +> +> On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote: +>> Hi Lo?c, +>> +>> Thanks for help. +>> +>> I'm running cowboy master from GitHub and Erlang R16B02. +>> +>> $ echo $ERL_LIBS +>> +>> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it. +>> +>> E.g.: /home/lloyd/Programming/Erlang/zippity/apps +>> +>> I've looked in .erlang and tried $ export ERL_LIBS=. +>> +>> Thanks again, +>> +>> LRP +>> +>> -----Original Message----- +>> From: "Lo?c Hoguin" +>> Sent: Monday, March 10, 2014 4:36pm +>> To: lloyd at writersglen.com, extend at lists.ninenines.eu +>> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined +>> +>> Try updating Erlang or Cowboy, this isn't the first time this happens +>> and I fixed something at some point. +>> +>> Also see if you have ERL_LIBS already defined, in which case there might +>> be a bug in Cowboy. +>> +>> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote: +>>> Hello, +>>> +>>> I've slavishly emulated the "Getting started" example in the guide: +>>> +>>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/ +>>> +>>> But, when I compile I get this error: +>>> +>>> yada yada +>>> ERLC hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl +>>> compile: warnings being treated as errors +>>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined +>>> make: *** [ebin/hello_erlang.app] Error 1 +>>> +>>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam +>>> +>>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine. +>>> +>>> % -behavior(cowboy_http_handler). +>>> +>>> Could this be a bug in Getting started or some dunder-headed thing on my end? +>>> +>>> Thanks, +>>> +>>> LRP +>>> +>>> +>>> ********************************************* +>>> My books: +>>> +>>> THE GOSPEL OF ASHES +>>> http://thegospelofashes.com +>>> +>>> Strength is not enough. Do they have the courage +>>> and the cunning? Can they survive long enough to +>>> save the lives of millions? +>>> +>>> FREEIN' PANCHO +>>> http://freeinpancho.com +>>> +>>> A community of misfits help a troubled boy find his way +>>> +>>> AYA TAKEO +>>> http://ayatakeo.com +>>> +>>> Star-crossed love, war and power in an alternative +>>> universe +>>> +>>> Available through Amazon or by request from your +>>> favorite bookstore +>>> +>>> +>>> ********************************************** +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From joshua.mcquistan at mcq.io Thu Mar 13 02:41:12 2014 +From: joshua.mcquistan at mcq.io (Joshua McQuistan) +Date: Thu, 13 Mar 2014 01:41:12 +0000 +Subject: [99s-extend] Updating Cowboy applications +Message-ID: <53210CB8.5080109@mcq.io> + +Hello all, + +I have written a Cowboy application that works fine over localhost. I'm +now looking at ways of deploying and updating it i.e., moving from dev +to prod in a nice manner. + +I have dug around the archives and have found that Cowboy does not +support hot code reloading meaning either a restart of the vm or playing +with code:reload_file is necessary. + +The latter suggests a possible rewriting of OTP's code loading mechanism +and seems like it might be sensible to avoid. + +The other approach then is a restart. In previous (non-Cowboy) set ups +I've used nginx on port 80 / 443 that talks to the web app via a unix +socket (e.g., "web/socket"). When updating I'll start a new instance on +a new socket (e.g., "web/socket.new") then rely on the file system's +"mv" to switch it to "web/socket"; this works because the underlying +file system guarantees mv to be atomic (or at least to never see a +missing file). I can then ask the old process to shut down nicely in the +background. + +For this to work it would require Cowby / Ranch to be able to listen on +unix sockets. A glance at the documentation suggests that unix sockets +aren't available, is this the case? What's the feasibility of it getting +added? + +It might just be simpler to load-balance across multiple servers and +safely take them out one at a time while updating. + +My other question is, how do others approach this problem? Did I miss +something vitally obvious? + +Regards, +Joshua + + +From essen at ninenines.eu Thu Mar 13 14:22:03 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 13 Mar 2014 14:22:03 +0100 +Subject: [99s-extend] Updating Cowboy applications +In-Reply-To: <53210CB8.5080109@mcq.io> +References: <53210CB8.5080109@mcq.io> +Message-ID: <5321B0FB.4060203@ninenines.eu> + +Deploying is easy: releases. + +The "getting started" chapter of the guide, and all the examples use +that and it should be pretty easy to do. + +You can reload Cowboy modules directly using l(module). You can reload +most Ranch modules too but some of them will require using sys. Ranch +will get support for upgrades as soon as I finish the upgrade test +suite, but it's still low priority. + +And upgrade of Cowboy processes can only be added after we make them +special processes, which is still a way to go. + +There is no plans for supporting unix sockets for the simple reason that +it is not portable. On the other hand, if you use a separate library to +open a socket and give it to Ranch (socket option), possibly writing a +specific transport module for it, then it's very possible that you can +use unix sockets (and if it works, please do send feedback). + +On 03/13/2014 02:41 AM, Joshua McQuistan wrote: +> Hello all, +> +> I have written a Cowboy application that works fine over localhost. I'm +> now looking at ways of deploying and updating it i.e., moving from dev +> to prod in a nice manner. +> +> I have dug around the archives and have found that Cowboy does not +> support hot code reloading meaning either a restart of the vm or playing +> with code:reload_file is necessary. +> +> The latter suggests a possible rewriting of OTP's code loading mechanism +> and seems like it might be sensible to avoid. +> +> The other approach then is a restart. In previous (non-Cowboy) set ups +> I've used nginx on port 80 / 443 that talks to the web app via a unix +> socket (e.g., "web/socket"). When updating I'll start a new instance on +> a new socket (e.g., "web/socket.new") then rely on the file system's +> "mv" to switch it to "web/socket"; this works because the underlying +> file system guarantees mv to be atomic (or at least to never see a +> missing file). I can then ask the old process to shut down nicely in the +> background. +> +> For this to work it would require Cowby / Ranch to be able to listen on +> unix sockets. A glance at the documentation suggests that unix sockets +> aren't available, is this the case? What's the feasibility of it getting +> added? +> +> It might just be simpler to load-balance across multiple servers and +> safely take them out one at a time while updating. +> +> My other question is, how do others approach this problem? Did I miss +> something vitally obvious? +> +> Regards, +> Joshua +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From joshua.mcquistan at mcq.io Thu Mar 13 15:23:09 2014 +From: joshua.mcquistan at mcq.io (Joshua McQuistan) +Date: Thu, 13 Mar 2014 14:23:09 +0000 +Subject: [99s-extend] Updating Cowboy applications +In-Reply-To: <5321B0FB.4060203@ninenines.eu> +References: <53210CB8.5080109@mcq.io> <5321B0FB.4060203@ninenines.eu> +Message-ID: <5321BF4D.50102@mcq.io> + +> +> I wish I knew enough to answer your question. But I do hope you publish a tutorial documenting your solution for those following you down the trail. + +Will do. + +On 13/03/14 13:22, Lo?c Hoguin wrote: +> +> There is no plans for supporting unix sockets for the simple reason that +> it is not portable. On the other hand, if you use a separate library to +> open a socket and give it to Ranch (socket option), possibly writing a +> specific transport module for it, then it's very possible that you can +> use unix sockets (and if it works, please do send feedback). + +I had missed this last night, I will try passing the socket down and see +if it works. + +I can also see the gen_tcp:listen in ranch_tcp but I'd prefer to avoid that. + + +From Christopher.Phillips at turner.com Fri Mar 14 19:52:07 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 18:52:07 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the body +Message-ID: + +On a dev server I had a Cowboy app suddenly start returning timeouts when calling cowboy_req:body_qs(Request), with surprising frequency, which in turn led to 500s back to the calling client. It only appeared to happen when hitting one particular resource, and was sporadic, and I was wondering if there might be some explanation related to Cowboy (as opposed to maybe really weird VM issues). For full disclosure, we would first check the body with cowboy_req:body(Request) as part of an access log, then ignore the returned cowboy_req:req() that call passed back, since we could not then stream the body off of it again. It was working fine, so I don't think it was related, but it seems more solid now after I removed it and I don't know if that's related or not. + + + +Here is an example request that dumped when the process died - + + +{req,[{socket,#Port<0.7113>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1805.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{10,188,32,225},53188}},{host,<<"bps-feedschedulervip1.turner.com">>},{host_info,undefined},{port,8091},{path,<<"/encoders/Player1/record">>},{path_info,[<<"record">>]},{qs,<<"authToken=...">>},{qs_vals,[{<<"authToken">>,<<"...">>}]},{bindings,[{id,<<"Player1">>}]},{headers,[{<<"host">>,<<"bps-feedschedulervip1.turner.com:8091">>},{<<"content-type">>,<<"application/x-www-form-urlencoded; charset=UTF-8">>},{<<"origin">>,<<"http://bps-newstrondev1.turner.com">>},{<<"content-length">>,<<"48">>},{<<"connection">>,<<"keep-alive">>},{<<"accept">>,<<"application/json, text/javascript, */*; q=0.01">>},{<<"user-agent">>,<<"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9">>},{<<"referer">>,<<"http://bps-newstrondev1.turner.com/newstron/record/record.html">>},{<<"accept-language">>,<<"en-us">>},{<<"accept-encoding">>,<<"gzip, deflate">>}]},{p_headers,[{<<"content-type">>,{<<"application">>,<<"x-www-form-urlencoded">>,[{<<"charset">>,<<"utf-8">>}]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"application">>,<<"json">>,[]},1000,[]},{{<<"text">>,<<"javascript">>,[]},1000,[]},{{<<"*">>,<<"*">>,[]},10,[]}]},{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[{charset,undefined},{media_type,{<<"application">>,<<"json">>,[]}}]},{body_state,waiting},{multipart,undefined},{buffer,<<>>},{resp_compress,false},{resp_state,waiting},{resp_headers,[{<<"content-type">>,[<<"application">>,<<"/">>,<<"json">>,<<>>]},{<<"Access-Control-Allow-Origin">>,<<"*">>}]},{resp_body,<<>>},{onresponse,#Fun}]} + + + + +As I said, it may be just due to VM issues or something, but I figured I'd ask in case there was any obvious issue. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Fri Mar 14 19:56:38 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 14 Mar 2014 19:56:38 +0100 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: +References: +Message-ID: <532350E6.5080507@ninenines.eu> + +Cowboy does have a timeout too small, that will be fixed soon (by making +it configurable, per body-reading call). It will be in the next release. + +On the other hand there's something weird in what you said. + +On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +> first check the body with cowboy_req:body(Request) as part of an access +> log, then ignore the returned cowboy_req:req() that call passed back, +> since we could not then stream the body off of it again. It was working +> fine, so I don't think it was related, but it seems more solid now after +> I removed it and I don't know if that's related or not. + +If you ignore the Req being returned, especially after a body-reading +call, then Cowboy will not be able to figure out that you actually read +it, and will attempt to read it again to skip it, leading to issues. + +-- +Lo?c Hoguin +http://ninenines.eu + + +From Christopher.Phillips at turner.com Fri Mar 14 20:07:40 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 19:07:40 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <532350E6.5080507@ninenines.eu> +References: + <532350E6.5080507@ninenines.eu> +Message-ID: + + This body is -small-. 48 bytes was my test data (per the +content-length). That shouldn't take 5 seconds to read, and usually it +took a millisecond or two, and returned to the client (despite actually +controlling some hardware across a network and such) within a second. And +it was ND; I tested this thing a couple of times locally and it appeared +to work, and even deployed onto a VM it worked some of the time (as I +said, might have been hardware or some other weirdness). + + So can we only read the body once? Or what's the right approach if I +want to access the body in both a module registered to the +onrequest/onresponse callbacks, and in the REST handler? + +On 3/14/14, 2:56 PM, "Lo?c Hoguin" wrote: + +>Cowboy does have a timeout too small, that will be fixed soon (by making +>it configurable, per body-reading call). It will be in the next release. +> +>On the other hand there's something weird in what you said. +> +>On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>> first check the body with cowboy_req:body(Request) as part of an access +>> log, then ignore the returned cowboy_req:req() that call passed back, +>> since we could not then stream the body off of it again. It was working +>> fine, so I don't think it was related, but it seems more solid now after +>> I removed it and I don't know if that's related or not. +> +>If you ignore the Req being returned, especially after a body-reading +>call, then Cowboy will not be able to figure out that you actually read +>it, and will attempt to read it again to skip it, leading to issues. +> +>-- +>Lo?c Hoguin +>http://ninenines.eu + + + +From essen at ninenines.eu Fri Mar 14 20:11:27 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 14 Mar 2014 20:11:27 +0100 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: +References: + <532350E6.5080507@ninenines.eu> + +Message-ID: <5323545F.4050602@ninenines.eu> + +Yep, only once. All functions that return {ok, ...} are like this. +There's no right approach, that's left as an exercise to the developer. :-) + +You can probably use cowboy_req:set_meta/meta if you really need to pass +it around. + +On 03/14/2014 08:07 PM, Phillips, Christopher wrote: +> This body is -small-. 48 bytes was my test data (per the +> content-length). That shouldn't take 5 seconds to read, and usually it +> took a millisecond or two, and returned to the client (despite actually +> controlling some hardware across a network and such) within a second. And +> it was ND; I tested this thing a couple of times locally and it appeared +> to work, and even deployed onto a VM it worked some of the time (as I +> said, might have been hardware or some other weirdness). +> +> So can we only read the body once? Or what's the right approach if I +> want to access the body in both a module registered to the +> onrequest/onresponse callbacks, and in the REST handler? +> +> On 3/14/14, 2:56 PM, "Lo?c Hoguin" wrote: +> +>> Cowboy does have a timeout too small, that will be fixed soon (by making +>> it configurable, per body-reading call). It will be in the next release. +>> +>> On the other hand there's something weird in what you said. +>> +>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>>> first check the body with cowboy_req:body(Request) as part of an access +>>> log, then ignore the returned cowboy_req:req() that call passed back, +>>> since we could not then stream the body off of it again. It was working +>>> fine, so I don't think it was related, but it seems more solid now after +>>> I removed it and I don't know if that's related or not. +>> +>> If you ignore the Req being returned, especially after a body-reading +>> call, then Cowboy will not be able to figure out that you actually read +>> it, and will attempt to read it again to skip it, leading to issues. +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From Christopher.Phillips at turner.com Fri Mar 14 20:13:31 2014 +From: Christopher.Phillips at turner.com (Phillips, Christopher) +Date: Fri, 14 Mar 2014 19:13:31 +0000 +Subject: [99s-extend] Cowboy unexpectedly timing out when reading the + body +In-Reply-To: <5323545F.4050602@ninenines.eu> +References: + <532350E6.5080507@ninenines.eu> + + <5323545F.4050602@ninenines.eu> +Message-ID: + + Hmm, okay. Thanks Loic. + +On 3/14/14, 3:11 PM, "Lo?c Hoguin" wrote: + +>Yep, only once. All functions that return {ok, ...} are like this. +>There's no right approach, that's left as an exercise to the developer. +>:-) +> +>You can probably use cowboy_req:set_meta/meta if you really need to pass +>it around. +> +>On 03/14/2014 08:07 PM, Phillips, Christopher wrote: +>> This body is -small-. 48 bytes was my test data (per the +>> content-length). That shouldn't take 5 seconds to read, and usually it +>> took a millisecond or two, and returned to the client (despite actually +>> controlling some hardware across a network and such) within a second. +>>And +>> it was ND; I tested this thing a couple of times locally and it appeared +>> to work, and even deployed onto a VM it worked some of the time (as I +>> said, might have been hardware or some other weirdness). +>> +>> So can we only read the body once? Or what's the right approach if I +>> want to access the body in both a module registered to the +>> onrequest/onresponse callbacks, and in the REST handler? +>> +>> On 3/14/14, 2:56 PM, "Lo?c Hoguin" wrote: +>> +>>> Cowboy does have a timeout too small, that will be fixed soon (by +>>>making +>>> it configurable, per body-reading call). It will be in the next +>>>release. +>>> +>>> On the other hand there's something weird in what you said. +>>> +>>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote: +>>>> first check the body with cowboy_req:body(Request) as part of an +>>>>access +>>>> log, then ignore the returned cowboy_req:req() that call passed back, +>>>> since we could not then stream the body off of it again. It was +>>>>working +>>>> fine, so I don't think it was related, but it seems more solid now +>>>>after +>>>> I removed it and I don't know if that's related or not. +>>> +>>> If you ignore the Req being returned, especially after a body-reading +>>> call, then Cowboy will not be able to figure out that you actually read +>>> it, and will attempt to read it again to skip it, leading to issues. +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +>-- +>Lo?c Hoguin +>http://ninenines.eu + + + diff --git a/_build/static/archives/extend/2014-March/000340.html b/_build/static/archives/extend/2014-March/000340.html new file mode 100644 index 00000000..228ab579 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000340.html @@ -0,0 +1,105 @@ + + + + [99s-extend] usage of make_* command + + + + + + + + + + +

[99s-extend] usage of make_* command

+ Anton Koval' + psihonavt at gmail.com +
+ Mon Mar 3 21:49:33 CET 2014 +

+
+ +
Hello,
+
+I have next structure of my project:
+.
+├── deps
+│   ├── cowboy
+│   ├── cowlib
+│   ├── erlang_iconv
+│   ├── erlydtl
+│   ├── mochiweb_xpath
+│   └── ranch
+├── ebin
+│   ├── fetchers.beam
+│   ├── parsers.beam
+│   └── wasearch_sup.beam
+├── erlang.mk
+├── Makefile
+├── _rel
+│   └── ....
+├── relx
+├── relx.config
+├── src
+│   ├── fetchers.erl
+│   ├── main_handler.erl
+│   ├── parsers.erl
+│   ├── tests
+│   │   ├── parsers_SUITE_data
+│   │   ├── parsers_SUITE.erl
+│   │   ├── ....
+│   ├── wasearch_app.erl
+│   ├── wasearch.app.src
+│   └── wasearch_sup.erl
+└── templates
+    └── index.dtl
+
+I would prefer to store tests not in `src` directory but rather in `tests`
+subdirectory.
+Erlang.mk README says: You can run an individual test suite by using the
+special test_* targets. For example if you have a common_test suite named
+spdy and you want to run only this suite and not the others, you can use
+the make test_spdy command.
+And of course `make test_parsers`  returns `no rule to make target` error.
+Is there a way to run suites from custom directory with
+`make_<mod_name_with_suite>` command?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140303/52007acc/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000341.html b/_build/static/archives/extend/2014-March/000341.html new file mode 100644 index 00000000..4ae144b9 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000341.html @@ -0,0 +1,81 @@ + + + + [99s-extend] Cowboy pre request filter + + + + + + + + + + +

[99s-extend] Cowboy pre request filter

+ Mark Nijhof + mark.nijhof at cre8ivethought.com +
+ Thu Mar 6 00:47:08 CET 2014 +

+
+ +
Hi,
+
+I want to create a module that basically sits between the incoming request
+and the http handler for that request to ensure a request is authenticated
+(using a cookie), if the request is not authenticated then I like to
+redirect to a specific login page (which should not be filtered).
+
+Is this possible with Cowboy? Should I use the onrequest hook (not sure if
+I can force redirects from there) for that or is there a better way?
+
+Cheers,
+
+-Mark
+
+-- 
+Mark Nijhof
+t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+s:  marknijhof
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/a517215b/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000342.html b/_build/static/archives/extend/2014-March/000342.html new file mode 100644 index 00000000..b2779a5d --- /dev/null +++ b/_build/static/archives/extend/2014-March/000342.html @@ -0,0 +1,129 @@ + + + + [99s-extend] Cowboy pre request filter + + + + + + + + + + +

[99s-extend] Cowboy pre request filter

+ Mark Nijhof + mark.nijhof at cre8ivethought.com +
+ Thu Mar 6 10:52:01 CET 2014 +

+
+ +
I also found the answer to my own question: custom middleware
+
+I just created:
+
+   1 -module(authentication_middleware).
+   2
+   3 -behaviour(cowboy_middleware).
+   4
+   5 -export([execute/2]).
+   6
+   7 execute(Req, Env) ->
+   8
+   9     {Path, Req1} = cowboy_req:path(Req),
+  10
+  11     case Path of
+  12         <<"/login.html">> ->
+  13             {ok, Req1, Env};
+  14         <<"/do_login">> ->
+  15             {ok, Req1, Env};
+  16         _ ->
+  17             case id3as_security:is_request_authenticated(Req1) of
+  18                 {error, eauth, Req2} ->
+  19                     {ok, Req4} = cowboy_req:reply(303,
+[{<<"Location">>, <<"/login.html">>}], "", Req2),
+  20                     {halt, Req4};
+  21                 {authenticated, _Id, Req2} ->
+  22                    {ok, Req2, Env}
+  23             end
+  24     end.
+
+And put this between the cowboy_router and cowboy_handler and life is all
+good.
+
+-Mark
+
+
+
+On Thu, Mar 6, 2014 at 12:47 AM, Mark Nijhof <mark.nijhof at cre8ivethought.com
+> wrote:
+
+> Hi,
+>
+> I want to create a module that basically sits between the incoming request
+> and the http handler for that request to ensure a request is authenticated
+> (using a cookie), if the request is not authenticated then I like to
+> redirect to a specific login page (which should not be filtered).
+>
+> Is this possible with Cowboy? Should I use the onrequest hook (not sure if
+> I can force redirects from there) for that or is there a better way?
+>
+> Cheers,
+>
+> -Mark
+>
+> --
+> Mark Nijhof
+> t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+> s:  marknijhof
+>
+>
+
+
+-- 
+Mark Nijhof
+t:   @MarkNijhof <https://twitter.com/MarkNijhof>
+s:  marknijhof
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/24422ef2/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000343.html b/_build/static/archives/extend/2014-March/000343.html new file mode 100644 index 00000000..b027aebb --- /dev/null +++ b/_build/static/archives/extend/2014-March/000343.html @@ -0,0 +1,121 @@ + + + + [99s-extend] usage of make_* command + + + + + + + + + + +

[99s-extend] usage of make_* command

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 6 15:40:59 CET 2014 +

+
+ +
Tests should be in ./tests, not ./src/tests.
+
+If you put them in ./tests everything you mentioned will work.
+
+On 03/03/2014 09:49 PM, Anton Koval' wrote:
+> Hello,
+>
+> I have next structure of my project:
+> .
+> ├── deps
+> │   ├── cowboy
+> │   ├── cowlib
+> │   ├── erlang_iconv
+> │   ├── erlydtl
+> │   ├── mochiweb_xpath
+> │   └── ranch
+> ├── ebin
+> │   ├── fetchers.beam
+> │   ├── parsers.beam
+> │   └── wasearch_sup.beam
+> ├── erlang.mk <http://erlang.mk>
+> ├── Makefile
+> ├── _rel
+> │   └── ....
+> ├── relx
+> ├── relx.config
+> ├── src
+> │   ├── fetchers.erl
+> │   ├── main_handler.erl
+> │   ├── parsers.erl
+> │   ├── tests
+> │   │   ├── parsers_SUITE_data
+> │   │   ├── parsers_SUITE.erl
+> │   │   ├── ....
+> │   ├── wasearch_app.erl
+> │   ├── wasearch.app.src
+> │   └── wasearch_sup.erl
+> └── templates
+>      └── index.dtl
+>
+> I would prefer to store tests not in `src` directory but rather in
+> `tests` subdirectory.
+> Erlang.mk README says: You can run an individual test suite by using the
+> special |test_*| targets. For example if you have a common_test suite
+> named |spdy| and you want to run only this suite and not the others, you
+> can use the |make test_spdy| command.
+> And of course `make test_parsers`  returns `no rule to make target` error.
+> Is there a way to run suites from custom directory with
+> `make_<mod_name_with_suite>` command?
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000344.html b/_build/static/archives/extend/2014-March/000344.html new file mode 100644 index 00000000..d6d3e174 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000344.html @@ -0,0 +1,134 @@ + + + + [99s-extend] usage of make_* command + + + + + + + + + + +

[99s-extend] usage of make_* command

+ Anton Koval' + psihonavt at gmail.com +
+ Thu Mar 6 15:50:01 CET 2014 +

+
+ +
Thank you for answer.
+Is it common way (for OTP-based application) to store tests in `tests`
+subdirectory rather then in `src/tests/`?
+
+
+On Thu, Mar 6, 2014 at 4:40 PM, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Tests should be in ./tests, not ./src/tests.
+>
+> If you put them in ./tests everything you mentioned will work.
+>
+>
+> On 03/03/2014 09:49 PM, Anton Koval' wrote:
+>
+>> Hello,
+>>
+>> I have next structure of my project:
+>> .
+>> ├── deps
+>> │   ├── cowboy
+>> │   ├── cowlib
+>> │   ├── erlang_iconv
+>> │   ├── erlydtl
+>> │   ├── mochiweb_xpath
+>> │   └── ranch
+>> ├── ebin
+>> │   ├── fetchers.beam
+>> │   ├── parsers.beam
+>> │   └── wasearch_sup.beam
+>> ├── erlang.mk <http://erlang.mk>
+>>
+>> ├── Makefile
+>> ├── _rel
+>> │   └── ....
+>> ├── relx
+>> ├── relx.config
+>> ├── src
+>> │   ├── fetchers.erl
+>> │   ├── main_handler.erl
+>> │   ├── parsers.erl
+>> │   ├── tests
+>> │   │   ├── parsers_SUITE_data
+>> │   │   ├── parsers_SUITE.erl
+>> │   │   ├── ....
+>> │   ├── wasearch_app.erl
+>> │   ├── wasearch.app.src
+>> │   └── wasearch_sup.erl
+>> └── templates
+>>      └── index.dtl
+>>
+>> I would prefer to store tests not in `src` directory but rather in
+>> `tests` subdirectory.
+>> Erlang.mk README says: You can run an individual test suite by using the
+>> special |test_*| targets. For example if you have a common_test suite
+>> named |spdy| and you want to run only this suite and not the others, you
+>> can use the |make test_spdy| command.
+>> And of course `make test_parsers`  returns `no rule to make target` error.
+>> Is there a way to run suites from custom directory with
+>> `make_<mod_name_with_suite>` command?
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140306/6fa8fe3b/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000345.html b/_build/static/archives/extend/2014-March/000345.html new file mode 100644 index 00000000..1da559eb --- /dev/null +++ b/_build/static/archives/extend/2014-March/000345.html @@ -0,0 +1,148 @@ + + + + [99s-extend] usage of make_* command + + + + + + + + + + +

[99s-extend] usage of make_* command

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 6 15:51:58 CET 2014 +

+
+ +
Sorry I meant ./test/ not ./tests/
+
+But yes. That's how OTP does it.
+
+On 03/06/2014 03:50 PM, Anton Koval' wrote:
+> Thank you for answer.
+> Is it common way (for OTP-based application) to store tests in `tests`
+> subdirectory rather then in `src/tests/`?
+>
+>
+> On Thu, Mar 6, 2014 at 4:40 PM, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Tests should be in ./tests, not ./src/tests.
+>
+>     If you put them in ./tests everything you mentioned will work.
+>
+>
+>     On 03/03/2014 09:49 PM, Anton Koval' wrote:
+>
+>         Hello,
+>
+>         I have next structure of my project:
+>         .
+>         ├── deps
+>         │   ├── cowboy
+>         │   ├── cowlib
+>         │   ├── erlang_iconv
+>         │   ├── erlydtl
+>         │   ├── mochiweb_xpath
+>         │   └── ranch
+>         ├── ebin
+>         │   ├── fetchers.beam
+>         │   ├── parsers.beam
+>         │   └── wasearch_sup.beam
+>         ├── erlang.mk <http://erlang.mk> <http://erlang.mk>
+>
+>         ├── Makefile
+>         ├── _rel
+>         │   └── ....
+>         ├── relx
+>         ├── relx.config
+>         ├── src
+>         │   ├── fetchers.erl
+>         │   ├── main_handler.erl
+>         │   ├── parsers.erl
+>         │   ├── tests
+>         │   │   ├── parsers_SUITE_data
+>         │   │   ├── parsers_SUITE.erl
+>         │   │   ├── ....
+>         │   ├── wasearch_app.erl
+>         │   ├── wasearch.app.src
+>         │   └── wasearch_sup.erl
+>         └── templates
+>               └── index.dtl
+>
+>         I would prefer to store tests not in `src` directory but rather in
+>         `tests` subdirectory.
+>         Erlang.mk README says: You can run an individual test suite by
+>         using the
+>         special |test_*| targets. For example if you have a common_test
+>         suite
+>         named |spdy| and you want to run only this suite and not the
+>         others, you
+>         can use the |make test_spdy| command.
+>         And of course `make test_parsers`  returns `no rule to make
+>         target` error.
+>         Is there a way to run suites from custom directory with
+>         `make_<mod_name_with_suite>` command?
+>
+>
+>         _________________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         https://lists.ninenines.eu/__listinfo/extend
+>         <https://lists.ninenines.eu/listinfo/extend>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000346.html b/_build/static/archives/extend/2014-March/000346.html new file mode 100644 index 00000000..c5372244 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000346.html @@ -0,0 +1,149 @@ + + + + [99s-extend] Trying to grok erlang.mk + + + + + + + + + + +

[99s-extend] Trying to grok erlang.mk

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Thu Mar 6 21:29:59 CET 2014 +

+
+ +
Hello,
+
+To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this:
+
+min
+   erlang.mk
+   Makefile
+   src
+      min.app.src
+      min.erl
+
+*** Where Makefile is:
+
+PROJECT = min
+
+include erlang.mk
+
+*** min.app.src is:
+
+{application, min,
+         [{description,[]},
+          {vsn,"0.1.0"},
+          {registered,[]},
+          {applications,[kernel,stdlib]},
+          {env,[]},
+          {modules,[]}]}.
+
+*** and min.erl is:
+
+-module(min).
+
+-export([hello/0]).
+
+hello() ->
+   io:format("Hello min!~n~n").
+
+*** But when I call make, I get this:
+
+/min$ make
+ ERLC   min.erl
+ APP    min .app.src
+cat: src/min: No such file or directory
+cat: .app.src: No such file or directory
+sed: can't read .app: No such file or directory
+make: *** [app] Error 2
+
+*** Observations
+
+min.erl compiles just  fine
+min.app.src breaks the compile
+
+*** Questions: 
+
+1) How can I correct this?
+2) How can I structure directories and make files for a project that involves several applications?
+
+Many thanks,
+
+LRP
+
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000347.html b/_build/static/archives/extend/2014-March/000347.html new file mode 100644 index 00000000..b8e2990a --- /dev/null +++ b/_build/static/archives/extend/2014-March/000347.html @@ -0,0 +1,221 @@ + + + + [99s-extend] Trying to grok erlang.mk + + + + + + + + + + +

[99s-extend] Trying to grok erlang.mk

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Fri Mar 7 13:37:27 CET 2014 +

+
+ +
Dear Lloyd
+
+I've just tried this with file layout and contents copied from your 
+email, and make works fine here I'm afraid.
+
+One odd thing I noticed in your make output ...
+
+ > /min$ make
+ >   ERLC   min.erl
+ >   APP    min .app.src
+ > cat: src/min: No such file or directory
+ > cat: .app.src: No such file or directory
+ > sed: can't read .app: No such file or directory
+ > make: *** [app] Error 2
+
+... is that in the APP line, the filename min.app.src has a space in it, 
+and it looks (in the cat lines) like it's broken down into src/min and 
+.app.src (ie ./.app.src).  I can't imagine why that's happening, but 
+that's what's causing the problem I should think.
+
+ > 2) How can I structure directories and make files for a project
+ >    that involves several applications?
+
+I don't know if it's the "correct" way with erlang.mk but, as a refugee 
+from rebar, I have apps set out rebar-style and use old-school recursive 
+make. e.g.:
+
+max/
+   erlang.mk
+   Makefile
+   apps/
+     app1/
+       Makefile
+       src/
+     app2/
+       Makefile
+       src/
+
+Top level Makefile doesn't need to include erlang.mk, and has lines like:
+
+all:
+	$(MAKE) -C apps/app1
+	$(MAKE) -C apps/app2
+
+Lower level Makefiles include erlang.mk.
+
+Best wishes
+
+Ivan
+
+
+On 06/03/2014 20:29, lloyd at writersglen.com wrote:
+> Hello,
+>
+> To secure my understanding of erlang.mk, I've been trying to create the simplest possible example I can imagine. Which gives me this:
+>
+> min
+>     erlang.mk
+>     Makefile
+>     src
+>        min.app.src
+>        min.erl
+>
+> *** Where Makefile is:
+>
+> PROJECT = min
+>
+> include erlang.mk
+>
+> *** min.app.src is:
+>
+> {application, min,
+>           [{description,[]},
+>            {vsn,"0.1.0"},
+>            {registered,[]},
+>            {applications,[kernel,stdlib]},
+>            {env,[]},
+>            {modules,[]}]}.
+>
+> *** and min.erl is:
+>
+> -module(min).
+>
+> -export([hello/0]).
+>
+> hello() ->
+>     io:format("Hello min!~n~n").
+>
+> *** But when I call make, I get this:
+>
+> /min$ make
+>   ERLC   min.erl
+>   APP    min .app.src
+> cat: src/min: No such file or directory
+> cat: .app.src: No such file or directory
+> sed: can't read .app: No such file or directory
+> make: *** [app] Error 2
+>
+> *** Observations
+>
+> min.erl compiles just  fine
+> min.app.src breaks the compile
+>
+> *** Questions:
+>
+> 1) How can I correct this?
+> 2) How can I structure directories and make files for a project that involves several applications?
+>
+> Many thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000348.html b/_build/static/archives/extend/2014-March/000348.html new file mode 100644 index 00000000..e7140ade --- /dev/null +++ b/_build/static/archives/extend/2014-March/000348.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Trying to grok erlang.mk + + + + + + + + + + +

[99s-extend] Trying to grok erlang.mk

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Mar 7 17:56:01 CET 2014 +

+
+ +
On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote:
+> PROJECT = min
+
+You probably have an extra space at the end here, and erlang.mk doesn't 
+trim them I guess. Please open a ticket!
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000349.html b/_build/static/archives/extend/2014-March/000349.html new file mode 100644 index 00000000..37895e1d --- /dev/null +++ b/_build/static/archives/extend/2014-March/000349.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Trying to grok erlang.mk + + + + + + + + + + +

[99s-extend] Trying to grok erlang.mk

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Fri Mar 7 17:58:40 CET 2014 +

+
+ +
Yes, that's it!  I've just tried it.
+
+Good old make :)
+
+On 07/03/2014 16:56, Loïc Hoguin wrote:
+> On 03/06/2014 09:29 PM, lloyd at writersglen.com wrote:
+>> PROJECT = min
+>
+> You probably have an extra space at the end here, and erlang.mk doesn't
+> trim them I guess. Please open a ticket!
+>
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                      www.llaisdy.com
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000350.html b/_build/static/archives/extend/2014-March/000350.html new file mode 100644 index 00000000..d257a7e8 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000350.html @@ -0,0 +1,115 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Mon Mar 10 20:44:27 CET 2014 +

+
+ +
Hello,
+
+I've slavishly emulated the "Getting started" example in the guide: 
+
+http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+
+But, when I compile I get this error:
+
+yada yada
+ ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+compile: warnings being treated as errors
+src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+make: *** [ebin/hello_erlang.app] Error 1
+
+Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+
+However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+
+% -behavior(cowboy_http_handler).
+
+Could this be a bug in Getting started or some dunder-headed thing on my end?
+
+Thanks,
+
+LRP
+
+
+*********************************************
+My books:
+
+THE GOSPEL OF ASHES
+http://thegospelofashes.com
+
+Strength is not enough. Do they have the courage 
+and the cunning? Can they survive long enough to 
+save the lives of millions?  
+
+FREEIN' PANCHO
+http://freeinpancho.com
+
+A community of misfits help a troubled boy find his way 
+
+AYA TAKEO
+http://ayatakeo.com
+
+Star-crossed love, war and power in an alternative 
+universe
+
+Available through Amazon or by request from your 
+favorite bookstore
+
+
+**********************************************
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000351.html b/_build/static/archives/extend/2014-March/000351.html new file mode 100644 index 00000000..ef1f4457 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000351.html @@ -0,0 +1,131 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Mar 10 21:36:22 CET 2014 +

+
+ +
Try updating Erlang or Cowboy, this isn't the first time this happens 
+and I fixed something at some point.
+
+Also see if you have ERL_LIBS already defined, in which case there might 
+be a bug in Cowboy.
+
+On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> I've slavishly emulated the "Getting started" example in the guide:
+>
+> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>
+> But, when I compile I get this error:
+>
+> yada yada
+>   ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+> compile: warnings being treated as errors
+> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+> make: *** [ebin/hello_erlang.app] Error 1
+>
+> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>
+> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>
+> % -behavior(cowboy_http_handler).
+>
+> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>
+> Thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000352.html b/_build/static/archives/extend/2014-March/000352.html new file mode 100644 index 00000000..bacc9c24 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000352.html @@ -0,0 +1,157 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Wed Mar 12 23:51:04 CET 2014 +

+
+ +
Hi Loïc,
+
+Thanks for help.
+
+I'm running cowboy master from GitHub and Erlang R16B02.
+
+$ echo $ERL_LIBS
+
+...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+
+E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+
+I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+
+Thanks again,
+
+LRP
+
+-----Original Message-----
+From: "Loïc Hoguin" <essen at ninenines.eu>
+Sent: Monday, March 10, 2014 4:36pm
+To: lloyd at writersglen.com, extend at lists.ninenines.eu
+Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+
+Try updating Erlang or Cowboy, this isn't the first time this happens 
+and I fixed something at some point.
+
+Also see if you have ERL_LIBS already defined, in which case there might 
+be a bug in Cowboy.
+
+On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+> Hello,
+>
+> I've slavishly emulated the "Getting started" example in the guide:
+>
+> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>
+> But, when I compile I get this error:
+>
+> yada yada
+>   ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+> compile: warnings being treated as errors
+> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+> make: *** [ebin/hello_erlang.app] Error 1
+>
+> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>
+> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>
+> % -behavior(cowboy_http_handler).
+>
+> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>
+> Thanks,
+>
+> LRP
+>
+>
+> *********************************************
+> My books:
+>
+> THE GOSPEL OF ASHES
+> http://thegospelofashes.com
+>
+> Strength is not enough. Do they have the courage
+> and the cunning? Can they survive long enough to
+> save the lives of millions?
+>
+> FREEIN' PANCHO
+> http://freeinpancho.com
+>
+> A community of misfits help a troubled boy find his way
+>
+> AYA TAKEO
+> http://ayatakeo.com
+>
+> Star-crossed love, war and power in an alternative
+> universe
+>
+> Available through Amazon or by request from your
+> favorite bookstore
+>
+>
+> **********************************************
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000353.html b/_build/static/archives/extend/2014-March/000353.html new file mode 100644 index 00000000..da6966ee --- /dev/null +++ b/_build/static/archives/extend/2014-March/000353.html @@ -0,0 +1,159 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Mar 12 23:57:16 CET 2014 +

+
+ +
Can you try again after running "unset ERL_LIBS"?
+
+On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+> Hi Loïc,
+>
+> Thanks for help.
+>
+> I'm running cowboy master from GitHub and Erlang R16B02.
+>
+> $ echo $ERL_LIBS
+>
+> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>
+> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>
+> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>
+> Thanks again,
+>
+> LRP
+>
+> -----Original Message-----
+> From: "Loïc Hoguin" <essen at ninenines.eu>
+> Sent: Monday, March 10, 2014 4:36pm
+> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Try updating Erlang or Cowboy, this isn't the first time this happens
+> and I fixed something at some point.
+>
+> Also see if you have ERL_LIBS already defined, in which case there might
+> be a bug in Cowboy.
+>
+> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>> Hello,
+>>
+>> I've slavishly emulated the "Getting started" example in the guide:
+>>
+>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>
+>> But, when I compile I get this error:
+>>
+>> yada yada
+>>    ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>> compile: warnings being treated as errors
+>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>> make: *** [ebin/hello_erlang.app] Error 1
+>>
+>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>
+>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>
+>> % -behavior(cowboy_http_handler).
+>>
+>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>
+>> Thanks,
+>>
+>> LRP
+>>
+>>
+>> *********************************************
+>> My books:
+>>
+>> THE GOSPEL OF ASHES
+>> http://thegospelofashes.com
+>>
+>> Strength is not enough. Do they have the courage
+>> and the cunning? Can they survive long enough to
+>> save the lives of millions?
+>>
+>> FREEIN' PANCHO
+>> http://freeinpancho.com
+>>
+>> A community of misfits help a troubled boy find his way
+>>
+>> AYA TAKEO
+>> http://ayatakeo.com
+>>
+>> Star-crossed love, war and power in an alternative
+>> universe
+>>
+>> Available through Amazon or by request from your
+>> favorite bookstore
+>>
+>>
+>> **********************************************
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000354.html b/_build/static/archives/extend/2014-March/000354.html new file mode 100644 index 00000000..fad782d1 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000354.html @@ -0,0 +1,180 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ lloyd at writersglen.com + lloyd at writersglen.com +
+ Thu Mar 13 00:43:16 CET 2014 +

+
+ +
Hi,
+
+That fixed it!
+
+But where can I go to understand why and prevent it in future? 
+
+I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system?
+
+Many thanks!
+
+Lloyd
+
+-----Original Message-----
+From: "Loïc Hoguin" <essen at ninenines.eu>
+Sent: Wednesday, March 12, 2014 6:57pm
+To: lloyd at writersglen.com
+Cc: extend at lists.ninenines.eu
+Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+
+Can you try again after running "unset ERL_LIBS"?
+
+On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+> Hi Loïc,
+>
+> Thanks for help.
+>
+> I'm running cowboy master from GitHub and Erlang R16B02.
+>
+> $ echo $ERL_LIBS
+>
+> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>
+> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>
+> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>
+> Thanks again,
+>
+> LRP
+>
+> -----Original Message-----
+> From: "Loïc Hoguin" <essen at ninenines.eu>
+> Sent: Monday, March 10, 2014 4:36pm
+> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Try updating Erlang or Cowboy, this isn't the first time this happens
+> and I fixed something at some point.
+>
+> Also see if you have ERL_LIBS already defined, in which case there might
+> be a bug in Cowboy.
+>
+> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>> Hello,
+>>
+>> I've slavishly emulated the "Getting started" example in the guide:
+>>
+>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>
+>> But, when I compile I get this error:
+>>
+>> yada yada
+>>    ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>> compile: warnings being treated as errors
+>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>> make: *** [ebin/hello_erlang.app] Error 1
+>>
+>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>
+>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>
+>> % -behavior(cowboy_http_handler).
+>>
+>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>
+>> Thanks,
+>>
+>> LRP
+>>
+>>
+>> *********************************************
+>> My books:
+>>
+>> THE GOSPEL OF ASHES
+>> http://thegospelofashes.com
+>>
+>> Strength is not enough. Do they have the courage
+>> and the cunning? Can they survive long enough to
+>> save the lives of millions?
+>>
+>> FREEIN' PANCHO
+>> http://freeinpancho.com
+>>
+>> A community of misfits help a troubled boy find his way
+>>
+>> AYA TAKEO
+>> http://ayatakeo.com
+>>
+>> Star-crossed love, war and power in an alternative
+>> universe
+>>
+>> Available through Amazon or by request from your
+>> favorite bookstore
+>>
+>>
+>> **********************************************
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000355.html b/_build/static/archives/extend/2014-March/000355.html new file mode 100644 index 00000000..819e76e1 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000355.html @@ -0,0 +1,186 @@ + + + + [99s-extend] Getting started error: behaviour cowboy_http_handler undefined + + + + + + + + + + +

[99s-extend] Getting started error: behaviour cowboy_http_handler undefined

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 13 00:46:57 CET 2014 +

+
+ +
It's explained here: http://www.erlang.org/doc/man/code.html
+
+I am not sure why it caused issues on your system, possibly Erlang 
+ignored it because there was an invalid folder in there. I don't really 
+know.
+
+On 03/13/2014 12:43 AM, lloyd at writersglen.com wrote:
+> Hi,
+>
+> That fixed it!
+>
+> But where can I go to understand why and prevent it in future?
+>
+> I've googled ERL_LIBS, but not found much enlightenment. Should there possibly be a note in Cowboy docs? Or is this something idiosyncratic to my system?
+>
+> Many thanks!
+>
+> Lloyd
+>
+> -----Original Message-----
+> From: "Loïc Hoguin" <essen at ninenines.eu>
+> Sent: Wednesday, March 12, 2014 6:57pm
+> To: lloyd at writersglen.com
+> Cc: extend at lists.ninenines.eu
+> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>
+> Can you try again after running "unset ERL_LIBS"?
+>
+> On 03/12/2014 11:51 PM, lloyd at writersglen.com wrote:
+>> Hi Loïc,
+>>
+>> Thanks for help.
+>>
+>> I'm running cowboy master from GitHub and Erlang R16B02.
+>>
+>> $ echo $ERL_LIBS
+>>
+>> ...gives me a directory that no longer exists; don't know how it got there, what it should be, or how to change it.
+>>
+>> E.g.: /home/lloyd/Programming/Erlang/zippity/apps
+>>
+>> I've looked in .erlang and tried $ export ERL_LIBS=<my path to hello_erlang/ebin>.
+>>
+>> Thanks again,
+>>
+>> LRP
+>>
+>> -----Original Message-----
+>> From: "Loïc Hoguin" <essen at ninenines.eu>
+>> Sent: Monday, March 10, 2014 4:36pm
+>> To: lloyd at writersglen.com, extend at lists.ninenines.eu
+>> Subject: Re: [99s-extend] Getting started error: behaviour cowboy_http_handler undefined
+>>
+>> Try updating Erlang or Cowboy, this isn't the first time this happens
+>> and I fixed something at some point.
+>>
+>> Also see if you have ERL_LIBS already defined, in which case there might
+>> be a bug in Cowboy.
+>>
+>> On 03/10/2014 08:44 PM, lloyd at writersglen.com wrote:
+>>> Hello,
+>>>
+>>> I've slavishly emulated the "Getting started" example in the guide:
+>>>
+>>> http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/
+>>>
+>>> But, when I compile I get this error:
+>>>
+>>> yada yada
+>>>     ERLC   hello_erlang_app.erl hello_handler.erl hello_erlang_sup.erl
+>>> compile: warnings being treated as errors
+>>> src/hello_handler.erl:2: behaviour cowboy_http_handler undefined
+>>> make: *** [ebin/hello_erlang.app] Error 1
+>>>
+>>> Cowboy seems to be correctly loaded and compiled as a dependency. I can see .../cowboy/ebin/cowboy_http_handler.beam
+>>>
+>>> However, when I remove the line -behavior(cowboy_http_handler) from hello_handler.erl, system compiles and creates release just fine.
+>>>
+>>> % -behavior(cowboy_http_handler).
+>>>
+>>> Could this be a bug in Getting started or some dunder-headed thing on my end?
+>>>
+>>> Thanks,
+>>>
+>>> LRP
+>>>
+>>>
+>>> *********************************************
+>>> My books:
+>>>
+>>> THE GOSPEL OF ASHES
+>>> http://thegospelofashes.com
+>>>
+>>> Strength is not enough. Do they have the courage
+>>> and the cunning? Can they survive long enough to
+>>> save the lives of millions?
+>>>
+>>> FREEIN' PANCHO
+>>> http://freeinpancho.com
+>>>
+>>> A community of misfits help a troubled boy find his way
+>>>
+>>> AYA TAKEO
+>>> http://ayatakeo.com
+>>>
+>>> Star-crossed love, war and power in an alternative
+>>> universe
+>>>
+>>> Available through Amazon or by request from your
+>>> favorite bookstore
+>>>
+>>>
+>>> **********************************************
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000356.html b/_build/static/archives/extend/2014-March/000356.html new file mode 100644 index 00000000..a1742223 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000356.html @@ -0,0 +1,96 @@ + + + + [99s-extend] Updating Cowboy applications + + + + + + + + + + +

[99s-extend] Updating Cowboy applications

+ Joshua McQuistan + joshua.mcquistan at mcq.io +
+ Thu Mar 13 02:41:12 CET 2014 +

+
+ +
Hello all,
+
+I have written a Cowboy application that works fine over localhost. I'm
+now looking at ways of deploying and updating it i.e., moving from dev
+to prod in a nice manner.
+
+I have dug around the archives and have found that Cowboy does not
+support hot code reloading meaning either a restart of the vm or playing
+with code:reload_file is necessary.
+
+The latter suggests a possible rewriting of OTP's code loading mechanism
+and seems like it might be sensible to avoid.
+
+The other approach then is a restart. In previous (non-Cowboy) set ups
+I've used nginx on port 80 / 443 that talks to the web app via a unix
+socket (e.g., "web/socket"). When updating I'll start a new instance on
+a new socket (e.g., "web/socket.new") then rely on the file system's
+"mv" to switch it to "web/socket"; this works because the underlying
+file system guarantees mv to be atomic (or at least to never see a
+missing file). I can then ask the old process to shut down nicely in the
+background.
+
+For this to work it would require Cowby / Ranch to be able to listen on
+unix sockets. A glance at the documentation suggests that unix sockets
+aren't available, is this the case? What's the feasibility of it getting
+added?
+
+It might just be simpler to load-balance across multiple servers and
+safely take them out one at a time while updating.
+
+My other question is, how do others approach this problem? Did I miss
+something vitally obvious?
+
+Regards,
+Joshua
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000357.html b/_build/static/archives/extend/2014-March/000357.html new file mode 100644 index 00000000..da65a33e --- /dev/null +++ b/_build/static/archives/extend/2014-March/000357.html @@ -0,0 +1,125 @@ + + + + [99s-extend] Updating Cowboy applications + + + + + + + + + + +

[99s-extend] Updating Cowboy applications

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 13 14:22:03 CET 2014 +

+
+ +
Deploying is easy: releases.
+
+The "getting started" chapter of the guide, and all the examples use 
+that and it should be pretty easy to do.
+
+You can reload Cowboy modules directly using l(module). You can reload 
+most Ranch modules too but some of them will require using sys. Ranch 
+will get support for upgrades as soon as I finish the upgrade test 
+suite, but it's still low priority.
+
+And upgrade of Cowboy processes can only be added after we make them 
+special processes, which is still a way to go.
+
+There is no plans for supporting unix sockets for the simple reason that 
+it is not portable. On the other hand, if you use a separate library to 
+open a socket and give it to Ranch (socket option), possibly writing a 
+specific transport module for it, then it's very possible that you can 
+use unix sockets (and if it works, please do send feedback).
+
+On 03/13/2014 02:41 AM, Joshua McQuistan wrote:
+> Hello all,
+>
+> I have written a Cowboy application that works fine over localhost. I'm
+> now looking at ways of deploying and updating it i.e., moving from dev
+> to prod in a nice manner.
+>
+> I have dug around the archives and have found that Cowboy does not
+> support hot code reloading meaning either a restart of the vm or playing
+> with code:reload_file is necessary.
+>
+> The latter suggests a possible rewriting of OTP's code loading mechanism
+> and seems like it might be sensible to avoid.
+>
+> The other approach then is a restart. In previous (non-Cowboy) set ups
+> I've used nginx on port 80 / 443 that talks to the web app via a unix
+> socket (e.g., "web/socket"). When updating I'll start a new instance on
+> a new socket (e.g., "web/socket.new") then rely on the file system's
+> "mv" to switch it to "web/socket"; this works because the underlying
+> file system guarantees mv to be atomic (or at least to never see a
+> missing file). I can then ask the old process to shut down nicely in the
+> background.
+>
+> For this to work it would require Cowby / Ranch to be able to listen on
+> unix sockets. A glance at the documentation suggests that unix sockets
+> aren't available, is this the case? What's the feasibility of it getting
+> added?
+>
+> It might just be simpler to load-balance across multiple servers and
+> safely take them out one at a time while updating.
+>
+> My other question is, how do others approach this problem? Did I miss
+> something vitally obvious?
+>
+> Regards,
+> Joshua
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000358.html b/_build/static/archives/extend/2014-March/000358.html new file mode 100644 index 00000000..7c7f0abe --- /dev/null +++ b/_build/static/archives/extend/2014-March/000358.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Updating Cowboy applications + + + + + + + + + + +

[99s-extend] Updating Cowboy applications

+ Joshua McQuistan + joshua.mcquistan at mcq.io +
+ Thu Mar 13 15:23:09 CET 2014 +

+
+ +
> 
+> I wish I knew enough to answer your question. But I do hope you publish a tutorial documenting your solution for those following you down the trail.
+
+Will do.
+
+On 13/03/14 13:22, Loïc Hoguin wrote:
+> 
+> There is no plans for supporting unix sockets for the simple reason that
+> it is not portable. On the other hand, if you use a separate library to
+> open a socket and give it to Ranch (socket option), possibly writing a
+> specific transport module for it, then it's very possible that you can
+> use unix sockets (and if it works, please do send feedback).
+
+I had missed this last night, I will try passing the socket down and see
+if it works.
+
+I can also see the gen_tcp:listen in ranch_tcp but I'd prefer to avoid that.
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000359.html b/_build/static/archives/extend/2014-March/000359.html new file mode 100644 index 00000000..1ce4d916 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000359.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Cowboy unexpectedly timing out when reading the body + + + + + + + + + + +

[99s-extend] Cowboy unexpectedly timing out when reading the body

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Fri Mar 14 19:52:07 CET 2014 +

+
+ +
On a dev server I had a Cowboy app suddenly start returning timeouts when calling cowboy_req:body_qs(Request), with surprising frequency, which in turn led to 500s back to the calling client. It only appeared to happen when hitting one particular resource, and was sporadic, and I was wondering if there might be some explanation related to Cowboy (as opposed to maybe really weird VM issues). For full disclosure, we would first check the body with cowboy_req:body(Request) as part of an access log, then ignore the returned cowboy_req:req() that call passed back, since we could not then stream the body off of it again. It was working fine, so I don't think it was related, but it seems more solid now after I removed it and I don't know if that's related or not.
+
+
+
+Here is an example request that dumped when the process died -
+
+
+{req,[{socket,#Port<0.7113>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1805.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{10,188,32,225},53188}},{host,<<"bps-feedschedulervip1.turner.com">>},{host_info,undefined},{port,8091},{path,<<"/encoders/Player1/record">>},{path_info,[<<"record">>]},{qs,<<"authToken=...">>},{qs_vals,[{<<"authToken">>,<<"...">>}]},{bindings,[{id,<<"Player1">>}]},{headers,[{<<"host">>,<<"bps-feedschedulervip1.turner.com:8091">>},{<<"content-type">>,<<"application/x-www-form-urlencoded; charset=UTF-8">>},{<<"origin">>,<<"http://bps-newstrondev1.turner.com">>},{<<"content-length">>,<<"48">>},{<<"connection">>,<<"keep-alive">>},{<<"accept">>,<<"application/json, text/javascript, */*; q=0.01">>},{<<"user-agent">>,<<"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9">>},{<<"referer">>,<<"http://bps-newstrondev1.turner.com/newstron/record/record.html">>},{<<"accept-language">>,<<"en-us">>},{<<"accept-encoding">>,<<"gzip, deflate">>}]},{p_headers,[{<<"content-type">>,{<<"application">>,<<"x-www-form-urlencoded">>,[{<<"charset">>,<<"utf-8">>}]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"application">>,<<"json">>,[]},1000,[]},{{<<"text">>,<<"javascript">>,[]},1000,[]},{{<<"*">>,<<"*">>,[]},10,[]}]},{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[{charset,undefined},{media_type,{<<"application">>,<<"json">>,[]}}]},{body_state,waiting},{multipart,undefined},{buffer,<<>>},{resp_compress,false},{resp_state,waiting},{resp_headers,[{<<"content-type">>,[<<"application">>,<<"/">>,<<"json">>,<<>>]},{<<"Access-Control-Allow-Origin">>,<<"*">>}]},{resp_body,<<>>},{onresponse,#Fun<access_log_responder.onresponse.4>}]}
+
+
+
+
+As I said, it may be just due to VM issues or something, but I figured I'd ask in case there was any obvious issue.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140314/b2f802d3/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000360.html b/_build/static/archives/extend/2014-March/000360.html new file mode 100644 index 00000000..24c59e1b --- /dev/null +++ b/_build/static/archives/extend/2014-March/000360.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Cowboy unexpectedly timing out when reading the body + + + + + + + + + + +

[99s-extend] Cowboy unexpectedly timing out when reading the body

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Mar 14 19:56:38 CET 2014 +

+
+ +
Cowboy does have a timeout too small, that will be fixed soon (by making 
+it configurable, per body-reading call). It will be in the next release.
+
+On the other hand there's something weird in what you said.
+
+On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+> first check the body with cowboy_req:body(Request) as part of an access
+> log, then ignore the returned cowboy_req:req() that call passed back,
+> since we could not then stream the body off of it again. It was working
+> fine, so I don't think it was related, but it seems more solid now after
+> I removed it and I don't know if that's related or not.
+
+If you ignore the Req being returned, especially after a body-reading 
+call, then Cowboy will not be able to figure out that you actually read 
+it, and will attempt to read it again to skip it, leading to issues.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000361.html b/_build/static/archives/extend/2014-March/000361.html new file mode 100644 index 00000000..0140723a --- /dev/null +++ b/_build/static/archives/extend/2014-March/000361.html @@ -0,0 +1,95 @@ + + + + [99s-extend] Cowboy unexpectedly timing out when reading the body + + + + + + + + + + +

[99s-extend] Cowboy unexpectedly timing out when reading the body

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Fri Mar 14 20:07:40 CET 2014 +

+
+ +
  This body is -small-. 48 bytes was my test data (per the
+content-length). That shouldn't take 5 seconds to read, and usually it
+took a millisecond or two, and returned to the client (despite actually
+controlling some hardware across a network and such) within a second. And
+it was ND; I tested this thing a couple of times locally and it appeared
+to work, and even deployed onto a VM it worked some of the time (as I
+said, might have been hardware or some other weirdness).
+
+  So can we only read the body once? Or what's the right approach if I
+want to access the body in both a module registered to the
+onrequest/onresponse callbacks, and in the REST handler?
+
+On 3/14/14, 2:56 PM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+>Cowboy does have a timeout too small, that will be fixed soon (by making
+>it configurable, per body-reading call). It will be in the next release.
+>
+>On the other hand there's something weird in what you said.
+>
+>On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>> first check the body with cowboy_req:body(Request) as part of an access
+>> log, then ignore the returned cowboy_req:req() that call passed back,
+>> since we could not then stream the body off of it again. It was working
+>> fine, so I don't think it was related, but it seems more solid now after
+>> I removed it and I don't know if that's related or not.
+>
+>If you ignore the Req being returned, especially after a body-reading
+>call, then Cowboy will not be able to figure out that you actually read
+>it, and will attempt to read it again to skip it, leading to issues.
+>
+>-- 
+>Loïc Hoguin
+>http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000362.html b/_build/static/archives/extend/2014-March/000362.html new file mode 100644 index 00000000..07e318d1 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000362.html @@ -0,0 +1,106 @@ + + + + [99s-extend] Cowboy unexpectedly timing out when reading the body + + + + + + + + + + +

[99s-extend] Cowboy unexpectedly timing out when reading the body

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Mar 14 20:11:27 CET 2014 +

+
+ +
Yep, only once. All functions that return {ok, ...} are like this. 
+There's no right approach, that's left as an exercise to the developer. :-)
+
+You can probably use cowboy_req:set_meta/meta if you really need to pass 
+it around.
+
+On 03/14/2014 08:07 PM, Phillips, Christopher wrote:
+>    This body is -small-. 48 bytes was my test data (per the
+> content-length). That shouldn't take 5 seconds to read, and usually it
+> took a millisecond or two, and returned to the client (despite actually
+> controlling some hardware across a network and such) within a second. And
+> it was ND; I tested this thing a couple of times locally and it appeared
+> to work, and even deployed onto a VM it worked some of the time (as I
+> said, might have been hardware or some other weirdness).
+>
+>    So can we only read the body once? Or what's the right approach if I
+> want to access the body in both a module registered to the
+> onrequest/onresponse callbacks, and in the REST handler?
+>
+> On 3/14/14, 2:56 PM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+>
+>> Cowboy does have a timeout too small, that will be fixed soon (by making
+>> it configurable, per body-reading call). It will be in the next release.
+>>
+>> On the other hand there's something weird in what you said.
+>>
+>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>>> first check the body with cowboy_req:body(Request) as part of an access
+>>> log, then ignore the returned cowboy_req:req() that call passed back,
+>>> since we could not then stream the body off of it again. It was working
+>>> fine, so I don't think it was related, but it seems more solid now after
+>>> I removed it and I don't know if that's related or not.
+>>
+>> If you ignore the Req being returned, especially after a body-reading
+>> call, then Cowboy will not be able to figure out that you actually read
+>> it, and will attempt to read it again to skip it, leading to issues.
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/000363.html b/_build/static/archives/extend/2014-March/000363.html new file mode 100644 index 00000000..f9141c42 --- /dev/null +++ b/_build/static/archives/extend/2014-March/000363.html @@ -0,0 +1,116 @@ + + + + [99s-extend] Cowboy unexpectedly timing out when reading the body + + + + + + + + + + +

[99s-extend] Cowboy unexpectedly timing out when reading the body

+ Phillips, Christopher + Christopher.Phillips at turner.com +
+ Fri Mar 14 20:13:31 CET 2014 +

+
+ +
  Hmm, okay. Thanks Loic.
+
+On 3/14/14, 3:11 PM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+
+>Yep, only once. All functions that return {ok, ...} are like this.
+>There's no right approach, that's left as an exercise to the developer.
+>:-)
+>
+>You can probably use cowboy_req:set_meta/meta if you really need to pass
+>it around.
+>
+>On 03/14/2014 08:07 PM, Phillips, Christopher wrote:
+>>    This body is -small-. 48 bytes was my test data (per the
+>> content-length). That shouldn't take 5 seconds to read, and usually it
+>> took a millisecond or two, and returned to the client (despite actually
+>> controlling some hardware across a network and such) within a second.
+>>And
+>> it was ND; I tested this thing a couple of times locally and it appeared
+>> to work, and even deployed onto a VM it worked some of the time (as I
+>> said, might have been hardware or some other weirdness).
+>>
+>>    So can we only read the body once? Or what's the right approach if I
+>> want to access the body in both a module registered to the
+>> onrequest/onresponse callbacks, and in the REST handler?
+>>
+>> On 3/14/14, 2:56 PM, "Loïc Hoguin" <essen at ninenines.eu> wrote:
+>>
+>>> Cowboy does have a timeout too small, that will be fixed soon (by
+>>>making
+>>> it configurable, per body-reading call). It will be in the next
+>>>release.
+>>>
+>>> On the other hand there's something weird in what you said.
+>>>
+>>> On 03/14/2014 07:52 PM, Phillips, Christopher wrote:
+>>>> first check the body with cowboy_req:body(Request) as part of an
+>>>>access
+>>>> log, then ignore the returned cowboy_req:req() that call passed back,
+>>>> since we could not then stream the body off of it again. It was
+>>>>working
+>>>> fine, so I don't think it was related, but it seems more solid now
+>>>>after
+>>>> I removed it and I don't know if that's related or not.
+>>>
+>>> If you ignore the Req being returned, especially after a body-reading
+>>> call, then Cowboy will not be able to figure out that you actually read
+>>> it, and will attempt to read it again to skip it, leading to issues.
+>>>
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>>
+>
+>-- 
+>Loïc Hoguin
+>http://ninenines.eu
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-March/author.html b/_build/static/archives/extend/2014-March/author.html new file mode 100644 index 00000000..b935d6a0 --- /dev/null +++ b/_build/static/archives/extend/2014-March/author.html @@ -0,0 +1,167 @@ + + + + The Extend March 2014 Archive by author + + + + + +

March 2014 Archives by author

+ +

Starting: Mon Mar 3 21:49:33 CET 2014
+ Ending: Fri Mar 14 20:13:31 CET 2014
+ Messages: 24

+

+

+ Last message date: + Fri Mar 14 20:13:31 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-March/date.html b/_build/static/archives/extend/2014-March/date.html new file mode 100644 index 00000000..07c935eb --- /dev/null +++ b/_build/static/archives/extend/2014-March/date.html @@ -0,0 +1,167 @@ + + + + The Extend March 2014 Archive by date + + + + + +

March 2014 Archives by date

+ +

Starting: Mon Mar 3 21:49:33 CET 2014
+ Ending: Fri Mar 14 20:13:31 CET 2014
+ Messages: 24

+

+

+ Last message date: + Fri Mar 14 20:13:31 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-March/index.html b/_build/static/archives/extend/2014-March/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-March/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-March/subject.html b/_build/static/archives/extend/2014-March/subject.html new file mode 100644 index 00000000..a8173ef7 --- /dev/null +++ b/_build/static/archives/extend/2014-March/subject.html @@ -0,0 +1,167 @@ + + + + The Extend March 2014 Archive by subject + + + + + +

March 2014 Archives by subject

+ +

Starting: Mon Mar 3 21:49:33 CET 2014
+ Ending: Fri Mar 14 20:13:31 CET 2014
+ Messages: 24

+

+

+ Last message date: + Fri Mar 14 20:13:31 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-March/thread.html b/_build/static/archives/extend/2014-March/thread.html new file mode 100644 index 00000000..d9b001cf --- /dev/null +++ b/_build/static/archives/extend/2014-March/thread.html @@ -0,0 +1,219 @@ + + + + The Extend March 2014 Archive by thread + + + + + +

March 2014 Archives by thread

+ +

Starting: Mon Mar 3 21:49:33 CET 2014
+ Ending: Fri Mar 14 20:13:31 CET 2014
+ Messages: 24

+

+

+ Last message date: + Fri Mar 14 20:13:31 CET 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-May.txt b/_build/static/archives/extend/2014-May.txt new file mode 100644 index 00000000..2b42dd73 --- /dev/null +++ b/_build/static/archives/extend/2014-May.txt @@ -0,0 +1,363 @@ +From janos.n.hary at gmail.com Sun May 4 09:59:21 2014 +From: janos.n.hary at gmail.com (Janos Hary) +Date: Sun, 4 May 2014 09:59:21 +0200 +Subject: [99s-extend] Gracefully stop Ranch +Message-ID: <001b01cf676e$c2ec8e20$48c5aa60$@gmail.com> + +All! + +I implemented a protocol as a ranch_protocol. It handles long running +sessions. At some point I'd like to stop my server accepting new +connections, but allow all open sessions to finish. Then I need to know when +all the open sessions (if any) finished. + +What would be the correct strategy to implement this? + +Thanks, +Janos + + + +From paulo.ferraz.oliveira at gmail.com Tue May 20 18:27:58 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 20 May 2014 17:27:58 +0100 +Subject: [99s-extend] REST responses +Message-ID: + +Hello. + +First of all, thanks for the great work you've done with cowboy. I've been +using it with a fait amount of success and I'm a fairly new Erlang +developer. I'm mainly interested in the REST "interface" of the application +and its way of doing RESTful things, and I like the way you did it (what +with all the content_types_provided, service_available, etc. functions). +I've tested the way the system reacted to the different Accept, +Content-Type, etc. headers and always got very well-opinionated responses +(406, 415, ...). + +A couple of questions remain though (I'm sorry if they've been asked +already but I've searched the web for answers and read the available docs +and couldn't find them): + +1. is it expected that, if I use cowboy_req:reply/2 in a GET handler +(coming from content_types_provided), the onresponse/4 hook be called +twice? I guess one is due to the reply and the other one due to the +workflow of the request, but is there a way to prevent the second execution? + +2. if I want to JSON-parse ALL my requests should I a) use the onrequest/1 +hook or b) do this on a per-request basis? Because I'd like to reply with a +400 ASAP but keep going if the JSON validates (I'm going to use JSON-schema +for validating input); and, if possible, have the JSON-parsed body stored +somewhere for future manipulation. + +3. I haven't seen examples that made use of the State (from the function +returns). When should I use this instead of the Request metadata? I'd like +to be able to set a generic error state for a request (either in meta ou +State) and that have a "standard" error response be created at a later time +(in a unique function, for example - e.g. onresponse/4). + +4. is there anything like a catch-all exception handler? I'd like to catch +exceptions that occur anywhere so I could log them and analyze them at a +later moment. + +I'm probably abusing the onresponse/onrequest hooks already, so your +answers should help me clarify this. + +Thanks. + +- Paulo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From paulo.ferraz.oliveira at gmail.com Tue May 20 20:32:10 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 20 May 2014 19:32:10 +0100 +Subject: [99s-extend] 202 for POST or PUT +Message-ID: + +Hi. + +Do you think it should be possible to generate a 202 for a POST or a PUT? +Is it something that will be implemented in a future version? + +Many thanks. + +- Paulo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue May 20 20:46:02 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 20 May 2014 20:46:02 +0200 +Subject: [99s-extend] REST responses +In-Reply-To: +References: +Message-ID: <537BA2EA.5080108@ninenines.eu> + +Hi, + +On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote: +> Hello. +> +> First of all, thanks for the great work you've done with cowboy. I've +> been using it with a fait amount of success and I'm a fairly new Erlang +> developer. I'm mainly interested in the REST "interface" of the +> application and its way of doing RESTful things, and I like the way you +> did it (what with all the content_types_provided, service_available, +> etc. functions). I've tested the way the system reacted to the different +> Accept, Content-Type, etc. headers and always got very well-opinionated +> responses (406, 415, ...). +> +> A couple of questions remain though (I'm sorry if they've been asked +> already but I've searched the web for answers and read the available +> docs and couldn't find them): +> +> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler +> (coming from content_types_provided), the onresponse/4 hook be called +> twice? I guess one is due to the reply and the other one due to the +> workflow of the request, but is there a way to prevent the second execution? + +If you reply from a callback you must call {halt, Req, State} to stop +processing. + +> 2. if I want to JSON-parse ALL my requests should I a) use the +> onrequest/1 hook or b) do this on a per-request basis? Because I'd like +> to reply with a 400 ASAP but keep going if the JSON validates (I'm going +> to use JSON-schema for validating input); and, if possible, have the +> JSON-parsed body stored somewhere for future manipulation. + +It makes little sense to do it before the accept callback you define. +Not only because you will duplicate content-type checks and whatnot, but +also because you don't actually win anything from doing this. If you are +using JSON, then JSON processing will take infinitely more resources +than the REST code. + +> 3. I haven't seen examples that made use of the State (from the function +> returns). When should I use this instead of the Request metadata? I'd +> like to be able to set a generic error state for a request (either in +> meta ou State) and that have a "standard" error response be created at a +> later time (in a unique function, for example - e.g. onresponse/4). + +State is for the functions within the current module. Look at +cowboy_static for an example. + +> 4. is there anything like a catch-all exception handler? I'd like to +> catch exceptions that occur anywhere so I could log them and analyze +> them at a later moment. + +You can add your own error_logger handler, or use something like lager. +All errors end up sending a message to error_logger. + +> I'm probably abusing the onresponse/onrequest hooks already, so your +> answers should help me clarify this. + +Sounds like it! + +> Thanks. +> +> - Paulo +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From essen at ninenines.eu Tue May 20 20:47:16 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 20 May 2014 20:47:16 +0200 +Subject: [99s-extend] 202 for POST or PUT +In-Reply-To: +References: +Message-ID: <537BA334.7080607@ninenines.eu> + +202 is only well defined for the DELETE method so there's no plan to add +something for other methods at this point. You can of course reply +directly if needed. + +On 05/20/2014 08:32 PM, Paulo F. Oliveira wrote: +> Hi. +> +> Do you think it should be possible to generate a 202 for a POST or a +> PUT? Is it something that will be implemented in a future version? +> +> Many thanks. +> +> - Paulo +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + + +From paulo.ferraz.oliveira at gmail.com Tue May 20 23:41:15 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Tue, 20 May 2014 22:41:15 +0100 +Subject: [99s-extend] REST responses +Message-ID: + +Hi, Lo?c. + +Thanks for having taken the time to reply. In some of my questions I think +I didn't explain myself correctly so I'll give it another go. + + +On 20 May 2014 19:46, Lo?c Hoguin wrote: + +> Hi, +> +> +> On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote: +> +>> Hello. +>> +>> First of all, thanks for the great work you've done with cowboy. I've +>> been using it with a fait amount of success and I'm a fairly new Erlang +>> developer. I'm mainly interested in the REST "interface" of the +>> application and its way of doing RESTful things, and I like the way you +>> did it (what with all the content_types_provided, service_available, +>> etc. functions). I've tested the way the system reacted to the different +>> Accept, Content-Type, etc. headers and always got very well-opinionated +>> responses (406, 415, ...). +>> +>> A couple of questions remain though (I'm sorry if they've been asked +>> already but I've searched the web for answers and read the available +>> docs and couldn't find them): +>> +>> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler +>> (coming from content_types_provided), the onresponse/4 hook be called +>> twice? I guess one is due to the reply and the other one due to the +>> workflow of the request, but is there a way to prevent the second +>> execution? +>> +> +> If you reply from a callback you must call {halt, Req, State} to stop +> processing. + + +Got it! + + +> 2. if I want to JSON-parse ALL my requests should I a) use the +>> onrequest/1 hook or b) do this on a per-request basis? Because I'd like +>> to reply with a 400 ASAP but keep going if the JSON validates (I'm going +>> to use JSON-schema for validating input); and, if possible, have the +>> JSON-parsed body stored somewhere for future manipulation. +>> +> +> It makes little sense to do it before the accept callback you define. Not +> only because you will duplicate content-type checks and whatnot, but also +> because you don't actually win anything from doing this. If you are using +> JSON, then JSON processing will take infinitely more resources than the +> REST code. + + +OK, I'll probably stick with a "helper" function that'll do this for me and +reply in case there are validation errors. +I only found the flow diagrams for the requests today after I had sent this +message, and they helped a lot. + + +> 3. I haven't seen examples that made use of the State (from the function +>> returns). When should I use this instead of the Request metadata? I'd +>> like to be able to set a generic error state for a request (either in +>> meta ou State) and that have a "standard" error response be created at a +>> later time (in a unique function, for example - e.g. onresponse/4). +>> +> +> State is for the functions within the current module. Look at +> cowboy_static for an example. + + +State allows me to, well, keep state, for a request "travelling" through +functions, right, and I can change it whenever I want just before returning +from a function that is executed prior to another one (the only function +for which this doesn't seem to make since is the last one cowboy calls +before actually replying to the client)? At the same time, so does the +request meta, from what I understood from the manual. So what is the +difference between one and the other and when would you recommend one or +the other. + +4. is there anything like a catch-all exception handler? I'd like to +>> catch exceptions that occur anywhere so I could log them and analyze +>> them at a later moment. +>> +> +> You can add your own error_logger handler, or use something like lager. +> All errors end up sending a message to error_logger. + + +I'll do this, thanks. + + +> I'm probably abusing the onresponse/onrequest hooks already, so your +>> answers should help me clarify this. +>> +> +> Sounds like it! +> +> Thanks. +>> +>> - Paulo +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> + +Thanks. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue May 20 23:52:21 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 20 May 2014 23:52:21 +0200 +Subject: [99s-extend] REST responses +In-Reply-To: +References: +Message-ID: <537BCE95.1090100@ninenines.eu> + +> State allows me to, well, keep state, for a request "travelling" through +> functions, right, and I can change it whenever I want just before +> returning from a function that is executed prior to another one (the +> only function for which this doesn't seem to make since is the last one +> cowboy calls before actually replying to the client)? At the same time, +> so does the request meta, from what I understood from the manual. So +> what is the difference between one and the other and when would you +> recommend one or the other. + +They have different purposes. Meta values are additional information +about the request. You're not supposed to set them except in special +circumstances, either because you have your own custom protocol like +cowboy_rest, or because there's no other way to pass state forward. + +Don't think about it, always use State. + +-- +Lo?c Hoguin +http://ninenines.eu + + diff --git a/_build/static/archives/extend/2014-May/000383.html b/_build/static/archives/extend/2014-May/000383.html new file mode 100644 index 00000000..c2ca464b --- /dev/null +++ b/_build/static/archives/extend/2014-May/000383.html @@ -0,0 +1,71 @@ + + + + [99s-extend] Gracefully stop Ranch + + + + + + + + + + +

[99s-extend] Gracefully stop Ranch

+ Janos Hary + janos.n.hary at gmail.com +
+ Sun May 4 09:59:21 CEST 2014 +

+
+ +
All!
+
+I implemented a protocol as a ranch_protocol. It handles long running
+sessions. At some point I'd like to stop my server accepting new
+connections, but allow all open sessions to finish. Then I need to know when
+all the open sessions (if any) finished.
+
+What would be the correct strategy to implement this?
+
+Thanks,
+Janos
+
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000384.html b/_build/static/archives/extend/2014-May/000384.html new file mode 100644 index 00000000..ae3cd3f3 --- /dev/null +++ b/_build/static/archives/extend/2014-May/000384.html @@ -0,0 +1,105 @@ + + + + [99s-extend] REST responses + + + + + + + + + + +

[99s-extend] REST responses

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue May 20 18:27:58 CEST 2014 +

+
+ +
Hello.
+
+First of all, thanks for the great work you've done with cowboy. I've been
+using it with a fait amount of success and I'm a fairly new Erlang
+developer. I'm mainly interested in the REST "interface" of the application
+and its way of doing RESTful things, and I like the way you did it (what
+with all the content_types_provided, service_available, etc. functions).
+I've tested the way the system reacted to the different Accept,
+Content-Type, etc. headers and always got very well-opinionated responses
+(406, 415, ...).
+
+A couple of questions remain though (I'm sorry if they've been asked
+already but I've searched the web for answers and read the available docs
+and couldn't find them):
+
+1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
+(coming from content_types_provided), the onresponse/4 hook be called
+twice? I guess one is due to the reply and the other one due to the
+workflow of the request, but is there a way to prevent the second execution?
+
+2. if I want to JSON-parse ALL my requests should I a) use the onrequest/1
+hook or b) do this on a per-request basis? Because I'd like to reply with a
+400 ASAP but keep going if the JSON validates (I'm going to use JSON-schema
+for validating input); and, if possible, have the JSON-parsed body stored
+somewhere for future manipulation.
+
+3. I haven't seen examples that made use of the State (from the function
+returns). When should I use this instead of the Request metadata? I'd like
+to be able to set a generic error state for a request (either in meta ou
+State) and that have a "standard" error response be created at a later time
+(in a unique function, for example - e.g. onresponse/4).
+
+4. is there anything like a catch-all exception handler? I'd like to catch
+exceptions that occur anywhere so I could log them and analyze them at a
+later moment.
+
+I'm probably abusing the onresponse/onrequest hooks already, so your
+answers should help me clarify this.
+
+Thanks.
+
+- Paulo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/cf7632e9/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000385.html b/_build/static/archives/extend/2014-May/000385.html new file mode 100644 index 00000000..d59d7aea --- /dev/null +++ b/_build/static/archives/extend/2014-May/000385.html @@ -0,0 +1,71 @@ + + + + [99s-extend] 202 for POST or PUT + + + + + + + + + + +

[99s-extend] 202 for POST or PUT

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue May 20 20:32:10 CEST 2014 +

+
+ +
Hi.
+
+Do you think it should be possible to generate a 202 for a POST or a PUT?
+Is it something that will be implemented in a future version?
+
+Many thanks.
+
+- Paulo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/699b72b3/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000386.html b/_build/static/archives/extend/2014-May/000386.html new file mode 100644 index 00000000..6435f3b5 --- /dev/null +++ b/_build/static/archives/extend/2014-May/000386.html @@ -0,0 +1,134 @@ + + + + [99s-extend] REST responses + + + + + + + + + + +

[99s-extend] REST responses

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue May 20 20:46:02 CEST 2014 +

+
+ +
Hi,
+
+On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote:
+> Hello.
+>
+> First of all, thanks for the great work you've done with cowboy. I've
+> been using it with a fait amount of success and I'm a fairly new Erlang
+> developer. I'm mainly interested in the REST "interface" of the
+> application and its way of doing RESTful things, and I like the way you
+> did it (what with all the content_types_provided, service_available,
+> etc. functions). I've tested the way the system reacted to the different
+> Accept, Content-Type, etc. headers and always got very well-opinionated
+> responses (406, 415, ...).
+>
+> A couple of questions remain though (I'm sorry if they've been asked
+> already but I've searched the web for answers and read the available
+> docs and couldn't find them):
+>
+> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
+> (coming from content_types_provided), the onresponse/4 hook be called
+> twice? I guess one is due to the reply and the other one due to the
+> workflow of the request, but is there a way to prevent the second execution?
+
+If you reply from a callback you must call {halt, Req, State} to stop 
+processing.
+
+> 2. if I want to JSON-parse ALL my requests should I a) use the
+> onrequest/1 hook or b) do this on a per-request basis? Because I'd like
+> to reply with a 400 ASAP but keep going if the JSON validates (I'm going
+> to use JSON-schema for validating input); and, if possible, have the
+> JSON-parsed body stored somewhere for future manipulation.
+
+It makes little sense to do it before the accept callback you define. 
+Not only because you will duplicate content-type checks and whatnot, but 
+also because you don't actually win anything from doing this. If you are 
+using JSON, then JSON processing will take infinitely more resources 
+than the REST code.
+
+> 3. I haven't seen examples that made use of the State (from the function
+> returns). When should I use this instead of the Request metadata? I'd
+> like to be able to set a generic error state for a request (either in
+> meta ou State) and that have a "standard" error response be created at a
+> later time (in a unique function, for example - e.g. onresponse/4).
+
+State is for the functions within the current module. Look at 
+cowboy_static for an example.
+
+> 4. is there anything like a catch-all exception handler? I'd like to
+> catch exceptions that occur anywhere so I could log them and analyze
+> them at a later moment.
+
+You can add your own error_logger handler, or use something like lager. 
+All errors end up sending a message to error_logger.
+
+> I'm probably abusing the onresponse/onrequest hooks already, so your
+> answers should help me clarify this.
+
+Sounds like it!
+
+> Thanks.
+>
+> - Paulo
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000387.html b/_build/static/archives/extend/2014-May/000387.html new file mode 100644 index 00000000..493740d2 --- /dev/null +++ b/_build/static/archives/extend/2014-May/000387.html @@ -0,0 +1,83 @@ + + + + [99s-extend] 202 for POST or PUT + + + + + + + + + + +

[99s-extend] 202 for POST or PUT

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue May 20 20:47:16 CEST 2014 +

+
+ +
202 is only well defined for the DELETE method so there's no plan to add 
+something for other methods at this point. You can of course reply 
+directly if needed.
+
+On 05/20/2014 08:32 PM, Paulo F. Oliveira wrote:
+> Hi.
+>
+> Do you think it should be possible to generate a 202 for a POST or a
+> PUT? Is it something that will be implemented in a future version?
+>
+> Many thanks.
+>
+> - Paulo
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000388.html b/_build/static/archives/extend/2014-May/000388.html new file mode 100644 index 00000000..0c28ba4d --- /dev/null +++ b/_build/static/archives/extend/2014-May/000388.html @@ -0,0 +1,180 @@ + + + + [99s-extend] REST responses + + + + + + + + + + +

[99s-extend] REST responses

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue May 20 23:41:15 CEST 2014 +

+
+ +
Hi, Loïc.
+
+Thanks for having taken the time to reply. In some of my questions I think
+I didn't explain myself correctly so I'll give it another go.
+
+
+On 20 May 2014 19:46, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Hi,
+>
+>
+> On 05/20/2014 06:27 PM, Paulo F. Oliveira wrote:
+>
+>> Hello.
+>>
+>> First of all, thanks for the great work you've done with cowboy. I've
+>> been using it with a fait amount of success and I'm a fairly new Erlang
+>> developer. I'm mainly interested in the REST "interface" of the
+>> application and its way of doing RESTful things, and I like the way you
+>> did it (what with all the content_types_provided, service_available,
+>> etc. functions). I've tested the way the system reacted to the different
+>> Accept, Content-Type, etc. headers and always got very well-opinionated
+>> responses (406, 415, ...).
+>>
+>> A couple of questions remain though (I'm sorry if they've been asked
+>> already but I've searched the web for answers and read the available
+>> docs and couldn't find them):
+>>
+>> 1. is it expected that, if I use cowboy_req:reply/2 in a GET handler
+>> (coming from content_types_provided), the onresponse/4 hook be called
+>> twice? I guess one is due to the reply and the other one due to the
+>> workflow of the request, but is there a way to prevent the second
+>> execution?
+>>
+>
+> If you reply from a callback you must call {halt, Req, State} to stop
+> processing.
+
+
+Got it!
+
+
+> 2. if I want to JSON-parse ALL my requests should I a) use the
+>> onrequest/1 hook or b) do this on a per-request basis? Because I'd like
+>> to reply with a 400 ASAP but keep going if the JSON validates (I'm going
+>> to use JSON-schema for validating input); and, if possible, have the
+>> JSON-parsed body stored somewhere for future manipulation.
+>>
+>
+> It makes little sense to do it before the accept callback you define. Not
+> only because you will duplicate content-type checks and whatnot, but also
+> because you don't actually win anything from doing this. If you are using
+> JSON, then JSON processing will take infinitely more resources than the
+> REST code.
+
+
+OK, I'll probably stick with a "helper" function that'll do this for me and
+reply in case there are validation errors.
+I only found the flow diagrams for the requests today after I had sent this
+message, and they helped a lot.
+
+
+> 3. I haven't seen examples that made use of the State (from the function
+>> returns). When should I use this instead of the Request metadata? I'd
+>> like to be able to set a generic error state for a request (either in
+>> meta ou State) and that have a "standard" error response be created at a
+>> later time (in a unique function, for example - e.g. onresponse/4).
+>>
+>
+> State is for the functions within the current module. Look at
+> cowboy_static for an example.
+
+
+State allows me to, well, keep state, for a request "travelling" through
+functions, right, and I can change it whenever I want just before returning
+from a function that is executed prior to another one (the only function
+for which this doesn't seem to make since is the last one cowboy calls
+before actually replying to the client)? At the same time, so does the
+request meta, from what I understood from the manual. So what is the
+difference between one and the other and when would you recommend one or
+the other.
+
+4. is there anything like a catch-all exception handler? I'd like to
+>> catch exceptions that occur anywhere so I could log them and analyze
+>> them at a later moment.
+>>
+>
+> You can add your own error_logger handler, or use something like lager.
+> All errors end up sending a message to error_logger.
+
+
+I'll do this, thanks.
+
+
+> I'm probably abusing the onresponse/onrequest hooks already, so your
+>> answers should help me clarify this.
+>>
+>
+> Sounds like it!
+>
+> Thanks.
+>>
+>> - Paulo
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+>
+
+Thanks.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140520/32454f85/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/000389.html b/_build/static/archives/extend/2014-May/000389.html new file mode 100644 index 00000000..2f1f44c7 --- /dev/null +++ b/_build/static/archives/extend/2014-May/000389.html @@ -0,0 +1,80 @@ + + + + [99s-extend] REST responses + + + + + + + + + + +

[99s-extend] REST responses

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue May 20 23:52:21 CEST 2014 +

+
+ +
> State allows me to, well, keep state, for a request "travelling" through
+> functions, right, and I can change it whenever I want just before
+> returning from a function that is executed prior to another one (the
+> only function for which this doesn't seem to make since is the last one
+> cowboy calls before actually replying to the client)? At the same time,
+> so does the request meta, from what I understood from the manual. So
+> what is the difference between one and the other and when would you
+> recommend one or the other.
+
+They have different purposes. Meta values are additional information 
+about the request. You're not supposed to set them except in special 
+circumstances, either because you have your own custom protocol like 
+cowboy_rest, or because there's no other way to pass state forward.
+
+Don't think about it, always use State.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-May/author.html b/_build/static/archives/extend/2014-May/author.html new file mode 100644 index 00000000..04dd96e0 --- /dev/null +++ b/_build/static/archives/extend/2014-May/author.html @@ -0,0 +1,82 @@ + + + + The Extend May 2014 Archive by author + + + + + +

May 2014 Archives by author

+ +

Starting: Sun May 4 09:59:21 CEST 2014
+ Ending: Tue May 20 23:52:21 CEST 2014
+ Messages: 7

+

+

+ Last message date: + Tue May 20 23:52:21 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-May/date.html b/_build/static/archives/extend/2014-May/date.html new file mode 100644 index 00000000..be72a5b3 --- /dev/null +++ b/_build/static/archives/extend/2014-May/date.html @@ -0,0 +1,82 @@ + + + + The Extend May 2014 Archive by date + + + + + +

May 2014 Archives by date

+ +

Starting: Sun May 4 09:59:21 CEST 2014
+ Ending: Tue May 20 23:52:21 CEST 2014
+ Messages: 7

+

+

+ Last message date: + Tue May 20 23:52:21 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-May/index.html b/_build/static/archives/extend/2014-May/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-May/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-May/subject.html b/_build/static/archives/extend/2014-May/subject.html new file mode 100644 index 00000000..0ce85257 --- /dev/null +++ b/_build/static/archives/extend/2014-May/subject.html @@ -0,0 +1,82 @@ + + + + The Extend May 2014 Archive by subject + + + + + +

May 2014 Archives by subject

+ +

Starting: Sun May 4 09:59:21 CEST 2014
+ Ending: Tue May 20 23:52:21 CEST 2014
+ Messages: 7

+

+

+ Last message date: + Tue May 20 23:52:21 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-May/thread.html b/_build/static/archives/extend/2014-May/thread.html new file mode 100644 index 00000000..6a0d295f --- /dev/null +++ b/_build/static/archives/extend/2014-May/thread.html @@ -0,0 +1,95 @@ + + + + The Extend May 2014 Archive by thread + + + + + +

May 2014 Archives by thread

+ +

Starting: Sun May 4 09:59:21 CEST 2014
+ Ending: Tue May 20 23:52:21 CEST 2014
+ Messages: 7

+

+

+ Last message date: + Tue May 20 23:52:21 CEST 2014
+ Archived on: Wed May 28 18:41:47 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-November.txt b/_build/static/archives/extend/2014-November.txt new file mode 100644 index 00000000..d1431e9e --- /dev/null +++ b/_build/static/archives/extend/2014-November.txt @@ -0,0 +1,210 @@ +From suresh at pimtools.com Thu Nov 6 14:31:23 2014 +From: suresh at pimtools.com (Suresh Kumar R) +Date: Thu, 6 Nov 2014 19:01:23 +0530 +Subject: [99s-extend] Html encode/decode +Message-ID: <2CC4A45D-FB15-4FB1-842D-BA29FB4FA3F6@pimtools.com> + +Hi, + +Can you suggest a best library to encode/decode html and url? I am using cowboy and bullet. Mochiweb seems to support only url encode/decode. + +I have been using mochijson2.erl file from mochi web to encode/decode json. + +Cheers +Suresh + + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From e at bestmx.net Thu Nov 6 14:32:41 2014 +From: e at bestmx.net (e at bestmx.net) +Date: Thu, 06 Nov 2014 14:32:41 +0100 +Subject: [99s-extend] Html encode/decode +In-Reply-To: <2CC4A45D-FB15-4FB1-842D-BA29FB4FA3F6@pimtools.com> +References: <2CC4A45D-FB15-4FB1-842D-BA29FB4FA3F6@pimtools.com> +Message-ID: <545B7879.3020807@bestmx.net> + +> Can you suggest a best library to encode/decode html and url? + +what exactly do you mean encode? +what are desired properties of the encoded text? + + +From e at bestmx.net Tue Nov 11 01:32:45 2014 +From: e at bestmx.net (e at bestmx.net) +Date: Tue, 11 Nov 2014 01:32:45 +0100 +Subject: [99s-extend] Websocket frames sequence +In-Reply-To: <545B7879.3020807@bestmx.net> +References: <2CC4A45D-FB15-4FB1-842D-BA29FB4FA3F6@pimtools.com> + <545B7879.3020807@bestmx.net> +Message-ID: <5461592D.4000408@bestmx.net> + +hi, all + +the question is about websocket and cowboy, both. + +if i return from a callback the value: +{reply, [{text,"A"}, {text,"B"}], Req, State} + +is it guaranteed that "A" will be received by the client prior to "B" ? + +if not, what actually happens? (are they emitted independently or together?) + +From pdtwonotes at gmail.com Tue Nov 11 05:52:45 2014 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Mon, 10 Nov 2014 23:52:45 -0500 +Subject: [99s-extend] Streaming with the static handler +Message-ID: <1415681565.1368.2.camel@gmail.com> + +I am building a streaming music server that delivers mp3 files from disk +to instances of 'mplayer'. So far I am using the Cowboy static handler +for this, and it is working for a single player but I wonder how +efficient the buffering is at the network level. Should I instead be +doing this myself with an http handler and chunked replies? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Nov 11 10:04:04 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 11 Nov 2014 11:04:04 +0200 +Subject: [99s-extend] Websocket frames sequence +In-Reply-To: <5461592D.4000408@bestmx.net> +References: <2CC4A45D-FB15-4FB1-842D-BA29FB4FA3F6@pimtools.com> + <545B7879.3020807@bestmx.net> <5461592D.4000408@bestmx.net> +Message-ID: <5461D104.9030802@ninenines.eu> + +In order, yes. I will clarify that in the guide. + +On 11/11/2014 02:32 AM, e at bestmx.net wrote: +> hi, all +> +> the question is about websocket and cowboy, both. +> +> if i return from a callback the value: +> {reply, [{text,"A"}, {text,"B"}], Req, State} +> +> is it guaranteed that "A" will be received by the client prior to "B" ? +> +> if not, what actually happens? (are they emitted independently or +> together?) +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Tue Nov 11 10:08:31 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 11 Nov 2014 11:08:31 +0200 +Subject: [99s-extend] Streaming with the static handler +In-Reply-To: <1415681565.1368.2.camel@gmail.com> +References: <1415681565.1368.2.camel@gmail.com> +Message-ID: <5461D20F.7020904@ninenines.eu> + +No idea. Measure? Chances are it's good enough for your intended scale. :-) + +On 11/11/2014 06:52 AM, Paul Dickson wrote: +> I am building a streaming music server that delivers mp3 files from disk +> to instances of 'mplayer'. So far I am using the Cowboy static handler +> for this, and it is working for a single player but I wonder how +> efficient the buffering is at the network level. Should I instead be +> doing this myself with an http handler and chunked replies? +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Tue Nov 11 13:24:10 2014 +From: e at bestmx.net (e at bestmx.net) +Date: Tue, 11 Nov 2014 13:24:10 +0100 +Subject: [99s-extend] Streaming with the static handler +In-Reply-To: <1415681565.1368.2.camel@gmail.com> +References: <1415681565.1368.2.camel@gmail.com> +Message-ID: <5461FFEA.9090308@bestmx.net> + +On 11/11/2014 05:52 AM, Paul Dickson wrote: +> I am building a streaming music server that delivers mp3 files from disk +> to instances of 'mplayer'. So far I am using the Cowboy static handler + +nginx is what you need for static files: +http://wiki.nginx.org/AudioTrackForHLS + + +From tristan.sloughter at gmail.com Sat Nov 22 06:44:21 2014 +From: tristan.sloughter at gmail.com (Tristan Sloughter) +Date: Fri, 22 Nov 2014 05:44:21 +0000 +Subject: [99s-extend] shinoki-s44 +Message-ID: <64DDD839586B585FA8DC7B371B81BC74@smtp.deskwing.net> + +http://antiq.co.il/ko/vichpcrgddbxwhfcdpsflud.sqkehqciqedlfxud + + + + + + + + + + + + + + + + + + Tristan Sloughter + + + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From daniel.goertzen at gmail.com Mon Nov 24 22:33:02 2014 +From: daniel.goertzen at gmail.com (Daniel Goertzen) +Date: Mon, 24 Nov 2014 15:33:02 -0600 +Subject: [99s-extend] multiple apps with erlang.mk +Message-ID: + +I'm working quite a bit with erlang.mk, and one thing I've noticed is that +I've seen no mention of how to deal with multiple apps. There are some +great examples of how to build a single app and its dependencies into a +release, but what is the proper way of handling things when you have say 6 +custom written apps (with their deps)? + + +Right now my top level directory looks like this: + +Makefile +erlang.mk +deps/ +custom_app_1/ +custom_app_2/ +custom_app_3/ +... + + +I've got the Makefile using erlang.mk to handle all the dependencies, and +then some custom rules to invoke make on all the app subdirectories. It's +not too bad so far. I was thinking of formalizing some of this into a +subapp plugin. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2014-November/000474.html b/_build/static/archives/extend/2014-November/000474.html new file mode 100644 index 00000000..ff5e6c27 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000474.html @@ -0,0 +1,73 @@ + + + + [99s-extend] Html encode/decode + + + + + + + + + + +

[99s-extend] Html encode/decode

+ Suresh Kumar R + suresh at pimtools.com +
+ Thu Nov 6 14:31:23 CET 2014 +

+
+ +
Hi,
+
+Can you suggest a best library to encode/decode html and url? I am using cowboy and bullet. Mochiweb seems to support only url encode/decode.
+
+I have been using mochijson2.erl file from mochi web to encode/decode json.
+ 
+Cheers
+Suresh
+
+
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141106/85a93e04/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000475.html b/_build/static/archives/extend/2014-November/000475.html new file mode 100644 index 00000000..36aa865c --- /dev/null +++ b/_build/static/archives/extend/2014-November/000475.html @@ -0,0 +1,66 @@ + + + + [99s-extend] Html encode/decode + + + + + + + + + + +

[99s-extend] Html encode/decode

+ e at bestmx.net + e at bestmx.net +
+ Thu Nov 6 14:32:41 CET 2014 +

+
+ +
> Can you suggest a best library to encode/decode html and url?
+
+what exactly do you mean encode?
+what are desired properties of the encoded text?
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000476.html b/_build/static/archives/extend/2014-November/000476.html new file mode 100644 index 00000000..56991cf8 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000476.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Websocket frames sequence + + + + + + + + + + +

[99s-extend] Websocket frames sequence

+ e at bestmx.net + e at bestmx.net +
+ Tue Nov 11 01:32:45 CET 2014 +

+
+ +
hi, all
+
+the question is about websocket and cowboy, both.
+
+if i return from a callback the value:
+{reply, [{text,"A"}, {text,"B"}], Req, State}
+
+is it guaranteed that "A" will be received by the client prior to "B" ?
+
+if not, what actually happens? (are they emitted independently or together?)
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000477.html b/_build/static/archives/extend/2014-November/000477.html new file mode 100644 index 00000000..34aad236 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000477.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Streaming with the static handler + + + + + + + + + + +

[99s-extend] Streaming with the static handler

+ Paul Dickson + pdtwonotes at gmail.com +
+ Tue Nov 11 05:52:45 CET 2014 +

+
+ +
I am building a streaming music server that delivers mp3 files from disk
+to instances of 'mplayer'.  So far I am using the Cowboy static handler
+for this, and it is working for a single player but I wonder how
+efficient the buffering is at the network level.  Should I instead be
+doing this myself with an http handler and chunked replies?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141110/a4b469a5/attachment.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000478.html b/_build/static/archives/extend/2014-November/000478.html new file mode 100644 index 00000000..92270472 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000478.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Websocket frames sequence + + + + + + + + + + +

[99s-extend] Websocket frames sequence

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 11 10:04:04 CET 2014 +

+
+ +
In order, yes. I will clarify that in the guide.
+
+On 11/11/2014 02:32 AM, e at bestmx.net wrote:
+> hi, all
+>
+> the question is about websocket and cowboy, both.
+>
+> if i return from a callback the value:
+> {reply, [{text,"A"}, {text,"B"}], Req, State}
+>
+> is it guaranteed that "A" will be received by the client prior to "B" ?
+>
+> if not, what actually happens? (are they emitted independently or
+> together?)
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000479.html b/_build/static/archives/extend/2014-November/000479.html new file mode 100644 index 00000000..f3955384 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000479.html @@ -0,0 +1,80 @@ + + + + [99s-extend] Streaming with the static handler + + + + + + + + + + +

[99s-extend] Streaming with the static handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Nov 11 10:08:31 CET 2014 +

+
+ +
No idea. Measure? Chances are it's good enough for your intended scale. :-)
+
+On 11/11/2014 06:52 AM, Paul Dickson wrote:
+> I am building a streaming music server that delivers mp3 files from disk
+> to instances of 'mplayer'.  So far I am using the Cowboy static handler
+> for this, and it is working for a single player but I wonder how
+> efficient the buffering is at the network level.  Should I instead be
+> doing this myself with an http handler and chunked replies?
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000480.html b/_build/static/archives/extend/2014-November/000480.html new file mode 100644 index 00000000..23e17977 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000480.html @@ -0,0 +1,68 @@ + + + + [99s-extend] Streaming with the static handler + + + + + + + + + + +

[99s-extend] Streaming with the static handler

+ e at bestmx.net + e at bestmx.net +
+ Tue Nov 11 13:24:10 CET 2014 +

+
+ +
On 11/11/2014 05:52 AM, Paul Dickson wrote:
+> I am building a streaming music server that delivers mp3 files from disk
+> to instances of 'mplayer'.  So far I am using the Cowboy static handler
+
+nginx is what you need for static files:
+http://wiki.nginx.org/AudioTrackForHLS
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000481.html b/_build/static/archives/extend/2014-November/000481.html new file mode 100644 index 00000000..00254448 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000481.html @@ -0,0 +1,86 @@ + + + + [99s-extend] shinoki-s44 + + + + + + + + + + +

[99s-extend] shinoki-s44

+ Tristan Sloughter + tristan.sloughter at gmail.com +
+ Sat Nov 22 06:44:21 CET 2014 +

+
+ +
http://antiq.co.il/ko/vichpcrgddbxwhfcdpsflud.sqkehqciqedlfxud 
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Tristan Sloughter 
+
+
+ 
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141122/bcb1d17c/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/000482.html b/_build/static/archives/extend/2014-November/000482.html new file mode 100644 index 00000000..01d42664 --- /dev/null +++ b/_build/static/archives/extend/2014-November/000482.html @@ -0,0 +1,83 @@ + + + + [99s-extend] multiple apps with erlang.mk + + + + + + + + + + +

[99s-extend] multiple apps with erlang.mk

+ Daniel Goertzen + daniel.goertzen at gmail.com +
+ Mon Nov 24 22:33:02 CET 2014 +

+
+ +
I'm working quite a bit with erlang.mk, and one thing I've noticed is that
+I've seen no mention of how to deal with multiple apps.  There are some
+great examples of how to build a single app and its dependencies into a
+release, but what is the proper way of handling things when you have say 6
+custom written apps (with their deps)?
+
+
+Right now my top level directory looks like this:
+
+Makefile
+erlang.mk
+deps/
+custom_app_1/
+custom_app_2/
+custom_app_3/
+...
+
+
+I've got the Makefile using erlang.mk to handle all the dependencies, and
+then some custom rules to invoke make on all the app subdirectories.  It's
+not too bad so far.  I was thinking of formalizing some of this into a
+subapp plugin.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141124/9ceef28a/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-November/author.html b/_build/static/archives/extend/2014-November/author.html new file mode 100644 index 00000000..0fc7768c --- /dev/null +++ b/_build/static/archives/extend/2014-November/author.html @@ -0,0 +1,92 @@ + + + + The Extend November 2014 Archive by author + + + + + +

November 2014 Archives by author

+ +

Starting: Thu Nov 6 14:31:23 CET 2014
+ Ending: Mon Nov 24 22:33:02 CET 2014
+ Messages: 9

+

+

+ Last message date: + Mon Nov 24 22:33:02 CET 2014
+ Archived on: Mon Nov 24 22:33:05 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-November/date.html b/_build/static/archives/extend/2014-November/date.html new file mode 100644 index 00000000..fce825ca --- /dev/null +++ b/_build/static/archives/extend/2014-November/date.html @@ -0,0 +1,92 @@ + + + + The Extend November 2014 Archive by date + + + + + +

November 2014 Archives by date

+ +

Starting: Thu Nov 6 14:31:23 CET 2014
+ Ending: Mon Nov 24 22:33:02 CET 2014
+ Messages: 9

+

+

+ Last message date: + Mon Nov 24 22:33:02 CET 2014
+ Archived on: Mon Nov 24 22:33:05 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-November/index.html b/_build/static/archives/extend/2014-November/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-November/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-November/subject.html b/_build/static/archives/extend/2014-November/subject.html new file mode 100644 index 00000000..08cc713a --- /dev/null +++ b/_build/static/archives/extend/2014-November/subject.html @@ -0,0 +1,92 @@ + + + + The Extend November 2014 Archive by subject + + + + + +

November 2014 Archives by subject

+ +

Starting: Thu Nov 6 14:31:23 CET 2014
+ Ending: Mon Nov 24 22:33:02 CET 2014
+ Messages: 9

+

+

+ Last message date: + Mon Nov 24 22:33:02 CET 2014
+ Archived on: Mon Nov 24 22:33:05 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-November/thread.html b/_build/static/archives/extend/2014-November/thread.html new file mode 100644 index 00000000..5032eebf --- /dev/null +++ b/_build/static/archives/extend/2014-November/thread.html @@ -0,0 +1,109 @@ + + + + The Extend November 2014 Archive by thread + + + + + +

November 2014 Archives by thread

+ +

Starting: Thu Nov 6 14:31:23 CET 2014
+ Ending: Mon Nov 24 22:33:02 CET 2014
+ Messages: 9

+

+

+ Last message date: + Mon Nov 24 22:33:02 CET 2014
+ Archived on: Mon Nov 24 22:33:05 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-October.txt b/_build/static/archives/extend/2014-October.txt new file mode 100644 index 00000000..be0a23b3 --- /dev/null +++ b/_build/static/archives/extend/2014-October.txt @@ -0,0 +1,223 @@ +From amol at hatwar.org Sun Oct 5 04:56:58 2014 +From: amol at hatwar.org (Amol Hatwar) +Date: Sun, 5 Oct 2014 08:26:58 +0530 +Subject: [99s-extend] Prevent resource creation on POST +Message-ID: <20141005025658.GA12424@newton.local> + +Hello, + +I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough... + +Here's what I have running: +A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body. + +Here's what I want done: +Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this? + +Cheers, + +AH + +From essen at ninenines.eu Sun Oct 5 09:49:00 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sun, 05 Oct 2014 10:49:00 +0300 +Subject: [99s-extend] Prevent resource creation on POST +In-Reply-To: <20141005025658.GA12424@newton.local> +References: <20141005025658.GA12424@newton.local> +Message-ID: <5430F7EC.4080306@ninenines.eu> + +If resource_exists = true, then POST doesn't create but update the +resource at the given URI. If what you are doing is something like +write-once resources then you will have to reject these cases manually +by returning halt at some point. + +On 10/05/2014 05:56 AM, Amol Hatwar wrote: +> Hello, +> +> I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough... +> +> Here's what I have running: +> A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body. +> +> Here's what I want done: +> Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this? +> +> Cheers, +> +> AH +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stefan.strigler at gmail.com Tue Oct 14 10:05:53 2014 +From: stefan.strigler at gmail.com (Stefan Strigler) +Date: Tue, 14 Oct 2014 10:05:53 +0200 +Subject: [99s-extend] PUT on new resource and status 201 +Message-ID: + +Hey, + +just subscribed yesterday and now that's already my first question. + +I'm referring to +http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you +have a PUT on a new resource the diagram suggests that the response's +status code depends on whether you've set a location and/or body. But when +looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always +return a 201. No matter what. I think the code is right, but the diagram +needs to be fixed. + +But then I'm not totally sure how to interpret +http://tools.ietf.org/html/rfc2616#section-10.2.2 which states + + The newly created resource can be referenced by the URI(s) + returned in the entity of the response, with the most specific URI + for the resource given by a Location header field. + + +Because currently it is totally possible to not have a location header +set (just as no body) for the response. In my opinion the current code +behaves good enough and it's up to the service to ensure the +requirements as stated by the RFC. Should cowboy enforce a header +field? Should it try to figure that out on its own? + + +Regards, + + +Stefan +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From lists at tuli.pe Tue Oct 14 10:42:54 2014 +From: lists at tuli.pe (Camille Troillard) +Date: Tue, 14 Oct 2014 10:42:54 +0200 +Subject: [99s-extend] PUT on new resource and status 201 +In-Reply-To: +References: +Message-ID: + +Hi Stefan, + + +On 14 Oct 2014, at 10:05, Stefan Strigler wrote: + +> just subscribed yesterday and now that's already my first question. +> +> I'm referring to http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you have a PUT on a new resource the diagram suggests that the response's status code depends on whether you've set a location and/or body. + +This is correct, I have experience this behaviour on Cowboy 1.0.0 and 2.0.0-pre.1. + + +> But when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always return a 201. No matter what. I think the code is right, but the diagram needs to be fixed. + +Could you be more specific? +I?m afraid it is not how it works for me. + + +> But then I'm not totally sure how to interpret http://tools.ietf.org/html/rfc2616#section-10.2.2 which states +> +> The newly created resource can be referenced by the URI(s) +> returned in the entity of the response, with the most specific URI +> for the resource given by a Location header field. +> +> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own? + +I think how Cowboy does is best at the moment. +I like to have the freedom to specify myself the Location, especially when PUT-ting new resources. + + +A bit off topic, I think this article is interesting regarding RFC-2616. + + https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead + +Given that, you might want to have a look at RFC-7231, section 3.1.4.2: + + http://tools.ietf.org/html/rfc7231#section-3.1.4.2. + + +Camille + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Oct 14 12:38:08 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 14 Oct 2014 12:38:08 +0200 +Subject: [99s-extend] PUT on new resource and status 201 +In-Reply-To: +References: +Message-ID: <543CFD10.1050701@ninenines.eu> + +Hi, + +On 10/14/2014 10:05 AM, Stefan Strigler wrote: +> I'm referring to +> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you +> have a PUT on a new resource the diagram suggests that the response's +> status code depends on whether you've set a location and/or body. But +> when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would +> always return a 201. No matter what. I think the code is right, but the +> diagram needs to be fixed. + +Yes it looks like you are on to something there. Please open a ticket +and I will look later on. There's another change near that area that +needs to be made with POST, I will look at both at the same time. + +> But then I'm not totally sure how to interpret +> http://tools.ietf.org/html/rfc2616#section-10.2.2 which states +> +> The newly created resource can be referenced by the URI(s) +> returned in the entity of the response, with the most specific URI +> for the resource given by a Location header field. +> +> +> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own? + +201 does not require a location header if the resource is created at the +path indicated by the request. Specifying a different URI is a rare +occurrence with PUT, it should only occur if you create the resource on +a different domain name (think a CDN pushing the file to a subdomain). + +And as Camille stated, forget RFC 2616, the various RFCs from httpbis is +where it's at now. + +-- +Lo?c Hoguin +http://ninenines.eu + +From David.Hiers at cdk.com Fri Oct 31 15:43:22 2014 +From: David.Hiers at cdk.com (Hiers, David) +Date: Fri, 31 Oct 2014 14:43:22 +0000 +Subject: [99s-extend] Cowboy, IE9, and HTTPS +Message-ID: + +Hello, + +Has anyone had trouble getting IE9 connecting to Cowboy over HTTPS? + +We're using Cowboy embedded in MongooseIM, and IE9 is giving us fits. + + +Thanks, + + + + +David + + +---------------------------------------------------------------------- +This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2014-October/000468.html b/_build/static/archives/extend/2014-October/000468.html new file mode 100644 index 00000000..d885c686 --- /dev/null +++ b/_build/static/archives/extend/2014-October/000468.html @@ -0,0 +1,72 @@ + + + + [99s-extend] Prevent resource creation on POST + + + + + + + + + + +

[99s-extend] Prevent resource creation on POST

+ Amol Hatwar + amol at hatwar.org +
+ Sun Oct 5 04:56:58 CEST 2014 +

+
+ +
Hello,
+
+I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough...
+
+Here's what I have running:
+A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body.
+
+Here's what I want done:
+Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this?
+
+Cheers,
+
+AH
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/000469.html b/_build/static/archives/extend/2014-October/000469.html new file mode 100644 index 00000000..edbb5ab7 --- /dev/null +++ b/_build/static/archives/extend/2014-October/000469.html @@ -0,0 +1,89 @@ + + + + [99s-extend] Prevent resource creation on POST + + + + + + + + + + +

[99s-extend] Prevent resource creation on POST

+ Loïc Hoguin + essen at ninenines.eu +
+ Sun Oct 5 09:49:00 CEST 2014 +

+
+ +
If resource_exists = true, then POST doesn't create but update the 
+resource at the given URI. If what you are doing is something like 
+write-once resources then you will have to reject these cases manually 
+by returning halt at some point.
+
+On 10/05/2014 05:56 AM, Amol Hatwar wrote:
+> Hello,
+>
+> I was recently tinkering with cowboy_rest and found that there is no way prevent resource creation in a POST request when it already exists. Either that, or I'm probably not doing something right or don't know enough...
+>
+> Here's what I have running:
+> A user tries to signup with a post request. To be successful, the username has to be unique. The resource_exists/2 method responds with proper true and false values by looking at the request body.
+>
+> Here's what I want done:
+> Iff the resource_exists callback returns true, I don't want the AcceptResource callback to run at all. Instead, I want to send a 4XX status and halt. Is there a canonical way of doing this?
+>
+> Cheers,
+>
+> AH
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/000470.html b/_build/static/archives/extend/2014-October/000470.html new file mode 100644 index 00000000..f2c4238c --- /dev/null +++ b/_build/static/archives/extend/2014-October/000470.html @@ -0,0 +1,95 @@ + + + + [99s-extend] PUT on new resource and status 201 + + + + + + + + + + +

[99s-extend] PUT on new resource and status 201

+ Stefan Strigler + stefan.strigler at gmail.com +
+ Tue Oct 14 10:05:53 CEST 2014 +

+
+ +
Hey,
+
+just subscribed yesterday and now that's already my first question.
+
+I'm referring to
+http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you
+have a PUT on a new resource the diagram suggests that the response's
+status code depends on whether you've set a location and/or body. But when
+looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always
+return a 201. No matter what. I think the code is right, but the diagram
+needs to be fixed.
+
+But then I'm not totally sure how to interpret
+http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
+
+   The newly created resource can be referenced by the URI(s)
+   returned in the entity of the response, with the most specific URI
+   for the resource given by a Location header field.
+
+
+Because currently it is totally possible to not have a location header
+set (just as no body) for the response. In my opinion the current code
+behaves good enough and it's up to the service to ensure the
+requirements as stated by the RFC. Should cowboy enforce a header
+field? Should it try to figure that out on its own?
+
+
+Regards,
+
+
+Stefan
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141014/d89bced6/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/000471.html b/_build/static/archives/extend/2014-October/000471.html new file mode 100644 index 00000000..6651b47d --- /dev/null +++ b/_build/static/archives/extend/2014-October/000471.html @@ -0,0 +1,105 @@ + + + + [99s-extend] PUT on new resource and status 201 + + + + + + + + + + +

[99s-extend] PUT on new resource and status 201

+ Camille Troillard + lists at tuli.pe +
+ Tue Oct 14 10:42:54 CEST 2014 +

+
+ +
Hi Stefan,
+
+
+On 14 Oct 2014, at 10:05, Stefan Strigler <stefan.strigler at gmail.com> wrote:
+
+> just subscribed yesterday and now that's already my first question.
+> 
+> I'm referring to http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you have a PUT on a new resource the diagram suggests that the response's status code depends on whether you've set a location and/or body.
+
+This is correct, I have experience this behaviour on Cowboy 1.0.0 and 2.0.0-pre.1.
+
+
+> But when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would always return a 201. No matter what. I think the code is right, but the diagram needs to be fixed. 
+
+Could you be more specific?
+I’m afraid it is not how it works for me.
+
+
+> But then I'm not totally sure how to interpret http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
+> 
+>    The newly created resource can be referenced by the URI(s)
+>    returned in the entity of the response, with the most specific URI
+>    for the resource given by a Location header field.
+> 
+> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own?
+
+I think how Cowboy does is best at the moment.
+I like to have the freedom to specify myself the Location, especially when PUT-ting new resources.
+
+
+A bit off topic, I think this article is interesting regarding RFC-2616.
+
+	https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead
+
+Given that, you might want to have a look at RFC-7231, section 3.1.4.2:
+
+	http://tools.ietf.org/html/rfc7231#section-3.1.4.2.
+
+
+Camille
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141014/77f74bf0/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/000472.html b/_build/static/archives/extend/2014-October/000472.html new file mode 100644 index 00000000..e1c3955e --- /dev/null +++ b/_build/static/archives/extend/2014-October/000472.html @@ -0,0 +1,97 @@ + + + + [99s-extend] PUT on new resource and status 201 + + + + + + + + + + +

[99s-extend] PUT on new resource and status 201

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Oct 14 12:38:08 CEST 2014 +

+
+ +
Hi,
+
+On 10/14/2014 10:05 AM, Stefan Strigler wrote:
+> I'm referring to
+> http://ninenines.eu/docs/en/cowboy/1.0/guide/rest_flowcharts/. Given you
+> have a PUT on a new resource the diagram suggests that the response's
+> status code depends on whether you've set a location and/or body. But
+> when looking at the code (v1.0.0) then cowboy_rest:maybe_created/2 would
+> always return a 201. No matter what. I think the code is right, but the
+> diagram needs to be fixed.
+
+Yes it looks like you are on to something there. Please open a ticket 
+and I will look later on. There's another change near that area that 
+needs to be made with POST, I will look at both at the same time.
+
+> But then I'm not totally sure how to interpret
+> http://tools.ietf.org/html/rfc2616#section-10.2.2 which states
+>
+>     The newly created resource can be referenced by the URI(s)
+>     returned in the entity of the response, with the most specific URI
+>     for the resource given by a Location header field.
+>
+>
+> Because currently it is totally possible to not have a location header set (just as no body) for the response. In my opinion the current code behaves good enough and it's up to the service to ensure the requirements as stated by the RFC. Should cowboy enforce a header field? Should it try to figure that out on its own?
+
+201 does not require a location header if the resource is created at the 
+path indicated by the request. Specifying a different URI is a rare 
+occurrence with PUT, it should only occur if you create the resource on 
+a different domain name (think a CDN pushing the file to a subdomain).
+
+And as Camille stated, forget RFC 2616, the various RFCs from httpbis is 
+where it's at now.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/000473.html b/_build/static/archives/extend/2014-October/000473.html new file mode 100644 index 00000000..ad2ee5ce --- /dev/null +++ b/_build/static/archives/extend/2014-October/000473.html @@ -0,0 +1,78 @@ + + + + [99s-extend] Cowboy, IE9, and HTTPS + + + + + + + + + + +

[99s-extend] Cowboy, IE9, and HTTPS

+ Hiers, David + David.Hiers at cdk.com +
+ Fri Oct 31 15:43:22 CET 2014 +

+
+ +
Hello,
+
+Has anyone had trouble getting IE9 connecting to Cowboy over HTTPS?
+
+We're using Cowboy embedded in MongooseIM, and IE9 is giving us fits.
+
+
+Thanks,
+
+
+
+
+David
+
+
+----------------------------------------------------------------------
+This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20141031/fc6724a7/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-October/author.html b/_build/static/archives/extend/2014-October/author.html new file mode 100644 index 00000000..24771b30 --- /dev/null +++ b/_build/static/archives/extend/2014-October/author.html @@ -0,0 +1,77 @@ + + + + The Extend October 2014 Archive by author + + + + + +

October 2014 Archives by author

+ +

Starting: Sun Oct 5 04:56:58 CEST 2014
+ Ending: Fri Oct 31 15:43:22 CET 2014
+ Messages: 6

+

+

+ Last message date: + Fri Oct 31 15:43:22 CET 2014
+ Archived on: Fri Oct 31 15:43:44 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-October/date.html b/_build/static/archives/extend/2014-October/date.html new file mode 100644 index 00000000..683cdab8 --- /dev/null +++ b/_build/static/archives/extend/2014-October/date.html @@ -0,0 +1,77 @@ + + + + The Extend October 2014 Archive by date + + + + + +

October 2014 Archives by date

+ +

Starting: Sun Oct 5 04:56:58 CEST 2014
+ Ending: Fri Oct 31 15:43:22 CET 2014
+ Messages: 6

+

+

+ Last message date: + Fri Oct 31 15:43:22 CET 2014
+ Archived on: Fri Oct 31 15:43:44 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-October/index.html b/_build/static/archives/extend/2014-October/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-October/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-October/subject.html b/_build/static/archives/extend/2014-October/subject.html new file mode 100644 index 00000000..248289eb --- /dev/null +++ b/_build/static/archives/extend/2014-October/subject.html @@ -0,0 +1,77 @@ + + + + The Extend October 2014 Archive by subject + + + + + +

October 2014 Archives by subject

+ +

Starting: Sun Oct 5 04:56:58 CEST 2014
+ Ending: Fri Oct 31 15:43:22 CET 2014
+ Messages: 6

+

+

+ Last message date: + Fri Oct 31 15:43:22 CET 2014
+ Archived on: Fri Oct 31 15:43:44 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-October/thread.html b/_build/static/archives/extend/2014-October/thread.html new file mode 100644 index 00000000..85acc3a6 --- /dev/null +++ b/_build/static/archives/extend/2014-October/thread.html @@ -0,0 +1,87 @@ + + + + The Extend October 2014 Archive by thread + + + + + +

October 2014 Archives by thread

+ +

Starting: Sun Oct 5 04:56:58 CEST 2014
+ Ending: Fri Oct 31 15:43:22 CET 2014
+ Messages: 6

+

+

+ Last message date: + Fri Oct 31 15:43:22 CET 2014
+ Archived on: Fri Oct 31 15:43:44 CET 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-September.txt b/_build/static/archives/extend/2014-September.txt new file mode 100644 index 00000000..58303855 --- /dev/null +++ b/_build/static/archives/extend/2014-September.txt @@ -0,0 +1,526 @@ +From paulo.ferraz.oliveira at gmail.com Mon Sep 15 23:24:20 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Mon, 15 Sep 2014 22:24:20 +0100 +Subject: [99s-extend] Using cowboy_req:body more than once per request +Message-ID: + +Hi. + +I recently implemented a checksum header (X-Checksum) that allows +validating the content of a request's body by hash comparison (just to give +you some context). I'm using the onrequest hook to affect all requests (and +be able to reply appropriately for non-conformance to the hash function +result) but can't figure out how to not read the request body twice, i.e. I +read it in the onrequest hook but later on need to read it again in the +route handler, but I can't (from the manual, for cowboy_req:body: "This +function can only be called once. Cowboy will not cache the result of this +call."). At the moment, and because the API consumers were in a hurry, the +solution I found (I understand it might be an ugly hack), was to read the +body, store it in the Req's meta (property body, for example) and then +access that property later on, instead of using cowboy_req:body. I'm not +quite happy with this solution and was wondering if there is anything more +elegant that I can implement. + +Thanks. + +Cheers. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From paulo.ferraz.oliveira at gmail.com Mon Sep 15 23:34:48 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Mon, 15 Sep 2014 22:34:48 +0100 +Subject: [99s-extend] :binding doc +Message-ID: + +Hi. + +This can be read in the cowboy_req:binding doc: "By default the value is a +binary, however constraints may change the type of this value (for example +automatically converting numbers to integer)." + +What constraints are we talking about here? + +Also, there's no reference to the fact that the bindings are URL-decoded, +even though they appear to be. + +Cheers. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From paulo.ferraz.oliveira at gmail.com Mon Sep 15 23:55:39 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Mon, 15 Sep 2014 22:55:39 +0100 +Subject: [99s-extend] :binding doc +Message-ID: + +OK, I guess "constraints" refers to this: +http://ninenines.eu/docs/en/cowboy/HEAD/guide/routing/#constraints + +:D + +Cheers. + +- Paulo F. Oliveira +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Sep 16 00:15:44 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 16 Sep 2014 00:15:44 +0200 +Subject: [99s-extend] :binding doc +In-Reply-To: +References: +Message-ID: <54176510.9040100@ninenines.eu> + +On 09/15/2014 11:34 PM, Paulo F. Oliveira wrote: +> Also, there's no reference to the fact that the bindings are +> URL-decoded, even though they appear to be. + +Cowboy decodes everything. If you feel it's helpful to mention, please +send a patch. + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Tue Sep 16 00:22:27 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 16 Sep 2014 00:22:27 +0200 +Subject: [99s-extend] Using cowboy_req:body more than once per request +In-Reply-To: +References: +Message-ID: <541766A3.4070309@ninenines.eu> + +It seems a bit weird to me to read the body and validate it before +validating the request itself. + +I would explicitly put these checks in the handler directly. This of +course means that there is no need to read it twice anymore. + +On 09/15/2014 11:24 PM, Paulo F. Oliveira wrote: +> Hi. +> +> I recently implemented a checksum header (X-Checksum) that allows +> validating the content of a request's body by hash comparison (just to +> give you some context). I'm using the onrequest hook to affect all +> requests (and be able to reply appropriately for non-conformance to the +> hash function result) but can't figure out how to not read the request +> body twice, i.e. I read it in the onrequest hook but later on need to +> read it again in the route handler, but I can't (from the manual, for +> cowboy_req:body: "This function can only be called once. Cowboy will not +> cache the result of this call."). At the moment, and because the API +> consumers were in a hurry, the solution I found (I understand it might +> be an ugly hack), was to read the body, store it in the Req's meta +> (property body, for example) and then access that property later on, +> instead of using cowboy_req:body. I'm not quite happy with this solution +> and was wondering if there is anything more elegant that I can implement. +> +> Thanks. +> +> Cheers. +> +> - Paulo F. Oliveira +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From paulo.ferraz.oliveira at gmail.com Tue Sep 16 00:35:20 2014 +From: paulo.ferraz.oliveira at gmail.com (Paulo F. Oliveira) +Date: Mon, 15 Sep 2014 23:35:20 +0100 +Subject: [99s-extend] Using cowboy_req:body more than once per request +In-Reply-To: <541766A3.4070309@ninenines.eu> +References: + <541766A3.4070309@ninenines.eu> +Message-ID: + +Hi. + +> It seems a bit weird to me to read the body and validate it before validating the request itself. + +It certainly seems like it, but I had no immediate solution and +instead of changing a dozen handlers, this seemed faster to implement +:D. I don't understand what you mean by "validating the request +itself". I read the header (I mentioned previously) and the body and +check one against the other. They are present and enough for the +_validator_ to make a decision, but I might be missing something here. + +> I would explicitly put these checks in the handler directly. This of course means that there is no need to read it twice anymore. + +I've been trying to find a way to easily share code between handlers +without having to rewrite a lot of code (even if I do decide to put +things in a library function - or several). I recently came across +https://github.com/opscode/mixer. Have you ever used it? + +Thanks. + +- Paulo F. Oliveira + +From essen at ninenines.eu Tue Sep 16 00:42:20 2014 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 16 Sep 2014 00:42:20 +0200 +Subject: [99s-extend] Using cowboy_req:body more than once per request +In-Reply-To: +References: <541766A3.4070309@ninenines.eu> + +Message-ID: <54176B4C.1060101@ninenines.eu> + +On 09/16/2014 12:35 AM, Paulo F. Oliveira wrote: +> Hi. +> +>> It seems a bit weird to me to read the body and validate it before validating the request itself. +> +> It certainly seems like it, but I had no immediate solution and +> instead of changing a dozen handlers, this seemed faster to implement +> :D. I don't understand what you mean by "validating the request +> itself". I read the header (I mentioned previously) and the body and +> check one against the other. They are present and enough for the +> _validator_ to make a decision, but I might be missing something here. + +Like, is it the right method? Are the bindings/qs parameters/headers +present and valid? And so on. The body should be the last thing you +check, due to how expensive it can be, not the first. + +>> I would explicitly put these checks in the handler directly. This of course means that there is no need to read it twice anymore. +> +> I've been trying to find a way to easily share code between handlers +> without having to rewrite a lot of code (even if I do decide to put +> things in a library function - or several). I recently came across +> https://github.com/opscode/mixer. Have you ever used it? + +I usually share code by writing functions. Then I call these functions +where needed. + +-- +Lo?c Hoguin +http://ninenines.eu + +From jmrepetti at gmail.com Mon Sep 29 18:52:16 2014 +From: jmrepetti at gmail.com (=?UTF-8?B?SnVhbiBNYXTDrWFz?=) +Date: Mon, 29 Sep 2014 18:52:16 +0200 +Subject: [99s-extend] Newbie, Cowboy + Websocket + Audio Recording +Message-ID: + +Hello list, I hope this is the right place to ask this. + +I'm learning Erlang, and I wanted to create a Cowboy app to record audio +from a web browser. + +Based on the websocket example in the Cowboy source code, I get the user +mic input and send this input to the websocket. + +I created a "recorder" module, which functionality is to save the data to +the a file. + + +*#rawe_handler.erl*-module(rawec_handler). +-behaviour(cowboy_websocket_handler). +...... +init(_, _, _) -> + case whereis(recorder) of + undefined -> + RecorderPid = recorder:start(), + register(recorder, RecorderPid); + _ -> ok + end, + {upgrade, protocol, cowboy_websocket}. +..... +websocket_handle(_Frame, Req, State) -> + RecorderPid = whereis(recorder), + RecorderPid ! {rec, _Frame/binary}, + {ok, Req, State}. + +*#recorder.erl* +-module(recorder). + +-export([start/0, recorder_fun/1]). +-compile([debug_info]). + +recorder_fun(IoDevice) -> + receive + {rec, Data} -> + ok = file:write(IoDevice, Data), + io:format(Data), + recorder_fun(IoDevice); + {stop, _} -> + %%Close file + file:close(IoDevice) + end. + +start() -> + {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write, +binary]), + spawn(recorder, recorder_fun, [IoDevice]). + + +When I start the console, and allow the microphone on the browser, I see +this error on the console: + +=ERROR REPORT==== 29-Sep-2014::18:13:03 === +Ranch listener http had connection process started with +cowboy_protocol:start_link/4 at <0.178.0> exit with reason: +*{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC, +DATA STREAM CONTINUES) + +Probably my approach to do this is totally wrong. I there any obvious +problem here? +Can someone point me to a right direction?. Maybe I should write directly +to a file in the *websocket_handle *funcion, but how can I keep a file +opened during the streaming? + +The github repo is here: https://github.com/jmrepetti/rawec with the whole +source code if you want to take a look. + + +Thanks in advance, +Matias. +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From edgurgel at gmail.com Tue Sep 30 00:53:26 2014 +From: edgurgel at gmail.com (Eduardo Gurgel) +Date: Tue, 30 Sep 2014 11:53:26 +1300 +Subject: [99s-extend] Newbie, Cowboy + Websocket + Audio Recording +In-Reply-To: +References: +Message-ID: + +Looking on the output it says: + +*{reason,badarith} *on this line: + +RecorderPid ! {rec, _Frame/binary}, + +This may help you somehow. + +BTW, variables starting with _ are usually used to show unused variables +and stop warnings from the compiler. + +On 30 September 2014 05:52, Juan Mat?as wrote: + +> Hello list, I hope this is the right place to ask this. +> +> I'm learning Erlang, and I wanted to create a Cowboy app to record audio +> from a web browser. +> +> Based on the websocket example in the Cowboy source code, I get the user +> mic input and send this input to the websocket. +> +> I created a "recorder" module, which functionality is to save the data to +> the a file. +> +> +> *#rawe_handler.erl*-module(rawec_handler). +> -behaviour(cowboy_websocket_handler). +> ...... +> init(_, _, _) -> +> case whereis(recorder) of +> undefined -> +> RecorderPid = recorder:start(), +> register(recorder, RecorderPid); +> _ -> ok +> end, +> {upgrade, protocol, cowboy_websocket}. +> ..... +> websocket_handle(_Frame, Req, State) -> +> RecorderPid = whereis(recorder), +> RecorderPid ! {rec, _Frame/binary}, +> {ok, Req, State}. +> +> *#recorder.erl* +> -module(recorder). +> +> -export([start/0, recorder_fun/1]). +> -compile([debug_info]). +> +> recorder_fun(IoDevice) -> +> receive +> {rec, Data} -> +> ok = file:write(IoDevice, Data), +> io:format(Data), +> recorder_fun(IoDevice); +> {stop, _} -> +> %%Close file +> file:close(IoDevice) +> end. +> +> start() -> +> {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write, +> binary]), +> spawn(recorder, recorder_fun, [IoDevice]). +> +> +> When I start the console, and allow the microphone on the browser, I see +> this error on the console: +> +> =ERROR REPORT==== 29-Sep-2014::18:13:03 === +> Ranch listener http had connection process started with +> cowboy_protocol:start_link/4 at <0.178.0> exit with reason: +> *{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC, +> DATA STREAM CONTINUES) +> +> Probably my approach to do this is totally wrong. I there any obvious +> problem here? +> Can someone point me to a right direction?. Maybe I should write directly +> to a file in the *websocket_handle *funcion, but how can I keep a file +> opened during the streaming? +> +> The github repo is here: https://github.com/jmrepetti/rawec with the +> whole source code if you want to take a look. +> +> +> Thanks in advance, +> Matias. +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> + + +-- +Eduardo +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From jmrepetti at gmail.com Tue Sep 30 12:38:15 2014 +From: jmrepetti at gmail.com (=?UTF-8?B?SnVhbiBNYXTDrWFz?=) +Date: Tue, 30 Sep 2014 12:38:15 +0200 +Subject: [99s-extend] Newbie, Cowboy + Websocket + Audio Recording +In-Reply-To: +References: + +Message-ID: + +Thanks, that fixed the error. Now I'm having other but I'll investigate. + + + +On Tue, Sep 30, 2014 at 12:53 AM, Eduardo Gurgel wrote: + +> Looking on the output it says: +> +> *{reason,badarith} *on this line: +> +> RecorderPid ! {rec, _Frame/binary}, +> +> This may help you somehow. +> +> BTW, variables starting with _ are usually used to show unused variables +> and stop warnings from the compiler. +> +> On 30 September 2014 05:52, Juan Mat?as wrote: +> +>> Hello list, I hope this is the right place to ask this. +>> +>> I'm learning Erlang, and I wanted to create a Cowboy app to record audio +>> from a web browser. +>> +>> Based on the websocket example in the Cowboy source code, I get the user +>> mic input and send this input to the websocket. +>> +>> I created a "recorder" module, which functionality is to save the data to +>> the a file. +>> +>> +>> *#rawe_handler.erl*-module(rawec_handler). +>> -behaviour(cowboy_websocket_handler). +>> ...... +>> init(_, _, _) -> +>> case whereis(recorder) of +>> undefined -> +>> RecorderPid = recorder:start(), +>> register(recorder, RecorderPid); +>> _ -> ok +>> end, +>> {upgrade, protocol, cowboy_websocket}. +>> ..... +>> websocket_handle(_Frame, Req, State) -> +>> RecorderPid = whereis(recorder), +>> RecorderPid ! {rec, _Frame/binary}, +>> {ok, Req, State}. +>> +>> *#recorder.erl* +>> -module(recorder). +>> +>> -export([start/0, recorder_fun/1]). +>> -compile([debug_info]). +>> +>> recorder_fun(IoDevice) -> +>> receive +>> {rec, Data} -> +>> ok = file:write(IoDevice, Data), +>> io:format(Data), +>> recorder_fun(IoDevice); +>> {stop, _} -> +>> %%Close file +>> file:close(IoDevice) +>> end. +>> +>> start() -> +>> {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write, +>> binary]), +>> spawn(recorder, recorder_fun, [IoDevice]). +>> +>> +>> When I start the console, and allow the microphone on the browser, I see +>> this error on the console: +>> +>> =ERROR REPORT==== 29-Sep-2014::18:13:03 === +>> Ranch listener http had connection process started with +>> cowboy_protocol:start_link/4 at <0.178.0> exit with reason: +>> *{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC, +>> DATA STREAM CONTINUES) +>> +>> Probably my approach to do this is totally wrong. I there any obvious +>> problem here? +>> Can someone point me to a right direction?. Maybe I should write directly +>> to a file in the *websocket_handle *funcion, but how can I keep a file +>> opened during the streaming? +>> +>> The github repo is here: https://github.com/jmrepetti/rawec with the +>> whole source code if you want to take a look. +>> +>> +>> Thanks in advance, +>> Matias. +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> +> +> -- +> Eduardo +> + + + +-- +Mat?as +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2014-September/000458.html b/_build/static/archives/extend/2014-September/000458.html new file mode 100644 index 00000000..8b93f654 --- /dev/null +++ b/_build/static/archives/extend/2014-September/000458.html @@ -0,0 +1,85 @@ + + + + [99s-extend] Using cowboy_req:body more than once per request + + + + + + + + + + +

[99s-extend] Using cowboy_req:body more than once per request

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Mon Sep 15 23:24:20 CEST 2014 +

+
+ +
Hi.
+
+I recently implemented a checksum header (X-Checksum) that allows
+validating the content of a request's body by hash comparison (just to give
+you some context). I'm using the onrequest hook to affect all requests (and
+be able to reply appropriately for non-conformance to the hash function
+result) but can't figure out how to not read the request body twice, i.e. I
+read it in the onrequest hook but later on need to read it again in the
+route handler, but I can't (from the manual, for cowboy_req:body: "This
+function can only be called once. Cowboy will not cache the result of this
+call."). At the moment, and because the API consumers were in a hurry, the
+solution I found (I understand it might be an ugly hack), was to read the
+body, store it in the Req's meta (property body, for example) and then
+access that property later on, instead of using cowboy_req:body. I'm not
+quite happy with this solution and was wondering if there is anything more
+elegant that I can implement.
+
+Thanks.
+
+Cheers.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140915/26d4e023/attachment-0001.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000459.html b/_build/static/archives/extend/2014-September/000459.html new file mode 100644 index 00000000..c360f518 --- /dev/null +++ b/_build/static/archives/extend/2014-September/000459.html @@ -0,0 +1,81 @@ + + + + [99s-extend] :binding doc + + + + + + + + + + +

[99s-extend] :binding doc

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Mon Sep 15 23:34:48 CEST 2014 +

+
+ +
Hi.
+
+This can be read in the cowboy_req:binding doc: "By default the value is a
+binary, however constraints may change the type of this value (for example
+automatically converting numbers to integer)."
+
+What constraints are we talking about here?
+
+Also, there's no reference to the fact that the bindings are URL-decoded,
+even though they appear to be.
+
+Cheers.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140915/5f3302e4/attachment.html>
+
+ + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000460.html b/_build/static/archives/extend/2014-September/000460.html new file mode 100644 index 00000000..a544862a --- /dev/null +++ b/_build/static/archives/extend/2014-September/000460.html @@ -0,0 +1,75 @@ + + + + [99s-extend] :binding doc + + + + + + + + + + +

[99s-extend] :binding doc

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Mon Sep 15 23:55:39 CEST 2014 +

+
+ +
OK, I guess "constraints" refers to this:
+http://ninenines.eu/docs/en/cowboy/HEAD/guide/routing/#constraints
+
+:D
+
+Cheers.
+
+- Paulo F. Oliveira
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140915/d97a6072/attachment.html>
+
+ + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000461.html b/_build/static/archives/extend/2014-September/000461.html new file mode 100644 index 00000000..68f764da --- /dev/null +++ b/_build/static/archives/extend/2014-September/000461.html @@ -0,0 +1,74 @@ + + + + [99s-extend] :binding doc + + + + + + + + + + +

[99s-extend] :binding doc

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Sep 16 00:15:44 CEST 2014 +

+
+ +
On 09/15/2014 11:34 PM, Paulo F. Oliveira wrote:
+> Also, there's no reference to the fact that the bindings are
+> URL-decoded, even though they appear to be.
+
+Cowboy decodes everything. If you feel it's helpful to mention, please 
+send a patch.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000462.html b/_build/static/archives/extend/2014-September/000462.html new file mode 100644 index 00000000..f8727d7c --- /dev/null +++ b/_build/static/archives/extend/2014-September/000462.html @@ -0,0 +1,101 @@ + + + + [99s-extend] Using cowboy_req:body more than once per request + + + + + + + + + + +

[99s-extend] Using cowboy_req:body more than once per request

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Sep 16 00:22:27 CEST 2014 +

+
+ +
It seems a bit weird to me to read the body and validate it before 
+validating the request itself.
+
+I would explicitly put these checks in the handler directly. This of 
+course means that there is no need to read it twice anymore.
+
+On 09/15/2014 11:24 PM, Paulo F. Oliveira wrote:
+> Hi.
+>
+> I recently implemented a checksum header (X-Checksum) that allows
+> validating the content of a request's body by hash comparison (just to
+> give you some context). I'm using the onrequest hook to affect all
+> requests (and be able to reply appropriately for non-conformance to the
+> hash function result) but can't figure out how to not read the request
+> body twice, i.e. I read it in the onrequest hook but later on need to
+> read it again in the route handler, but I can't (from the manual, for
+> cowboy_req:body: "This function can only be called once. Cowboy will not
+> cache the result of this call."). At the moment, and because the API
+> consumers were in a hurry, the solution I found (I understand it might
+> be an ugly hack), was to read the body, store it in the Req's meta
+> (property body, for example) and then access that property later on,
+> instead of using cowboy_req:body. I'm not quite happy with this solution
+> and was wondering if there is anything more elegant that I can implement.
+>
+> Thanks.
+>
+> Cheers.
+>
+> - Paulo F. Oliveira
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000463.html b/_build/static/archives/extend/2014-September/000463.html new file mode 100644 index 00000000..1e618983 --- /dev/null +++ b/_build/static/archives/extend/2014-September/000463.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Using cowboy_req:body more than once per request + + + + + + + + + + +

[99s-extend] Using cowboy_req:body more than once per request

+ Paulo F. Oliveira + paulo.ferraz.oliveira at gmail.com +
+ Tue Sep 16 00:35:20 CEST 2014 +

+
+ +
Hi.
+
+> It seems a bit weird to me to read the body and validate it before validating the request itself.
+
+It certainly seems like it, but I had no immediate solution and
+instead of changing a dozen handlers, this seemed faster to implement
+:D. I don't understand what you mean by "validating the request
+itself". I read the header (I mentioned previously) and the body and
+check one against the other. They are present and enough for the
+_validator_ to make a decision, but I might be missing something here.
+
+> I would explicitly put these checks in the handler directly. This of course means that there is no need to read it twice anymore.
+
+I've been trying to find a way to easily share code between handlers
+without having to rewrite a lot of code (even if I do decide to put
+things in a library function - or several). I recently came across
+https://github.com/opscode/mixer. Have you ever used it?
+
+Thanks.
+
+- Paulo F. Oliveira
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000464.html b/_build/static/archives/extend/2014-September/000464.html new file mode 100644 index 00000000..2df89a6e --- /dev/null +++ b/_build/static/archives/extend/2014-September/000464.html @@ -0,0 +1,89 @@ + + + + [99s-extend] Using cowboy_req:body more than once per request + + + + + + + + + + +

[99s-extend] Using cowboy_req:body more than once per request

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Sep 16 00:42:20 CEST 2014 +

+
+ +
On 09/16/2014 12:35 AM, Paulo F. Oliveira wrote:
+> Hi.
+>
+>> It seems a bit weird to me to read the body and validate it before validating the request itself.
+>
+> It certainly seems like it, but I had no immediate solution and
+> instead of changing a dozen handlers, this seemed faster to implement
+> :D. I don't understand what you mean by "validating the request
+> itself". I read the header (I mentioned previously) and the body and
+> check one against the other. They are present and enough for the
+> _validator_ to make a decision, but I might be missing something here.
+
+Like, is it the right method? Are the bindings/qs parameters/headers 
+present and valid? And so on. The body should be the last thing you 
+check, due to how expensive it can be, not the first.
+
+>> I would explicitly put these checks in the handler directly. This of course means that there is no need to read it twice anymore.
+>
+> I've been trying to find a way to easily share code between handlers
+> without having to rewrite a lot of code (even if I do decide to put
+> things in a library function - or several). I recently came across
+> https://github.com/opscode/mixer. Have you ever used it?
+
+I usually share code by writing functions. Then I call these functions 
+where needed.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000465.html b/_build/static/archives/extend/2014-September/000465.html new file mode 100644 index 00000000..66ac7abc --- /dev/null +++ b/_build/static/archives/extend/2014-September/000465.html @@ -0,0 +1,137 @@ + + + + [99s-extend] Newbie, Cowboy + Websocket + Audio Recording + + + + + + + + + + +

[99s-extend] Newbie, Cowboy + Websocket + Audio Recording

+ Juan Matías + jmrepetti at gmail.com +
+ Mon Sep 29 18:52:16 CEST 2014 +

+
+ +
Hello list, I hope this is the right place to ask this.
+
+I'm learning Erlang, and I wanted to create a Cowboy app to record audio
+from a web browser.
+
+Based on the websocket example in the Cowboy source code, I get the user
+mic input and send this input to the websocket.
+
+I created a "recorder" module, which functionality is to save the data to
+the a file.
+
+
+*#rawe_handler.erl*-module(rawec_handler).
+-behaviour(cowboy_websocket_handler).
+......
+init(_, _, _) ->
+  case whereis(recorder) of
+    undefined ->
+        RecorderPid = recorder:start(),
+        register(recorder, RecorderPid);
+    _ -> ok
+  end,
+    {upgrade, protocol, cowboy_websocket}.
+.....
+websocket_handle(_Frame, Req, State) ->
+  RecorderPid = whereis(recorder),
+  RecorderPid ! {rec, _Frame/binary},
+    {ok, Req, State}.
+
+*#recorder.erl*
+-module(recorder).
+
+-export([start/0, recorder_fun/1]).
+-compile([debug_info]).
+
+recorder_fun(IoDevice) ->
+  receive
+    {rec, Data} ->
+      ok = file:write(IoDevice, Data),
+      io:format(Data),
+      recorder_fun(IoDevice);
+    {stop, _} ->
+      %%Close file
+      file:close(IoDevice)
+    end.
+
+start() ->
+  {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write,
+binary]),
+  spawn(recorder, recorder_fun, [IoDevice]).
+
+
+When I start the console, and allow the microphone on the browser, I see
+this error on the console:
+
+=ERROR REPORT==== 29-Sep-2014::18:13:03 ===
+Ranch listener http had connection process started with
+cowboy_protocol:start_link/4 at <0.178.0> exit with reason:
+*{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC,
+DATA STREAM CONTINUES)
+
+Probably my approach to do this is totally wrong. I there any obvious
+problem here?
+Can someone point me to a right direction?. Maybe I should write directly
+to a file in the *websocket_handle *funcion, but how can I keep a file
+opened during the streaming?
+
+The github repo is here: https://github.com/jmrepetti/rawec with the whole
+source code if you want to take a look.
+
+
+Thanks in advance,
+Matias.
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140929/84fe21a4/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000466.html b/_build/static/archives/extend/2014-September/000466.html new file mode 100644 index 00000000..94dd1886 --- /dev/null +++ b/_build/static/archives/extend/2014-September/000466.html @@ -0,0 +1,161 @@ + + + + [99s-extend] Newbie, Cowboy + Websocket + Audio Recording + + + + + + + + + + +

[99s-extend] Newbie, Cowboy + Websocket + Audio Recording

+ Eduardo Gurgel + edgurgel at gmail.com +
+ Tue Sep 30 00:53:26 CEST 2014 +

+
+ +
Looking on the output it says:
+
+*{reason,badarith} *on this line:
+
+RecorderPid ! {rec, _Frame/binary},
+
+This may help you somehow.
+
+BTW, variables starting with _ are usually used to show unused variables
+and stop warnings from the compiler.
+
+On 30 September 2014 05:52, Juan Matías <jmrepetti at gmail.com> wrote:
+
+> Hello list, I hope this is the right place to ask this.
+>
+> I'm learning Erlang, and I wanted to create a Cowboy app to record audio
+> from a web browser.
+>
+> Based on the websocket example in the Cowboy source code, I get the user
+> mic input and send this input to the websocket.
+>
+> I created a "recorder" module, which functionality is to save the data to
+> the a file.
+>
+>
+> *#rawe_handler.erl*-module(rawec_handler).
+> -behaviour(cowboy_websocket_handler).
+> ......
+> init(_, _, _) ->
+>   case whereis(recorder) of
+>     undefined ->
+>         RecorderPid = recorder:start(),
+>         register(recorder, RecorderPid);
+>     _ -> ok
+>   end,
+>     {upgrade, protocol, cowboy_websocket}.
+> .....
+> websocket_handle(_Frame, Req, State) ->
+>   RecorderPid = whereis(recorder),
+>   RecorderPid ! {rec, _Frame/binary},
+>     {ok, Req, State}.
+>
+> *#recorder.erl*
+> -module(recorder).
+>
+> -export([start/0, recorder_fun/1]).
+> -compile([debug_info]).
+>
+> recorder_fun(IoDevice) ->
+>   receive
+>     {rec, Data} ->
+>       ok = file:write(IoDevice, Data),
+>       io:format(Data),
+>       recorder_fun(IoDevice);
+>     {stop, _} ->
+>       %%Close file
+>       file:close(IoDevice)
+>     end.
+>
+> start() ->
+>   {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write,
+> binary]),
+>   spawn(recorder, recorder_fun, [IoDevice]).
+>
+>
+> When I start the console, and allow the microphone on the browser, I see
+> this error on the console:
+>
+> =ERROR REPORT==== 29-Sep-2014::18:13:03 ===
+> Ranch listener http had connection process started with
+> cowboy_protocol:start_link/4 at <0.178.0> exit with reason:
+> *{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC,
+> DATA STREAM CONTINUES)
+>
+> Probably my approach to do this is totally wrong. I there any obvious
+> problem here?
+> Can someone point me to a right direction?. Maybe I should write directly
+> to a file in the *websocket_handle *funcion, but how can I keep a file
+> opened during the streaming?
+>
+> The github repo is here: https://github.com/jmrepetti/rawec with the
+> whole source code if you want to take a look.
+>
+>
+> Thanks in advance,
+> Matias.
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+>
+
+
+-- 
+Eduardo
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140930/6d952ce6/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/000467.html b/_build/static/archives/extend/2014-September/000467.html new file mode 100644 index 00000000..722b40d2 --- /dev/null +++ b/_build/static/archives/extend/2014-September/000467.html @@ -0,0 +1,170 @@ + + + + [99s-extend] Newbie, Cowboy + Websocket + Audio Recording + + + + + + + + + + +

[99s-extend] Newbie, Cowboy + Websocket + Audio Recording

+ Juan Matías + jmrepetti at gmail.com +
+ Tue Sep 30 12:38:15 CEST 2014 +

+
+ +
Thanks, that fixed the error. Now I'm having other but I'll investigate.
+
+
+
+On Tue, Sep 30, 2014 at 12:53 AM, Eduardo Gurgel <edgurgel at gmail.com> wrote:
+
+> Looking on the output it says:
+>
+> *{reason,badarith} *on this line:
+>
+> RecorderPid ! {rec, _Frame/binary},
+>
+> This may help you somehow.
+>
+> BTW, variables starting with _ are usually used to show unused variables
+> and stop warnings from the compiler.
+>
+> On 30 September 2014 05:52, Juan Matías <jmrepetti at gmail.com> wrote:
+>
+>> Hello list, I hope this is the right place to ask this.
+>>
+>> I'm learning Erlang, and I wanted to create a Cowboy app to record audio
+>> from a web browser.
+>>
+>> Based on the websocket example in the Cowboy source code, I get the user
+>> mic input and send this input to the websocket.
+>>
+>> I created a "recorder" module, which functionality is to save the data to
+>> the a file.
+>>
+>>
+>> *#rawe_handler.erl*-module(rawec_handler).
+>> -behaviour(cowboy_websocket_handler).
+>> ......
+>> init(_, _, _) ->
+>>   case whereis(recorder) of
+>>     undefined ->
+>>         RecorderPid = recorder:start(),
+>>         register(recorder, RecorderPid);
+>>     _ -> ok
+>>   end,
+>>     {upgrade, protocol, cowboy_websocket}.
+>> .....
+>> websocket_handle(_Frame, Req, State) ->
+>>   RecorderPid = whereis(recorder),
+>>   RecorderPid ! {rec, _Frame/binary},
+>>     {ok, Req, State}.
+>>
+>> *#recorder.erl*
+>> -module(recorder).
+>>
+>> -export([start/0, recorder_fun/1]).
+>> -compile([debug_info]).
+>>
+>> recorder_fun(IoDevice) ->
+>>   receive
+>>     {rec, Data} ->
+>>       ok = file:write(IoDevice, Data),
+>>       io:format(Data),
+>>       recorder_fun(IoDevice);
+>>     {stop, _} ->
+>>       %%Close file
+>>       file:close(IoDevice)
+>>     end.
+>>
+>> start() ->
+>>   {ok, IoDevice} = file:open("/tmp/test_binary.wav", [write,
+>> binary]),
+>>   spawn(recorder, recorder_fun, [IoDevice]).
+>>
+>>
+>> When I start the console, and allow the microphone on the browser, I see
+>> this error on the console:
+>>
+>> =ERROR REPORT==== 29-Sep-2014::18:13:03 ===
+>> Ranch listener http had connection process started with
+>> cowboy_protocol:start_link/4 at <0.178.0> exit with reason:
+>> *{[{reason,badarith},{mfa,{rawec_handler,websocket_handle,3*}},{stacktrace,[{rawec_handler,websocket_handle,3,[{file,"src/rawec_handler.erl"},{line,35}]},{cowboy_websocket,handler_call,7,[{file,"src/cowboy_websocket.erl"},{line,588}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,435}]}]},{msg,{binary,<<0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0....(ETC,
+>> DATA STREAM CONTINUES)
+>>
+>> Probably my approach to do this is totally wrong. I there any obvious
+>> problem here?
+>> Can someone point me to a right direction?. Maybe I should write directly
+>> to a file in the *websocket_handle *funcion, but how can I keep a file
+>> opened during the streaming?
+>>
+>> The github repo is here: https://github.com/jmrepetti/rawec with the
+>> whole source code if you want to take a look.
+>>
+>>
+>> Thanks in advance,
+>> Matias.
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>
+>
+> --
+> Eduardo
+>
+
+
+
+-- 
+Matías
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20140930/ef46837f/attachment.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2014-September/author.html b/_build/static/archives/extend/2014-September/author.html new file mode 100644 index 00000000..a559a789 --- /dev/null +++ b/_build/static/archives/extend/2014-September/author.html @@ -0,0 +1,97 @@ + + + + The Extend September 2014 Archive by author + + + + + +

September 2014 Archives by author

+ +

Starting: Mon Sep 15 23:24:20 CEST 2014
+ Ending: Tue Sep 30 12:38:15 CEST 2014
+ Messages: 10

+

+

+ Last message date: + Tue Sep 30 12:38:15 CEST 2014
+ Archived on: Tue Sep 30 12:45:20 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-September/date.html b/_build/static/archives/extend/2014-September/date.html new file mode 100644 index 00000000..85c9135a --- /dev/null +++ b/_build/static/archives/extend/2014-September/date.html @@ -0,0 +1,97 @@ + + + + The Extend September 2014 Archive by date + + + + + +

September 2014 Archives by date

+ +

Starting: Mon Sep 15 23:24:20 CEST 2014
+ Ending: Tue Sep 30 12:38:15 CEST 2014
+ Messages: 10

+

+

+ Last message date: + Tue Sep 30 12:38:15 CEST 2014
+ Archived on: Tue Sep 30 12:45:20 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-September/index.html b/_build/static/archives/extend/2014-September/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2014-September/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2014-September/subject.html b/_build/static/archives/extend/2014-September/subject.html new file mode 100644 index 00000000..47e15aa1 --- /dev/null +++ b/_build/static/archives/extend/2014-September/subject.html @@ -0,0 +1,97 @@ + + + + The Extend September 2014 Archive by subject + + + + + +

September 2014 Archives by subject

+ +

Starting: Mon Sep 15 23:24:20 CEST 2014
+ Ending: Tue Sep 30 12:38:15 CEST 2014
+ Messages: 10

+

+

+ Last message date: + Tue Sep 30 12:38:15 CEST 2014
+ Archived on: Tue Sep 30 12:45:20 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2014-September/thread.html b/_build/static/archives/extend/2014-September/thread.html new file mode 100644 index 00000000..0c9a6ce2 --- /dev/null +++ b/_build/static/archives/extend/2014-September/thread.html @@ -0,0 +1,119 @@ + + + + The Extend September 2014 Archive by thread + + + + + +

September 2014 Archives by thread

+ +

Starting: Mon Sep 15 23:24:20 CEST 2014
+ Ending: Tue Sep 30 12:38:15 CEST 2014
+ Messages: 10

+

+

+ Last message date: + Tue Sep 30 12:38:15 CEST 2014
+ Archived on: Tue Sep 30 12:45:20 CEST 2014 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-April.txt b/_build/static/archives/extend/2015-April.txt new file mode 100644 index 00000000..5d6e0f90 --- /dev/null +++ b/_build/static/archives/extend/2015-April.txt @@ -0,0 +1,134 @@ +From samset at wanadoo.fr Wed Apr 22 22:56:01 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Wed, 22 Apr 2015 22:56:01 +0200 +Subject: [99s-extend] cowboy_websocket_handler +Message-ID: <43C48B2E-0396-43E0-B82C-E524C8274004@wanadoo.fr> + +Hi there, + +I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler : +- is it an OTP gen_ instance ? +- how/where the websocket_handle() is called ? +- how websocket_info() relates to the Transport:send() operation and where/how this latter function is called? + +I could not find the cowboy_websocket_handler behavior in the src dir. I guess i?ve missed something. +The code is clean but difficult to decipher by a erlang padawan like me. + +Why do i need to understand this ? + +I would like to write a generic tcp transport layer that provides an interface like the cowboy_xxx_handler to my protocol stack. +Of course i will use ranch underneath. + +Neither the examples provided with ranch nor the ftp server tutorial reveals the sophisticated architecture used to handover data/context to the handler and to get reply data from the handler. + +Thank you for your help. + +Samir Sow + + +From essen at ninenines.eu Wed Apr 22 23:18:29 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 23 Apr 2015 00:18:29 +0300 +Subject: [99s-extend] cowboy_websocket_handler +In-Reply-To: <43C48B2E-0396-43E0-B82C-E524C8274004@wanadoo.fr> +References: <43C48B2E-0396-43E0-B82C-E524C8274004@wanadoo.fr> +Message-ID: <55381025.6070607@ninenines.eu> + +Hello, + +On 04/22/2015 11:56 PM, Samir Sow wrote: +> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler : +> - is it an OTP gen_ instance ? +> - how/where the websocket_handle() is called ? +> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called? +> +> I could not find the cowboy_websocket_handler behavior in the src dir. I guess i?ve missed something. +> The code is clean but difficult to decipher by a erlang padawan like me. + +Presumably you are looking in master. cowboy_websocket does that in +master now. cowboy_websocket_handler is in Cowboy 1.0. + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Wed Apr 22 23:39:29 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Wed, 22 Apr 2015 23:39:29 +0200 +Subject: [99s-extend] cowboy_websocket_handler +In-Reply-To: <55381025.6070607@ninenines.eu> +References: <43C48B2E-0396-43E0-B82C-E524C8274004@wanadoo.fr> + <55381025.6070607@ninenines.eu> +Message-ID: <55F4A36D-6FEF-47B4-B02F-D3B3FA74732D@wanadoo.fr> + +Thanks. +Still i can?t figure out how you manage the data transmission from/to handler via the websocket_handle() and websocket_info() function. + +Samir + +> On 22 avr. 2015, at 23:18, Lo?c Hoguin wrote: +> +> Hello, +> +> On 04/22/2015 11:56 PM, Samir Sow wrote: +>> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler : +>> - is it an OTP gen_ instance ? +>> - how/where the websocket_handle() is called ? +>> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called? +>> +>> I could not find the cowboy_websocket_handler behavior in the src dir. I guess i?ve missed something. +>> The code is clean but difficult to decipher by a erlang padawan like me. +> +> Presumably you are looking in master. cowboy_websocket does that in master now. cowboy_websocket_handler is in Cowboy 1.0. +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Thu Apr 23 10:55:23 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 23 Apr 2015 11:55:23 +0300 +Subject: [99s-extend] cowboy_websocket_handler +In-Reply-To: <55F4A36D-6FEF-47B4-B02F-D3B3FA74732D@wanadoo.fr> +References: <43C48B2E-0396-43E0-B82C-E524C8274004@wanadoo.fr> + <55381025.6070607@ninenines.eu> + <55F4A36D-6FEF-47B4-B02F-D3B3FA74732D@wanadoo.fr> +Message-ID: <5538B37B.6080501@ninenines.eu> + +It's a simple function call. + +Assuming the variable Handler contains the name of the module, it's just +doing Handler:websocket_info(Info, Req, State) and then checks the +return value. + +On 04/23/2015 12:39 AM, Samir Sow wrote: +> Thanks. +> Still i can?t figure out how you manage the data transmission from/to handler via the websocket_handle() and websocket_info() function. +> +> Samir +> +>> On 22 avr. 2015, at 23:18, Lo?c Hoguin wrote: +>> +>> Hello, +>> +>> On 04/22/2015 11:56 PM, Samir Sow wrote: +>>> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler : +>>> - is it an OTP gen_ instance ? +>>> - how/where the websocket_handle() is called ? +>>> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called? +>>> +>>> I could not find the cowboy_websocket_handler behavior in the src dir. I guess i?ve missed something. +>>> The code is clean but difficult to decipher by a erlang padawan like me. +>> +>> Presumably you are looking in master. cowboy_websocket does that in master now. cowboy_websocket_handler is in Cowboy 1.0. +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + diff --git a/_build/static/archives/extend/2015-April/000527.html b/_build/static/archives/extend/2015-April/000527.html new file mode 100644 index 00000000..3b29489d --- /dev/null +++ b/_build/static/archives/extend/2015-April/000527.html @@ -0,0 +1,80 @@ + + + + [99s-extend] cowboy_websocket_handler + + + + + + + + + + +

[99s-extend] cowboy_websocket_handler

+ Samir Sow + samset at wanadoo.fr +
+ Wed Apr 22 22:56:01 CEST 2015 +

+
+ +
Hi there,
+
+I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler  :
+-  is it an OTP gen_ instance ?
+- how/where the websocket_handle() is called ?
+- how websocket_info() relates to the Transport:send() operation and where/how this latter function is called?
+
+I  could not find the cowboy_websocket_handler behavior in the src dir. I guess i’ve missed something.
+The code is clean but difficult to decipher by a erlang padawan like me.
+
+Why do i need to understand this ?
+
+I would like to write a generic tcp transport layer that provides an interface like the cowboy_xxx_handler to my protocol stack.
+Of course i will use ranch underneath.
+
+Neither the examples provided with ranch nor the ftp server tutorial reveals the sophisticated architecture used to handover data/context to the handler and to get reply data from the handler.
+
+Thank you for your help.
+
+Samir Sow
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-April/000528.html b/_build/static/archives/extend/2015-April/000528.html new file mode 100644 index 00000000..b2d9bb96 --- /dev/null +++ b/_build/static/archives/extend/2015-April/000528.html @@ -0,0 +1,78 @@ + + + + [99s-extend] cowboy_websocket_handler + + + + + + + + + + +

[99s-extend] cowboy_websocket_handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Apr 22 23:18:29 CEST 2015 +

+
+ +
Hello,
+
+On 04/22/2015 11:56 PM, Samir Sow wrote:
+> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler  :
+> -  is it an OTP gen_ instance ?
+> - how/where the websocket_handle() is called ?
+> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called?
+>
+> I  could not find the cowboy_websocket_handler behavior in the src dir. I guess i’ve missed something.
+> The code is clean but difficult to decipher by a erlang padawan like me.
+
+Presumably you are looking in master. cowboy_websocket does that in 
+master now. cowboy_websocket_handler is in Cowboy 1.0.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-April/000529.html b/_build/static/archives/extend/2015-April/000529.html new file mode 100644 index 00000000..b04ff0f7 --- /dev/null +++ b/_build/static/archives/extend/2015-April/000529.html @@ -0,0 +1,85 @@ + + + + [99s-extend] cowboy_websocket_handler + + + + + + + + + + +

[99s-extend] cowboy_websocket_handler

+ Samir Sow + samset at wanadoo.fr +
+ Wed Apr 22 23:39:29 CEST 2015 +

+
+ +
Thanks.
+Still i can’t figure out how you manage the data transmission from/to handler via the websocket_handle() and websocket_info() function.
+
+Samir
+
+> On 22 avr. 2015, at 23:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> Hello,
+> 
+> On 04/22/2015 11:56 PM, Samir Sow wrote:
+>> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler  :
+>> -  is it an OTP gen_ instance ?
+>> - how/where the websocket_handle() is called ?
+>> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called?
+>> 
+>> I  could not find the cowboy_websocket_handler behavior in the src dir. I guess i’ve missed something.
+>> The code is clean but difficult to decipher by a erlang padawan like me.
+> 
+> Presumably you are looking in master. cowboy_websocket does that in master now. cowboy_websocket_handler is in Cowboy 1.0.
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-April/000530.html b/_build/static/archives/extend/2015-April/000530.html new file mode 100644 index 00000000..1285025d --- /dev/null +++ b/_build/static/archives/extend/2015-April/000530.html @@ -0,0 +1,93 @@ + + + + [99s-extend] cowboy_websocket_handler + + + + + + + + + + +

[99s-extend] cowboy_websocket_handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Apr 23 10:55:23 CEST 2015 +

+
+ +
It's a simple function call.
+
+Assuming the variable Handler contains the name of the module, it's just 
+doing Handler:websocket_info(Info, Req, State) and then checks the 
+return value.
+
+On 04/23/2015 12:39 AM, Samir Sow wrote:
+> Thanks.
+> Still i can’t figure out how you manage the data transmission from/to handler via the websocket_handle() and websocket_info() function.
+>
+> Samir
+>
+>> On 22 avr. 2015, at 23:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> Hello,
+>>
+>> On 04/22/2015 11:56 PM, Samir Sow wrote:
+>>> I would like to learn more about the cowboy_xxxx_handler for instance the cowboy_websocket_handler  :
+>>> -  is it an OTP gen_ instance ?
+>>> - how/where the websocket_handle() is called ?
+>>> - how websocket_info() relates to the Transport:send() operation and where/how this latter function is called?
+>>>
+>>> I  could not find the cowboy_websocket_handler behavior in the src dir. I guess i’ve missed something.
+>>> The code is clean but difficult to decipher by a erlang padawan like me.
+>>
+>> Presumably you are looking in master. cowboy_websocket does that in master now. cowboy_websocket_handler is in Cowboy 1.0.
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-April/author.html b/_build/static/archives/extend/2015-April/author.html new file mode 100644 index 00000000..194631b4 --- /dev/null +++ b/_build/static/archives/extend/2015-April/author.html @@ -0,0 +1,67 @@ + + + + The Extend April 2015 Archive by author + + + + + +

April 2015 Archives by author

+ +

Starting: Wed Apr 22 22:56:01 CEST 2015
+ Ending: Thu Apr 23 10:55:23 CEST 2015
+ Messages: 4

+

+

+ Last message date: + Thu Apr 23 10:55:23 CEST 2015
+ Archived on: Thu Apr 23 10:55:15 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-April/date.html b/_build/static/archives/extend/2015-April/date.html new file mode 100644 index 00000000..6d542059 --- /dev/null +++ b/_build/static/archives/extend/2015-April/date.html @@ -0,0 +1,67 @@ + + + + The Extend April 2015 Archive by date + + + + + +

April 2015 Archives by date

+ +

Starting: Wed Apr 22 22:56:01 CEST 2015
+ Ending: Thu Apr 23 10:55:23 CEST 2015
+ Messages: 4

+

+

+ Last message date: + Thu Apr 23 10:55:23 CEST 2015
+ Archived on: Thu Apr 23 10:55:15 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-April/index.html b/_build/static/archives/extend/2015-April/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-April/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-April/subject.html b/_build/static/archives/extend/2015-April/subject.html new file mode 100644 index 00000000..862e7302 --- /dev/null +++ b/_build/static/archives/extend/2015-April/subject.html @@ -0,0 +1,67 @@ + + + + The Extend April 2015 Archive by subject + + + + + +

April 2015 Archives by subject

+ +

Starting: Wed Apr 22 22:56:01 CEST 2015
+ Ending: Thu Apr 23 10:55:23 CEST 2015
+ Messages: 4

+

+

+ Last message date: + Thu Apr 23 10:55:23 CEST 2015
+ Archived on: Thu Apr 23 10:55:15 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-April/thread.html b/_build/static/archives/extend/2015-April/thread.html new file mode 100644 index 00000000..9835b5a3 --- /dev/null +++ b/_build/static/archives/extend/2015-April/thread.html @@ -0,0 +1,77 @@ + + + + The Extend April 2015 Archive by thread + + + + + +

April 2015 Archives by thread

+ +

Starting: Wed Apr 22 22:56:01 CEST 2015
+ Ending: Thu Apr 23 10:55:23 CEST 2015
+ Messages: 4

+

+

+ Last message date: + Thu Apr 23 10:55:23 CEST 2015
+ Archived on: Thu Apr 23 10:55:15 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-August.txt b/_build/static/archives/extend/2015-August.txt new file mode 100644 index 00000000..adf32e1f --- /dev/null +++ b/_build/static/archives/extend/2015-August.txt @@ -0,0 +1,124 @@ +From essen at ninenines.eu Sat Aug 8 14:43:39 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sat, 08 Aug 2015 14:43:39 +0200 +Subject: [99s-extend] help to combine websocket with basic authentication +In-Reply-To: +References: +Message-ID: <55C5F97B.2000503@ninenines.eu> + +Hey, did you manage to fix your issue? + +On 07/13/2015 12:47 PM, Robert Balogh wrote: +> hello, +> +> Sorry that I turned to the list again, but I would like to get some help +> from you. I have a websocket based application, based on the +> cowboy/examples/websocket. It is working well. Now I would like to add a +> basic authentication, and I saw, there is an example how to do this. I +> checked the cowboy/examples/rest_basic_auth example. +> So I tried "add" the aut. example into my websocket app by doing the +> following steps: +> - add new module for handle the authentication +> do_basic_auth.erl +> - update cowboy_router:compile function call when star application +> with {"/", do_basic_auth, []} +> +> Once the compilation done, I can start the app and I get the "basic +> auth" window in the browser when connecting to localhost:8080, but the +> "ordinary" index.html does not appears when I set the correct auth data +> (user/pwd). I am pretty sure that I made something wrong, I do not see +> what I did wrong, thus I kindly ask you, please try help me. +> +> The project what I am working on can be seen in the github: +> https://github.com/ethrbh/websocket_2 +> +> thanks fro your help, +> /Robi +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From a.brandon.clark at gmail.com Mon Aug 24 20:15:57 2015 +From: a.brandon.clark at gmail.com (Brandon Clark) +Date: Mon, 24 Aug 2015 11:15:57 -0700 +Subject: [99s-extend] Can't start syslog when built with erlang.mk +Message-ID: + +Greetings... + +I'm finding that I can't start syslog when it is built as a dependency of +my erlang.mk project. For example: + +$ erl -pa _rel/${MY_PROJECT}/lib/*/ebin +Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] [hipe] +[kernel-poll:false] + +Eshell V7.0 (abort with ^G) +1> syslog:start(). +{error,"could not load driver syslog_drv: \"cannot open shared object file: +No such file or directory\""} + + +The root of the problem seems to be that erlang.mk compiled syslog_drv.c as +"syslog.so" and syslog expects to load "syslog_drv.so". I have confirmed +that renaming the file solves the problem. + +What do I do with that? + +~BC +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Mon Aug 24 20:18:27 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 24 Aug 2015 20:18:27 +0200 +Subject: [99s-extend] Can't start syslog when built with erlang.mk +In-Reply-To: +References: +Message-ID: <55DB5FF3.1070604@ninenines.eu> + +On 08/24/2015 08:15 PM, Brandon Clark wrote: +> Greetings... +> +> I'm finding that I can't start syslog when it is built as a dependency +> of my erlang.mk project. For example: +> +> $ erl -pa _rel/${MY_PROJECT}/lib/*/ebin +> Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] [hipe] +> [kernel-poll:false] +> +> Eshell V7.0 (abort with ^G) +> 1> syslog:start(). +> {error,"could not load driver syslog_drv: \"cannot open shared object +> file: No such file or directory\""} +> +> +> The root of the problem seems to be that erlang.mk +> compiled syslog_drv.c as "syslog.so" and syslog expects to load +> "syslog_drv.so". I have confirmed that renaming the file solves the +> problem. +> +> What do I do with that? + +Open a ticket and this will be fixed, probably just need to handle a +case we don't do yet. :-) + +Cheers, + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + diff --git a/_build/static/archives/extend/2015-August/000547.html b/_build/static/archives/extend/2015-August/000547.html new file mode 100644 index 00000000..e769f879 --- /dev/null +++ b/_build/static/archives/extend/2015-August/000547.html @@ -0,0 +1,100 @@ + + + + [99s-extend] help to combine websocket with basic authentication + + + + + + + + + + +

[99s-extend] help to combine websocket with basic authentication

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Aug 8 14:43:39 CEST 2015 +

+
+ +
Hey, did you manage to fix your issue?
+
+On 07/13/2015 12:47 PM, Robert Balogh wrote:
+> hello,
+>
+> Sorry that I turned to the list again, but I would like to get some help
+> from you. I have a websocket based application, based on the
+> cowboy/examples/websocket. It is working well. Now I would like to add a
+> basic authentication, and I saw, there is an example how to do this. I
+> checked the cowboy/examples/rest_basic_auth example.
+> So I tried "add" the aut. example into my websocket app by doing the
+> following steps:
+>   - add new module for handle the authentication
+>     do_basic_auth.erl
+>   - update cowboy_router:compile function call when star application
+> with {"/", do_basic_auth, []}
+>
+> Once the compilation done, I can start the app and I get the "basic
+> auth" window in the browser when connecting to localhost:8080, but the
+> "ordinary" index.html does not appears when I set the correct auth data
+> (user/pwd). I am pretty sure that I made something wrong, I do not see
+> what I did wrong, thus I kindly ask you, please try help me.
+>
+> The project what I am working on can be seen in the github:
+> https://github.com/ethrbh/websocket_2
+>
+> thanks fro your help,
+> /Robi
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-August/000548.html b/_build/static/archives/extend/2015-August/000548.html new file mode 100644 index 00000000..8724e5de --- /dev/null +++ b/_build/static/archives/extend/2015-August/000548.html @@ -0,0 +1,86 @@ + + + + [99s-extend] Can't start syslog when built with erlang.mk + + + + + + + + + + +

[99s-extend] Can't start syslog when built with erlang.mk

+ Brandon Clark + a.brandon.clark at gmail.com +
+ Mon Aug 24 20:15:57 CEST 2015 +

+
+ +
Greetings...
+
+I'm finding that I can't start syslog when it is built as a dependency of
+my erlang.mk project.  For example:
+
+$ erl -pa _rel/${MY_PROJECT}/lib/*/ebin
+Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] [hipe]
+[kernel-poll:false]
+
+Eshell V7.0  (abort with ^G)
+1> syslog:start().
+{error,"could not load driver syslog_drv: \"cannot open shared object file:
+No such file or directory\""}
+
+
+The root of the problem seems to be that erlang.mk compiled syslog_drv.c as
+"syslog.so" and syslog expects to load "syslog_drv.so".  I have confirmed
+that renaming the file solves the problem.
+
+What do I do with that?
+
+~BC
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150824/7576a7ab/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-August/000549.html b/_build/static/archives/extend/2015-August/000549.html new file mode 100644 index 00000000..b1e81a60 --- /dev/null +++ b/_build/static/archives/extend/2015-August/000549.html @@ -0,0 +1,91 @@ + + + + [99s-extend] Can't start syslog when built with erlang.mk + + + + + + + + + + +

[99s-extend] Can't start syslog when built with erlang.mk

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Aug 24 20:18:27 CEST 2015 +

+
+ +
On 08/24/2015 08:15 PM, Brandon Clark wrote:
+> Greetings...
+>
+> I'm finding that I can't start syslog when it is built as a dependency
+> of my erlang.mk <http://erlang.mk> project.  For example:
+>
+> $ erl -pa _rel/${MY_PROJECT}/lib/*/ebin
+> Erlang/OTP 18 [erts-7.0] [source] [64-bit] [async-threads:10] [hipe]
+> [kernel-poll:false]
+>
+> Eshell V7.0  (abort with ^G)
+> 1> syslog:start().
+> {error,"could not load driver syslog_drv: \"cannot open shared object
+> file: No such file or directory\""}
+>
+>
+> The root of the problem seems to be that erlang.mk <http://erlang.mk>
+> compiled syslog_drv.c as "syslog.so" and syslog expects to load
+> "syslog_drv.so".  I have confirmed that renaming the file solves the
+> problem.
+>
+> What do I do with that?
+
+Open a ticket and this will be fixed, probably just need to handle a 
+case we don't do yet. :-)
+
+Cheers,
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-August/author.html b/_build/static/archives/extend/2015-August/author.html new file mode 100644 index 00000000..3f21c157 --- /dev/null +++ b/_build/static/archives/extend/2015-August/author.html @@ -0,0 +1,62 @@ + + + + The Extend August 2015 Archive by author + + + + + +

August 2015 Archives by author

+ +

Starting: Sat Aug 8 14:43:39 CEST 2015
+ Ending: Mon Aug 24 20:18:27 CEST 2015
+ Messages: 3

+

+

+ Last message date: + Mon Aug 24 20:18:27 CEST 2015
+ Archived on: Mon Aug 24 20:18:10 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-August/date.html b/_build/static/archives/extend/2015-August/date.html new file mode 100644 index 00000000..0b2603f4 --- /dev/null +++ b/_build/static/archives/extend/2015-August/date.html @@ -0,0 +1,62 @@ + + + + The Extend August 2015 Archive by date + + + + + +

August 2015 Archives by date

+ +

Starting: Sat Aug 8 14:43:39 CEST 2015
+ Ending: Mon Aug 24 20:18:27 CEST 2015
+ Messages: 3

+

+

+ Last message date: + Mon Aug 24 20:18:27 CEST 2015
+ Archived on: Mon Aug 24 20:18:10 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-August/index.html b/_build/static/archives/extend/2015-August/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-August/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-August/subject.html b/_build/static/archives/extend/2015-August/subject.html new file mode 100644 index 00000000..6de6a6bb --- /dev/null +++ b/_build/static/archives/extend/2015-August/subject.html @@ -0,0 +1,62 @@ + + + + The Extend August 2015 Archive by subject + + + + + +

August 2015 Archives by subject

+ +

Starting: Sat Aug 8 14:43:39 CEST 2015
+ Ending: Mon Aug 24 20:18:27 CEST 2015
+ Messages: 3

+

+

+ Last message date: + Mon Aug 24 20:18:27 CEST 2015
+ Archived on: Mon Aug 24 20:18:10 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-August/thread.html b/_build/static/archives/extend/2015-August/thread.html new file mode 100644 index 00000000..3ce6486a --- /dev/null +++ b/_build/static/archives/extend/2015-August/thread.html @@ -0,0 +1,67 @@ + + + + The Extend August 2015 Archive by thread + + + + + +

August 2015 Archives by thread

+ +

Starting: Sat Aug 8 14:43:39 CEST 2015
+ Ending: Mon Aug 24 20:18:27 CEST 2015
+ Messages: 3

+

+

+ Last message date: + Mon Aug 24 20:18:27 CEST 2015
+ Archived on: Mon Aug 24 20:18:10 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-February.txt b/_build/static/archives/extend/2015-February.txt new file mode 100644 index 00000000..ca8da609 --- /dev/null +++ b/_build/static/archives/extend/2015-February.txt @@ -0,0 +1,233 @@ +From pdtwonotes at gmail.com Sun Feb 15 23:50:58 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Sun, 15 Feb 2015 17:50:58 -0500 +Subject: [99s-extend] callbacks for additional methods +Message-ID: <1424040658.19383.6.camel@gmail.com> + +I am writing a CalDAV handler, which is a type of WebDAV server. CalDAV +defines a bunch of +additional methods beyond what a typical web browser would use, such as +REPORT and PROPFIND. + +I have written the allowed_methods and known_methods callbacks to report +that all these methods +are acceptable. My content_types_provided has an entry for +"application/xml", which is how these +extra methods turn up. + +When I connect to my server using the calendar function of Evolution, +one of the first things it does +is a REPORT method, which is sort of a query. This gets as far as +content_types_provided, but after +that it does not call the function I identified in +content_types_provided. + +What is the best way to handle the non-standard methods that do not have +defined callbacks? + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From samset at wanadoo.fr Fri Feb 27 18:07:08 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 27 Feb 2015 18:07:08 +0100 +Subject: [99s-extend] Body length and content-length mismatch +Message-ID: <4E148D98-CFDB-40D4-8532-8E46C8F09DB0@wanadoo.fr> + +Hi, + +I?m facing an issue with the cowboy_req:body call. + +The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure. +Trying to use cowboy_req:body with the length option does not make any difference. + +How can i retrieve the data ? +Any clue ? + +Thank you + +{ok,{<<"basic">>,{<>,<>}}, + {http_req, + {sslsocket, + {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>}, + <0.407.0>}, + ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1', + {{xxxxxxxxx},16220}, + <>,undefined,xxxx,<>,undefined, + <<>>,undefined, + [{res_1,<>}], + [{<<"content-type">>,<<"application/json">>}, + {<<"content-length">>,<<"2">>}, + {<<"te">>,<<>>}, + {<<"host">>,<>}, + {<<"authorization">>, + <<"Basic xxxxxxxxxxxxxx">>}, + {<<"connection">>,<<"keep-alive">>}], + [{<<"authorization">>, + {<<"basic">>,{<>,<>}}}, + {<<"connection">>,[<<"keep-alive">>]}], + undefined,[],waiting, + <<"{\"login\":\?xxxx at xxxxxx\",\?xxxx\":\?xxxx\"}{\"login\":\?xxxx at xxxx\",\?xxxx\":\?xxxxx\"}">>, + undefined,false,waiting, + [{<<"Access-Control-Allow-Credentials">>,<<"true">>}, + {<<"Access-Control-Allow-Origin">>, + <<"http://xxxxxxxxx">>}], + <<>>,undefined}} +Samir + + + +From essen at ninenines.eu Fri Feb 27 18:11:42 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 27 Feb 2015 18:11:42 +0100 +Subject: [99s-extend] Body length and content-length mismatch +In-Reply-To: <4E148D98-CFDB-40D4-8532-8E46C8F09DB0@wanadoo.fr> +References: <4E148D98-CFDB-40D4-8532-8E46C8F09DB0@wanadoo.fr> +Message-ID: <54F0A54E.2010205@ninenines.eu> + +It looks like the client is telling you BS. + +On 02/27/2015 06:07 PM, Samir Sow wrote: +> Hi, +> +> I?m facing an issue with the cowboy_req:body call. +> +> The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure. +> Trying to use cowboy_req:body with the length option does not make any difference. +> +> How can i retrieve the data ? +> Any clue ? +> +> Thank you +> +> {ok,{<<"basic">>,{<>,<>}}, +> {http_req, +> {sslsocket, +> {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>}, +> <0.407.0>}, +> ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1', +> {{xxxxxxxxx},16220}, +> <>,undefined,xxxx,<>,undefined, +> <<>>,undefined, +> [{res_1,<>}], +> [{<<"content-type">>,<<"application/json">>}, +> {<<"content-length">>,<<"2">>}, +> {<<"te">>,<<>>}, +> {<<"host">>,<>}, +> {<<"authorization">>, +> <<"Basic xxxxxxxxxxxxxx">>}, +> {<<"connection">>,<<"keep-alive">>}], +> [{<<"authorization">>, +> {<<"basic">>,{<>,<>}}}, +> {<<"connection">>,[<<"keep-alive">>]}], +> undefined,[],waiting, +> <<"{\"login\":\?xxxx at xxxxxx\",\?xxxx\":\?xxxx\"}{\"login\":\?xxxx at xxxx\",\?xxxx\":\?xxxxx\"}">>, + +And looking at this (the buffer of already received data, presumably +your whole body, it looks like you receive 2 things. Perhaps the client +gives you the count of things instead of the length? + +Either way if the client provides a wrong content-type you should reject +the connection. + +> undefined,false,waiting, +> [{<<"Access-Control-Allow-Credentials">>,<<"true">>}, +> {<<"Access-Control-Allow-Origin">>, +> <<"http://xxxxxxxxx">>}], +> <<>>,undefined}} +> Samir +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Fri Feb 27 18:33:56 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Fri, 27 Feb 2015 18:33:56 +0100 +Subject: [99s-extend] Body length and content-length mismatch +In-Reply-To: <54F0A54E.2010205@ninenines.eu> +References: <4E148D98-CFDB-40D4-8532-8E46C8F09DB0@wanadoo.fr> + <54F0A54E.2010205@ninenines.eu> +Message-ID: <62EAECE1-086A-4788-845A-11A1BC6C16AA@wanadoo.fr> + +Yes. +i?m using httpc. It does not like wrapping a binary string inside a []. +I?ll fix my body. + +Thank you. + +Sincerely. + + + +> On 27 f?vr. 2015, at 18:11, Lo?c Hoguin wrote: +> +> It looks like the client is telling you BS. +> +> On 02/27/2015 06:07 PM, Samir Sow wrote: +>> Hi, +>> +>> I?m facing an issue with the cowboy_req:body call. +>> +>> The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure. +>> Trying to use cowboy_req:body with the length option does not make any difference. +>> +>> How can i retrieve the data ? +>> Any clue ? +>> +>> Thank you +>> +>> {ok,{<<"basic">>,{<>,<>}}, +>> {http_req, +>> {sslsocket, +>> {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>}, +>> <0.407.0>}, +>> ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1', +>> {{xxxxxxxxx},16220}, +>> <>,undefined,xxxx,<>,undefined, +>> <<>>,undefined, +>> [{res_1,<>}], +>> [{<<"content-type">>,<<"application/json">>}, +>> {<<"content-length">>,<<"2">>}, +>> {<<"te">>,<<>>}, +>> {<<"host">>,<>}, +>> {<<"authorization">>, +>> <<"Basic xxxxxxxxxxxxxx">>}, +>> {<<"connection">>,<<"keep-alive">>}], +>> [{<<"authorization">>, +>> {<<"basic">>,{<>,<>}}}, +>> {<<"connection">>,[<<"keep-alive">>]}], +>> undefined,[],waiting, +>> <<"{\"login\":\?xxxx at xxxxxx\",\?xxxx\":\?xxxx\"}{\"login\":\?xxxx at xxxx\",\?xxxx\":\?xxxxx\"}">>, +> +> And looking at this (the buffer of already received data, presumably your whole body, it looks like you receive 2 things. Perhaps the client gives you the count of things instead of the length? +> +> Either way if the client provides a wrong content-type you should reject the connection. +> +>> undefined,false,waiting, +>> [{<<"Access-Control-Allow-Credentials">>,<<"true">>}, +>> {<<"Access-Control-Allow-Origin">>, +>> <<"http://xxxxxxxxx">>}], +>> <<>>,undefined}} +>> Samir +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + diff --git a/_build/static/archives/extend/2015-February/000510.html b/_build/static/archives/extend/2015-February/000510.html new file mode 100644 index 00000000..2f81ecde --- /dev/null +++ b/_build/static/archives/extend/2015-February/000510.html @@ -0,0 +1,83 @@ + + + + [99s-extend] callbacks for additional methods + + + + + + + + + + +

[99s-extend] callbacks for additional methods

+ Paul Dickson + pdtwonotes at gmail.com +
+ Sun Feb 15 23:50:58 CET 2015 +

+
+ +
I am writing a CalDAV handler, which is a type of WebDAV server.  CalDAV
+defines a bunch of
+additional methods beyond what a typical web browser would use, such as
+REPORT and PROPFIND.
+
+I have written the allowed_methods and known_methods callbacks to report
+that all these methods
+are acceptable.  My content_types_provided has an entry for
+"application/xml", which is how these
+extra methods turn up.
+
+When I connect to my server using the calendar function of Evolution,
+one of the first things it does
+is a REPORT method, which is sort of a query.  This gets as far as
+content_types_provided, but after
+that it does not call the function I identified in
+content_types_provided.
+
+What is the best way to handle the non-standard methods that do not have
+defined callbacks?
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150215/9d2f5de1/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-February/000511.html b/_build/static/archives/extend/2015-February/000511.html new file mode 100644 index 00000000..c3fde33d --- /dev/null +++ b/_build/static/archives/extend/2015-February/000511.html @@ -0,0 +1,103 @@ + + + + [99s-extend] Body length and content-length mismatch + + + + + + + + + + +

[99s-extend] Body length and content-length mismatch

+ Samir Sow + samset at wanadoo.fr +
+ Fri Feb 27 18:07:08 CET 2015 +

+
+ +
Hi,
+
+I’m facing an issue with the cowboy_req:body call.
+
+The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure.
+Trying to use cowboy_req:body with the length option does not make any difference.
+
+How can i retrieve the data ?
+Any clue ?
+
+Thank you
+
+{ok,{<<"basic">>,{<<«xxxxx at xxxxxx">>,<<«xxxxxxx">>}},
+          {http_req,
+              {sslsocket,
+                  {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>},
+                  <0.407.0>},
+              ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1',
+              {{xxxxxxxxx},16220},
+              <<«xxxx">>,undefined,xxxx,<<«xxxxx">>,undefined,
+              <<>>,undefined,
+              [{res_1,<<«xxxx">>}],
+              [{<<"content-type">>,<<"application/json">>},
+               {<<"content-length">>,<<"2">>},
+               {<<"te">>,<<>>},
+               {<<"host">>,<<«xxxxx">>},
+               {<<"authorization">>,
+                <<"Basic xxxxxxxxxxxxxx">>},
+               {<<"connection">>,<<"keep-alive">>}],
+              [{<<"authorization">>,
+                {<<"basic">>,{<<«xxxxxx">>,<<«xxxxxx">>}}},
+               {<<"connection">>,[<<"keep-alive">>]}],
+              undefined,[],waiting,
+              <<"{\"login\":\»xxxx at xxxxxx\",\»xxxx\":\»xxxx\"}{\"login\":\»xxxx at xxxx\",\»xxxx\":\»xxxxx\"}">>,
+              undefined,false,waiting,
+              [{<<"Access-Control-Allow-Credentials">>,<<"true">>},
+               {<<"Access-Control-Allow-Origin">>,
+                <<"http://xxxxxxxxx">>}],
+              <<>>,undefined}}
+Samir
+
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-February/000512.html b/_build/static/archives/extend/2015-February/000512.html new file mode 100644 index 00000000..f40595c2 --- /dev/null +++ b/_build/static/archives/extend/2015-February/000512.html @@ -0,0 +1,123 @@ + + + + [99s-extend] Body length and content-length mismatch + + + + + + + + + + +

[99s-extend] Body length and content-length mismatch

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Feb 27 18:11:42 CET 2015 +

+
+ +
It looks like the client is telling you BS.
+
+On 02/27/2015 06:07 PM, Samir Sow wrote:
+> Hi,
+>
+> I’m facing an issue with the cowboy_req:body call.
+>
+> The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure.
+> Trying to use cowboy_req:body with the length option does not make any difference.
+>
+> How can i retrieve the data ?
+> Any clue ?
+>
+> Thank you
+>
+> {ok,{<<"basic">>,{<<«xxxxx at xxxxxx">>,<<«xxxxxxx">>}},
+>            {http_req,
+>                {sslsocket,
+>                    {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>},
+>                    <0.407.0>},
+>                ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1',
+>                {{xxxxxxxxx},16220},
+>                <<«xxxx">>,undefined,xxxx,<<«xxxxx">>,undefined,
+>                <<>>,undefined,
+>                [{res_1,<<«xxxx">>}],
+>                [{<<"content-type">>,<<"application/json">>},
+>                 {<<"content-length">>,<<"2">>},
+>                 {<<"te">>,<<>>},
+>                 {<<"host">>,<<«xxxxx">>},
+>                 {<<"authorization">>,
+>                  <<"Basic xxxxxxxxxxxxxx">>},
+>                 {<<"connection">>,<<"keep-alive">>}],
+>                [{<<"authorization">>,
+>                  {<<"basic">>,{<<«xxxxxx">>,<<«xxxxxx">>}}},
+>                 {<<"connection">>,[<<"keep-alive">>]}],
+>                undefined,[],waiting,
+>                <<"{\"login\":\»xxxx at xxxxxx\",\»xxxx\":\»xxxx\"}{\"login\":\»xxxx at xxxx\",\»xxxx\":\»xxxxx\"}">>,
+
+And looking at this (the buffer of already received data, presumably 
+your whole body, it looks like you receive 2 things. Perhaps the client 
+gives you the count of things instead of the length?
+
+Either way if the client provides a wrong content-type you should reject 
+the connection.
+
+>                undefined,false,waiting,
+>                [{<<"Access-Control-Allow-Credentials">>,<<"true">>},
+>                 {<<"Access-Control-Allow-Origin">>,
+>                  <<"http://xxxxxxxxx">>}],
+>                <<>>,undefined}}
+> Samir
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-February/000513.html b/_build/static/archives/extend/2015-February/000513.html new file mode 100644 index 00000000..d8937c71 --- /dev/null +++ b/_build/static/archives/extend/2015-February/000513.html @@ -0,0 +1,130 @@ + + + + [99s-extend] Body length and content-length mismatch + + + + + + + + + + +

[99s-extend] Body length and content-length mismatch

+ Samir Sow + samset at wanadoo.fr +
+ Fri Feb 27 18:33:56 CET 2015 +

+
+ +
Yes.
+i’m using httpc. It does not like  wrapping a binary string inside a [].
+I’ll fix my body.
+
+Thank you.
+
+Sincerely.
+
+
+
+> On 27 févr. 2015, at 18:11, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> It looks like the client is telling you BS.
+> 
+> On 02/27/2015 06:07 PM, Samir Sow wrote:
+>> Hi,
+>> 
+>> I’m facing an issue with the cowboy_req:body call.
+>> 
+>> The header show a length of 2 while the body itself is a binary string which has a size greater than 2 for sure.
+>> Trying to use cowboy_req:body with the length option does not make any difference.
+>> 
+>> How can i retrieve the data ?
+>> Any clue ?
+>> 
+>> Thank you
+>> 
+>> {ok,{<<"basic">>,{<<«xxxxx at xxxxxx">>,<<«xxxxxxx">>}},
+>>           {http_req,
+>>               {sslsocket,
+>>                   {gen_tcp,#Port<0.13250>,tls_connection,<0.298.0>},
+>>                   <0.407.0>},
+>>               ranch_ssl,keepalive,<0.408.0>,<<"POST">>,'HTTP/1.1',
+>>               {{xxxxxxxxx},16220},
+>>               <<«xxxx">>,undefined,xxxx,<<«xxxxx">>,undefined,
+>>               <<>>,undefined,
+>>               [{res_1,<<«xxxx">>}],
+>>               [{<<"content-type">>,<<"application/json">>},
+>>                {<<"content-length">>,<<"2">>},
+>>                {<<"te">>,<<>>},
+>>                {<<"host">>,<<«xxxxx">>},
+>>                {<<"authorization">>,
+>>                 <<"Basic xxxxxxxxxxxxxx">>},
+>>                {<<"connection">>,<<"keep-alive">>}],
+>>               [{<<"authorization">>,
+>>                 {<<"basic">>,{<<«xxxxxx">>,<<«xxxxxx">>}}},
+>>                {<<"connection">>,[<<"keep-alive">>]}],
+>>               undefined,[],waiting,
+>>               <<"{\"login\":\»xxxx at xxxxxx\",\»xxxx\":\»xxxx\"}{\"login\":\»xxxx at xxxx\",\»xxxx\":\»xxxxx\"}">>,
+> 
+> And looking at this (the buffer of already received data, presumably your whole body, it looks like you receive 2 things. Perhaps the client gives you the count of things instead of the length?
+> 
+> Either way if the client provides a wrong content-type you should reject the connection.
+> 
+>>               undefined,false,waiting,
+>>               [{<<"Access-Control-Allow-Credentials">>,<<"true">>},
+>>                {<<"Access-Control-Allow-Origin">>,
+>>                 <<"http://xxxxxxxxx">>}],
+>>               <<>>,undefined}}
+>> Samir
+>> 
+>> 
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-February/author.html b/_build/static/archives/extend/2015-February/author.html new file mode 100644 index 00000000..fd99291d --- /dev/null +++ b/_build/static/archives/extend/2015-February/author.html @@ -0,0 +1,67 @@ + + + + The Extend February 2015 Archive by author + + + + + +

February 2015 Archives by author

+ +

Starting: Sun Feb 15 23:50:58 CET 2015
+ Ending: Fri Feb 27 18:33:56 CET 2015
+ Messages: 4

+

+

+ Last message date: + Fri Feb 27 18:33:56 CET 2015
+ Archived on: Fri Feb 27 18:33:54 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-February/date.html b/_build/static/archives/extend/2015-February/date.html new file mode 100644 index 00000000..1b5a82b3 --- /dev/null +++ b/_build/static/archives/extend/2015-February/date.html @@ -0,0 +1,67 @@ + + + + The Extend February 2015 Archive by date + + + + + +

February 2015 Archives by date

+ +

Starting: Sun Feb 15 23:50:58 CET 2015
+ Ending: Fri Feb 27 18:33:56 CET 2015
+ Messages: 4

+

+

+ Last message date: + Fri Feb 27 18:33:56 CET 2015
+ Archived on: Fri Feb 27 18:33:54 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-February/index.html b/_build/static/archives/extend/2015-February/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-February/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-February/subject.html b/_build/static/archives/extend/2015-February/subject.html new file mode 100644 index 00000000..878baabb --- /dev/null +++ b/_build/static/archives/extend/2015-February/subject.html @@ -0,0 +1,67 @@ + + + + The Extend February 2015 Archive by subject + + + + + +

February 2015 Archives by subject

+ +

Starting: Sun Feb 15 23:50:58 CET 2015
+ Ending: Fri Feb 27 18:33:56 CET 2015
+ Messages: 4

+

+

+ Last message date: + Fri Feb 27 18:33:56 CET 2015
+ Archived on: Fri Feb 27 18:33:54 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-February/thread.html b/_build/static/archives/extend/2015-February/thread.html new file mode 100644 index 00000000..2c70907f --- /dev/null +++ b/_build/static/archives/extend/2015-February/thread.html @@ -0,0 +1,75 @@ + + + + The Extend February 2015 Archive by thread + + + + + +

February 2015 Archives by thread

+ +

Starting: Sun Feb 15 23:50:58 CET 2015
+ Ending: Fri Feb 27 18:33:56 CET 2015
+ Messages: 4

+

+

+ Last message date: + Fri Feb 27 18:33:56 CET 2015
+ Archived on: Fri Feb 27 18:33:54 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-January.txt b/_build/static/archives/extend/2015-January.txt new file mode 100644 index 00000000..d94c2440 --- /dev/null +++ b/_build/static/archives/extend/2015-January.txt @@ -0,0 +1,1189 @@ +From e at bestmx.net Sat Jan 10 14:55:58 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 14:55:58 +0100 +Subject: [99s-extend] websocket over ssl +Message-ID: <54B12F6E.6000305@bestmx.net> + +Hello all. + +I am trying to alter my cowboy-based websocket server from plain to SSL +connection. +And I found out that I have failed to understand very basics of the +combination of WS and SSL. + +As far as i've understood the very nature of the WS it is a bit altered +http connection (i open the http connection first, and then i change its +status to WS) + +On the other hand the whole "HTTP story" could be wrapped into SSL, so +that SSL is an outer layer of data encoding (as seen transparent by an +application) + +thus, +if I open HTTPS connection (which implies SSL enveloping) and then alter +the connection status to WS, the whole "WS story" appears naturally +INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. + +Is it true? + +In this regard i can hardly find a place in this world for the "WSS" +term, what does it stand for? + +Please, help me fit it in my head. + +However, i might be confusing some Client-Side entities, that are +involved in the process of starting up my WebSocket. + +I am using a Browser with JavaScript. + +The semantics of the very WebSocket.start() operation is not enough +clear to me. Please, do not laugh. + +when i do JS WebSocket.start() does it: +(a) opens an http connection and then alters it to WS +(b) alters the connection in the context of which the JS process is running +???? + +I'll be damned if the answer was lying on the surface of the internet! + +The third part of this ugly question is about cowboy actually. +How all these entities mentioned above do map into my_app.erl file? +what particular bits of cowboy's "configuration" (may i call this +particular piece of code a "setup" or "config"?) affect what aspects of +the connection initialization. + +well, i am afraid it could be put in a simpler way: +"Exactly When and Where the WSS story begins?" + + +From essen at ninenines.eu Sat Jan 10 15:21:04 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sat, 10 Jan 2015 15:21:04 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <54B12F6E.6000305@bestmx.net> +References: <54B12F6E.6000305@bestmx.net> +Message-ID: <54B13550.5050504@ninenines.eu> + +Assuming you have no problem understanding HTTPS, the only differences +between plain Websocket and HTTPS Websocket are as follow: + +In your browser, your ws:// links become wss:// links. + +In Cowboy, use start_https instead of start_http. There is no change +required in your code otherwise. + +It may or may not be possible to use wss:// from an HTTP page or ws:// +from an HTTPS page, I'm not too up to date on that one. Otherwise, ws:// +from HTTP page or wss:// from HTTPS page works as intended. + +There is no requirement that a Websocket connection is initiated on a +new TCP connection. I am not sure if browsers reuse connections or not. + +On 01/10/2015 02:55 PM, e at bestmx.net wrote: +> Hello all. +> +> I am trying to alter my cowboy-based websocket server from plain to SSL +> connection. +> And I found out that I have failed to understand very basics of the +> combination of WS and SSL. +> +> As far as i've understood the very nature of the WS it is a bit altered +> http connection (i open the http connection first, and then i change its +> status to WS) +> +> On the other hand the whole "HTTP story" could be wrapped into SSL, so +> that SSL is an outer layer of data encoding (as seen transparent by an +> application) +> +> thus, +> if I open HTTPS connection (which implies SSL enveloping) and then alter +> the connection status to WS, the whole "WS story" appears naturally +> INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. +> +> Is it true? +> +> In this regard i can hardly find a place in this world for the "WSS" +> term, what does it stand for? +> +> Please, help me fit it in my head. +> +> However, i might be confusing some Client-Side entities, that are +> involved in the process of starting up my WebSocket. +> +> I am using a Browser with JavaScript. +> +> The semantics of the very WebSocket.start() operation is not enough +> clear to me. Please, do not laugh. +> +> when i do JS WebSocket.start() does it: +> (a) opens an http connection and then alters it to WS +> (b) alters the connection in the context of which the JS process is running +> ???? +> +> I'll be damned if the answer was lying on the surface of the internet! +> +> The third part of this ugly question is about cowboy actually. +> How all these entities mentioned above do map into my_app.erl file? +> what particular bits of cowboy's "configuration" (may i call this +> particular piece of code a "setup" or "config"?) affect what aspects of +> the connection initialization. +> +> well, i am afraid it could be put in a simpler way: +> "Exactly When and Where the WSS story begins?" +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Sat Jan 10 15:28:52 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 15:28:52 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <54B13550.5050504@ninenines.eu> +References: <54B12F6E.6000305@bestmx.net> <54B13550.5050504@ninenines.eu> +Message-ID: <54B13724.8010503@bestmx.net> + +> In Cowboy, use start_https instead of start_http. + +thanx! it makes a lot of sense for me. +tell me please what deps should be declared in the .app file? + +is the following correct? + + {applications, [ + kernel, + stdlib, + crypto, + public_key, + ssl, + cowboy + ]}, + +does the order matters? + +(i borrowed that from the internet without deep understanding of the +roles of each app on the list) + +From essen at ninenines.eu Sat Jan 10 15:34:41 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Sat, 10 Jan 2015 15:34:41 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <54B13724.8010503@bestmx.net> +References: <54B12F6E.6000305@bestmx.net> <54B13550.5050504@ninenines.eu> + <54B13724.8010503@bestmx.net> +Message-ID: <54B13881.6000408@ninenines.eu> + +Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter +I think. + +On 01/10/2015 03:28 PM, e at bestmx.net wrote: +>> In Cowboy, use start_https instead of start_http. +> +> thanx! it makes a lot of sense for me. +> tell me please what deps should be declared in the .app file? +> +> is the following correct? +> +> {applications, [ +> kernel, +> stdlib, +> crypto, +> public_key, +> ssl, +> cowboy +> ]}, +> +> does the order matters? +> +> (i borrowed that from the internet without deep understanding of the +> roles of each app on the list) + +-- +Lo?c Hoguin +http://ninenines.eu + +From lee.sylvester at gmail.com Sat Jan 10 15:39:41 2015 +From: lee.sylvester at gmail.com (Lee Sylvester) +Date: Sat, 10 Jan 2015 14:39:41 +0000 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <54B12F6E.6000305@bestmx.net> +References: <54B12F6E.6000305@bestmx.net> +Message-ID: + +I use Cowboy for websockets, but I find it?s a lot easier (and less stressful) to run Nginx in front of it to provide the SSL layer. + +Lee + + +> On 10 Jan 2015, at 13:55, e at bestmx.net wrote: +> +> Hello all. +> +> I am trying to alter my cowboy-based websocket server from plain to SSL connection. +> And I found out that I have failed to understand very basics of the combination of WS and SSL. +> +> As far as i've understood the very nature of the WS it is a bit altered http connection (i open the http connection first, and then i change its status to WS) +> +> On the other hand the whole "HTTP story" could be wrapped into SSL, so that SSL is an outer layer of data encoding (as seen transparent by an application) +> +> thus, +> if I open HTTPS connection (which implies SSL enveloping) and then alter the connection status to WS, the whole "WS story" appears naturally INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION. +> +> Is it true? +> +> In this regard i can hardly find a place in this world for the "WSS" term, what does it stand for? +> +> Please, help me fit it in my head. +> +> However, i might be confusing some Client-Side entities, that are involved in the process of starting up my WebSocket. +> +> I am using a Browser with JavaScript. +> +> The semantics of the very WebSocket.start() operation is not enough clear to me. Please, do not laugh. +> +> when i do JS WebSocket.start() does it: +> (a) opens an http connection and then alters it to WS +> (b) alters the connection in the context of which the JS process is running +> ???? +> +> I'll be damned if the answer was lying on the surface of the internet! +> +> The third part of this ugly question is about cowboy actually. +> How all these entities mentioned above do map into my_app.erl file? +> what particular bits of cowboy's "configuration" (may i call this particular piece of code a "setup" or "config"?) affect what aspects of the connection initialization. +> +> well, i am afraid it could be put in a simpler way: +> "Exactly When and Where the WSS story begins?" +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + + +From e at bestmx.net Sat Jan 10 15:46:23 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 15:46:23 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: +References: <54B12F6E.6000305@bestmx.net> + +Message-ID: <54B13B3F.5090907@bestmx.net> + + > I use Cowboy for websockets, but I find it?s a lot easier (and less + > stressful) to run Nginx in front of it to provide the SSL layer. + +well, nginx is my choice for almost everything, still i am trying to +minimize amount of intermediate software wherever possible. + +P.S. +with nginx and postgreSQL i have managed to eliminate any trace of +server-side scripting in my previous project :) +just nginx connected to Postgres. + + +From e at bestmx.net Sat Jan 10 16:28:19 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Sat, 10 Jan 2015 16:28:19 +0100 +Subject: [99s-extend] websocket over ssl +In-Reply-To: <54B13881.6000408@ninenines.eu> +References: <54B12F6E.6000305@bestmx.net> <54B13550.5050504@ninenines.eu> + <54B13724.8010503@bestmx.net> <54B13881.6000408@ninenines.eu> +Message-ID: <54B14513.3090804@bestmx.net> + +thanx again. +now everything "magically" works :) + + +On 01/10/2015 03:34 PM, Lo?c Hoguin wrote: +> Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter +> I think. +> +> On 01/10/2015 03:28 PM, e at bestmx.net wrote: +>>> In Cowboy, use start_https instead of start_http. +>> +>> thanx! it makes a lot of sense for me. +>> tell me please what deps should be declared in the .app file? +>> +>> is the following correct? +>> +>> {applications, [ +>> kernel, +>> stdlib, +>> crypto, +>> public_key, +>> ssl, +>> cowboy +>> ]}, +>> +>> does the order matters? +>> +>> (i borrowed that from the internet without deep understanding of the +>> roles of each app on the list) +> + +From stefan.strigler at gmail.com Wed Jan 14 17:45:41 2015 +From: stefan.strigler at gmail.com (Stefan Strigler) +Date: Wed, 14 Jan 2015 17:45:41 +0100 +Subject: [99s-extend] cowboy and handling exceptions +Message-ID: + +Hey there, + +maybe I'm missing the obvious. What I want to do is add some generic +handler for exception handling. Say we have a set of resources some of +which delegating stuff to external, other services. These calls might +result in a + +throw({error, timeout}) + +for instance. How would I add/modify cowboy's middleware (right place?) to +handle those (known) exception and return a custom error (like 504 - +Gateway Timeout). + +Thanks for any hints, + +Steve +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Jan 14 18:49:39 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 14 Jan 2015 18:49:39 +0100 +Subject: [99s-extend] cowboy and handling exceptions +In-Reply-To: +References: +Message-ID: <54B6AC33.8040207@ninenines.eu> + +I don't know, there is no such thing in Cowboy. :-) + +On 01/14/2015 05:45 PM, Stefan Strigler wrote: +> Hey there, +> +> maybe I'm missing the obvious. What I want to do is add some generic +> handler for exception handling. Say we have a set of resources some of +> which delegating stuff to external, other services. These calls might +> result in a +> +> throw({error, timeout}) +> +> for instance. How would I add/modify cowboy's middleware (right place?) +> to handle those (known) exception and return a custom error (like 504 - +> Gateway Timeout). +> +> Thanks for any hints, +> +> Steve +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Wed Jan 14 18:50:21 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 14 Jan 2015 18:50:21 +0100 +Subject: [99s-extend] cowboy and handling exceptions +In-Reply-To: <54B6AC33.8040207@ninenines.eu> +References: + <54B6AC33.8040207@ninenines.eu> +Message-ID: <54B6AC5D.1080903@ninenines.eu> + +I send too early... + +I want to add a hook for when Cowboy receives exceptions in Cowboy 2, so +at that point you will be able to do it. But nothing in current Cowboy. + +On 01/14/2015 06:49 PM, Lo?c Hoguin wrote: +> I don't know, there is no such thing in Cowboy. :-) +> +> On 01/14/2015 05:45 PM, Stefan Strigler wrote: +>> Hey there, +>> +>> maybe I'm missing the obvious. What I want to do is add some generic +>> handler for exception handling. Say we have a set of resources some of +>> which delegating stuff to external, other services. These calls might +>> result in a +>> +>> throw({error, timeout}) +>> +>> for instance. How would I add/modify cowboy's middleware (right place?) +>> to handle those (known) exception and return a custom error (like 504 - +>> Gateway Timeout). +>> +>> Thanks for any hints, +>> +>> Steve +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Mon Jan 19 20:32:00 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Mon, 19 Jan 2015 20:32:00 +0100 +Subject: [99s-extend] Cowboy + SSL +Message-ID: <54BD5BB0.4000503@bestmx.net> + +Hello. + +i still have a problem with SSL. +as soon as i change cowboy:start_http call to cowboy:start_https +my release refuses to stop (when requested) +and when i revert to "http" it starts and stops normally. + +i am sure it is the only difference: start_http vs. start_https + +i am using relx with default settings as it was provided by cowboy +(Erlang R17, System: Debian "testing") + +here is my_app.erl: + +start(_Type, _Args) -> + Dispatch = + cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), + + cowboy:start_https( https, 100, [ {port, 8765} + , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} + , {certfile, ?Dir ++ "/ssl/server.crt"} + , {keyfile, ?Dir ++ "/ssl/server.key"} ] + , [{env, [{dispatch, Dispatch}]}]), + + online37_sup:start_link(). + +stop(_State) -> ok. + + +once i call: +release/bin/my_release stop + +the erlang.log repeats hundreds of: + +=ERROR REPORT==== 19-Jan-2015::20:06:02 === +Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +{{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} + + +what could it be? +any misconfiguration of my system (regarding ssl support)? +what exactly does ranch expect from me? + + + +From e at bestmx.net Wed Jan 21 19:28:40 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Wed, 21 Jan 2015 19:28:40 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <54BD5BB0.4000503@bestmx.net> +References: <54BD5BB0.4000503@bestmx.net> +Message-ID: <54BFEFD8.7070003@bestmx.net> + +reading the sources i have found that this crash i am trying to report +is intended behavior, +but +it happens in the middle of the SHUTDOWN procedure! + + +I tried to investigate how a relx's release shuts down +and i have found it is merely one call to: init:stop/0 +nothing else. + +the manual says: + +stop() -> ok + +All applications are taken down smoothly, all code is unloaded, and all +ports are closed before the system terminates. If the -heart command +line flag was given, the heart program is terminated before the Erlang +node terminates. + +I end up totally clueless -- everything is rock solid yet it crashes. +maybe there is some clue in the sequence of shutting down applications? + +does anything controls/defines that sequence? + + + +On 01/19/2015 08:32 PM, e at bestmx.net wrote: +> Hello. +> +> i still have a problem with SSL. +> as soon as i change cowboy:start_http call to cowboy:start_https +> my release refuses to stop (when requested) +> and when i revert to "http" it starts and stops normally. +> +> i am sure it is the only difference: start_http vs. start_https +> +> i am using relx with default settings as it was provided by cowboy +> (Erlang R17, System: Debian "testing") +> +> here is my_app.erl: +> +> start(_Type, _Args) -> +> Dispatch = +> cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), +> +> cowboy:start_https( https, 100, [ {port, 8765} +> , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} +> , {certfile, ?Dir ++ "/ssl/server.crt"} +> , {keyfile, ?Dir ++ "/ssl/server.key"} ] +> , [{env, [{dispatch, Dispatch}]}]), +> +> online37_sup:start_link(). +> +> stop(_State) -> ok. +> +> +> once i call: +> release/bin/my_release stop +> +> the erlang.log repeats hundreds of: +> +> =ERROR REPORT==== 19-Jan-2015::20:06:02 === +> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +> +> +> +> what could it be? +> any misconfiguration of my system (regarding ssl support)? +> what exactly does ranch expect from me? +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +From pdtwonotes at gmail.com Sun Jan 25 23:30:08 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Sun, 25 Jan 2015 17:30:08 -0500 +Subject: [99s-extend] Rewriting URLs +Message-ID: <1422225008.17343.6.camel@gmail.com> + +I am trying to write a middleware step that will modify the URL in a +request before it gets to the default static request handler. I can not +find an example of how to do this. What I?have so far: + +execute( Req, Env ) -> + HostUrl = cowboy_req:host_url(Req), + NewUrl = rewrite( HostUrl ), + NewReq = ??? + {ok, NewReq, Env}. + +How do I modify a Request object so that it contains my modified URL, +which cowboy_static will then process normally? My 'rewrite' function +converts logical directory names into real file-system paths, using a +dynamic algorithm that can not be simply written into cowboy's dispatch +rules. + +The dispatch rules I am using is as follows, where 'bz_libmap' is my +module containing the code above: + {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From pdtwonotes at gmail.com Mon Jan 26 06:09:49 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Mon, 26 Jan 2015 00:09:49 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <1422225008.17343.6.camel@gmail.com> +References: <1422225008.17343.6.camel@gmail.com> +Message-ID: + +Some progress. I think this is how the code should look in my middleware: + +execute( Req, Env ) -> + HostUrl = cowboy_req:path(Req), + NewUrl = rewrite( HostUrl ), + NewReq = cowboy_req:set( [{path,NewUrl}], Req), + {ok, NewReq, Env}. + +It is getting called, but cowboy_static is being passed the wrong +thing afterward. I think I do not understand how to write the +dispatch rule. The value of NewUrl is an absolute filename. + + {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, + +From essen at ninenines.eu Mon Jan 26 11:26:42 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 26 Jan 2015 11:26:42 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: +References: <1422225008.17343.6.camel@gmail.com> + +Message-ID: <54C61662.4050309@ninenines.eu> + +You have to change path_info too if your middleware is after the router. + +On 01/26/2015 06:09 AM, Paul Dickson wrote: +> Some progress. I think this is how the code should look in my middleware: +> +> execute( Req, Env ) -> +> HostUrl = cowboy_req:path(Req), +> NewUrl = rewrite( HostUrl ), +> NewReq = cowboy_req:set( [{path,NewUrl}], Req), +> {ok, NewReq, Env}. +> +> It is getting called, but cowboy_static is being passed the wrong +> thing afterward. I think I do not understand how to write the +> dispatch rule. The value of NewUrl is an absolute filename. +> +> {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}}, +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From essen at ninenines.eu Mon Jan 26 11:29:34 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 26 Jan 2015 11:29:34 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <54BFEFD8.7070003@bestmx.net> +References: <54BD5BB0.4000503@bestmx.net> <54BFEFD8.7070003@bestmx.net> +Message-ID: <54C6170E.6030709@ninenines.eu> + +Hey, this is a known issue with recent Erlang versions: +https://github.com/ninenines/ranch/issues/90 + +I don't have a good fix for it other than requiring ssl for using +Cowboy/Ranch. I probably will. + +On 01/21/2015 07:28 PM, e at bestmx.net wrote: +> reading the sources i have found that this crash i am trying to report +> is intended behavior, +> but +> it happens in the middle of the SHUTDOWN procedure! +> +> +> I tried to investigate how a relx's release shuts down +> and i have found it is merely one call to: init:stop/0 +> nothing else. +> +> the manual says: +> +> stop() -> ok +> +> All applications are taken down smoothly, all code is unloaded, and all +> ports are closed before the system terminates. If the -heart command +> line flag was given, the heart program is terminated before the Erlang +> node terminates. +> +> I end up totally clueless -- everything is rock solid yet it crashes. +> maybe there is some clue in the sequence of shutting down applications? +> +> does anything controls/defines that sequence? +> +> +> +> On 01/19/2015 08:32 PM, e at bestmx.net wrote: +>> Hello. +>> +>> i still have a problem with SSL. +>> as soon as i change cowboy:start_http call to cowboy:start_https +>> my release refuses to stop (when requested) +>> and when i revert to "http" it starts and stops normally. +>> +>> i am sure it is the only difference: start_http vs. start_https +>> +>> i am using relx with default settings as it was provided by cowboy +>> (Erlang R17, System: Debian "testing") +>> +>> here is my_app.erl: +>> +>> start(_Type, _Args) -> +>> Dispatch = +>> cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]), +>> +>> cowboy:start_https( https, 100, [ {port, 8765} +>> , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"} +>> , {certfile, ?Dir ++ "/ssl/server.crt"} +>> , {keyfile, ?Dir ++ "/ssl/server.key"} ] +>> , [{env, [{dispatch, Dispatch}]}]), +>> +>> online37_sup:start_link(). +>> +>> stop(_State) -> ok. +>> +>> +>> once i call: +>> release/bin/my_release stop +>> +>> the erlang.log repeats hundreds of: +>> +>> =ERROR REPORT==== 19-Jan-2015::20:06:02 === +>> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: +>> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]} +>> +>> +>> +>> +>> what could it be? +>> any misconfiguration of my system (regarding ssl support)? +>> what exactly does ranch expect from me? +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-- +Lo?c Hoguin +http://ninenines.eu + +From e at bestmx.net Mon Jan 26 15:30:56 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Mon, 26 Jan 2015 15:30:56 +0100 +Subject: [99s-extend] Cowboy + SSL +In-Reply-To: <54C6170E.6030709@ninenines.eu> +References: <54BD5BB0.4000503@bestmx.net> <54BFEFD8.7070003@bestmx.net> + <54C6170E.6030709@ninenines.eu> +Message-ID: <54C64FA0.7040808@bestmx.net> + +> Hey, this is a known issue with recent Erlang versions: +> https://github.com/ninenines/ranch/issues/90 + +sorry i didn't know a keyword for googling this issue + +well, it seems to me very interesting problem -- basically a dependency +that appears in runtime (if i do not pass an ssl socket to the ranch, +there will be no dependency). + +i dare to suggest few alternative approaches to the solution: + +(A) make the shutdown state distinguishable for the 'ranch_acceptor', so +that not to crash in one particular sub case of the preliminary socket +close. (a terrible STATEFUL solution, i do not dare to suggest how to +pass this state to the acceptor) + +(B) make it possible *in general* to pass additional dependencies to the +applications that your application depends on. (as for now i can define +in my .app.src any arbitrary deps for the "top" application, and then +this .app.src will be processed anyway, there is no harm in improving +this .app preparation procedure one step further, in order to affect +.app files of subordinate applications. (it is perhaps a suggestion for +relx devs, anyway, nobody forbid us to discuss it)) + +there are some alternative ways to achieve (B) + +(B1) +it would be a mere change of the type of the 'applications' option in +.app.src -- we may make it a tree instead of a list. +for example: + +{applications, [ + kernel, + stdlib, + mnesia, + {cowboy, [{ranch, [ssl]}]} +]} +%% which reads: my app requires all these, +%% and cowboy must require ranch and ranch must require ssl + +it could (or should?) be shortened to: + +(B2) +%% my app requires all these, +%% and *IF* 'ranch' is somehow required then it must require ssl +{applications, [ + kernel, + stdlib, + mnesia, + cowboy, + {ranch, [ssl]} +]} + +this in turn makes separation possible: + +(B3) +we specify all applications we require as a plain list, and then we +specify PARTIAL ORDER: we need some certain pairs of applications to be +started in certain sequences. + +{applications, [ + kernel, + stdlib, + mnesia, + ssl, + cowboy +]}, +{sequence, [ + [ssl, ranch], +]} + +%% which reads: my app requires those apps to start +%% and among these it requires the ssl to be started BEFORE ranch + +%% generally we may specify any amount +%% of subsequences we care about: +{sequence, [ + [ssl, ranch], + [ranch, cowboy_lib, cowboy], + [appA1, appA2, appA3, ...], + ... +]} + +of course the specified sequence MIGHT BE IMPOSSIBLE (self-refuting) and +it needs to be verified, which is formally possible. + +From pdtwonotes at gmail.com Mon Jan 26 22:54:09 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Mon, 26 Jan 2015 16:54:09 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <54C61662.4050309@ninenines.eu> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> +Message-ID: <1422309249.26262.15.camel@gmail.com> + +On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +> You have to change path_info too if your middleware is after the router. +> +I have added that. My cowboy:start_http parameters include this: + {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +which I think means bz_libmap will get called on *every* request. This +seems to work. Among the dispatch rules is this line: + {"/music/[...]", cowboy_static, {dir, "", ""}}, +so any request starting with "/music/ will do a standard file fetch. +But due to the middlewares setup, bz_libmap will get a chance to +look at it first. + +bz_libmap checks the path to see if it starts with "/music/", and if +not, it just returns {ok,Req,Env} and lets processing proceed normally. +This works, and other dispatch rules take care of it, usually fetching +files from priv_dir. + +But if bz_libmap sees "/music/" at the start of the URL it transforms +the URL into something else, an absolute filename typically of an mp3 +file. This is what I want cowboy_static to process. Hopefully, this +does not run through the dispatch rules again. + +bz_libmap computes a new path and a new path_info and sets them with a +cowboy_req:set call. I am not sure what path_info should look like at +this point, because the path is no longer covered by any of the dispatch +rules. I do not want it to be, as that would allow a browser to fetch +any file in the file system, unchecked. + +But what happens is any attempts to fetch /music/Anything result in a +status 400 error. + +The other approach I was considering was to make my own handler, based +on cowboy_static, that does the URL/File transformation internally. But +even that might not be right, since it eventually upgrades to +cowboy_rest and there is more processing after that. This approach +seems inelegant. + +The actual only call to file:open I found in all of cowboy is in +cowboy_spdy. + + + + +From essen at ninenines.eu Tue Jan 27 11:13:41 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 11:13:41 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <1422309249.26262.15.camel@gmail.com> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> +Message-ID: <54C764D5.5020404@ninenines.eu> + +On 01/26/2015 10:54 PM, Paul Dickson wrote: +> On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +>> You have to change path_info too if your middleware is after the router. +>> +> I have added that. My cowboy:start_http parameters include this: +> {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +> which I think means bz_libmap will get called on *every* request. This +> seems to work. Among the dispatch rules is this line: +> {"/music/[...]", cowboy_static, {dir, "", ""}}, + +Is it the actual line? Cause {dir, "", ""} is wrong, the third element +must be an etag or mimetype tuple. + +Otherwise, I need a more complete error, or code. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:07:48 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:07:48 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <54C764D5.5020404@ninenines.eu> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> +Message-ID: <1422364068.30127.5.camel@gmail.com> + +On Tue, 2015-01-27 at 11:13 +0100, Lo?c Hoguin wrote: +> On 01/26/2015 10:54 PM, Paul Dickson wrote: +> > On Mon, 2015-01-26 at 11:26 +0100, Lo?c Hoguin wrote: +> >> You have to change path_info too if your middleware is after the router. +> >> +> > I have added that. My cowboy:start_http parameters include this: +> > {middlewares, [cowboy_router, bz_libmap, cowboy_handler]} +> > which I think means bz_libmap will get called on *every* request. This +> > seems to work. Among the dispatch rules is this line: +> > {"/music/[...]", cowboy_static, {dir, "", ""}}, +> +> Is it the actual line? Cause {dir, "", ""} is wrong, the third element +> must be an etag or mimetype tuple. +> +> Otherwise, I need a more complete error, or code. + +I changed the rule line to: + + {"/music/[...]", cowboy_static, {dir, "", [ + {mimetypes, cow_mimetypes, all}]}}, + +The client I am using is 'mplayer'. The error message is: + + Server returned 400:Bad Request + Failed to parse header. + Failed, exiting. + +I also included some tracing in my middleware module to print +out the new path and path_info values it is setting, showing +the result of the rewrite algorithm. + + Path <<"/music/Library/Folk/Swiss/Alphorn.ogg">> + Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, + <<"Alphorn.ogg">>] + + + +From essen at ninenines.eu Tue Jan 27 14:10:58 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 14:10:58 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <1422364068.30127.5.camel@gmail.com> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> <1422364068.30127.5.camel@gmail.com> +Message-ID: <54C78E62.9020307@ninenines.eu> + +On 01/27/2015 02:07 PM, Paul Dickson wrote: +> Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +> <<"Alphorn.ogg">>] + +Should be from Library onward, and not include the first two elements. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:24:30 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:24:30 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <54C78E62.9020307@ninenines.eu> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> <1422364068.30127.5.camel@gmail.com> + <54C78E62.9020307@ninenines.eu> +Message-ID: <1422365070.30127.8.camel@gmail.com> + +On Tue, 2015-01-27 at 14:10 +0100, Lo?c Hoguin wrote: + +> On 01/27/2015 02:07 PM, Paul Dickson wrote: +> > Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +> > <<"Alphorn.ogg">>] +> +> Should be from Library onward, and not include the first two elements. +> + + +This is perhaps a confusing case, because the incoming URL and the +transformed URL both start with "/music". What if that was not the +case, and the resulting path was, for example, + + /home/me/music/Folk/Swiss/Alphorn.ogg + +which does not match anything in the rules at all? Is that allowed, or +must the rewritten URL also match a rule? +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Jan 27 14:29:20 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 27 Jan 2015 14:29:20 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <1422365070.30127.8.camel@gmail.com> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> <1422364068.30127.5.camel@gmail.com> + <54C78E62.9020307@ninenines.eu> <1422365070.30127.8.camel@gmail.com> +Message-ID: <54C792B0.3040406@ninenines.eu> + +On 01/27/2015 02:24 PM, Paul Dickson wrote: +> On Tue, 2015-01-27 at 14:10 +0100, Lo?c Hoguin wrote: +>> On 01/27/2015 02:07 PM, Paul Dickson wrote: +>> > Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>, +>> > <<"Alphorn.ogg">>] +>> +>> Should be from Library onward, and not include the first two elements. +>> +> +> This is perhaps a confusing case, because the incoming URL and the +> transformed URL both start with "/music". What if that was not the +> case, and the resulting path was, for example, +> +> /home/me/music/Folk/Swiss/Alphorn.ogg +> +> which does not match anything in the rules at all? Is that allowed, or +> must the rewritten URL also match a rule? + +Middlewares execute in order and only once, so not sure what you're asking. + +Again I'd need to see some code to help you as I am quite confused by +what you are trying to do and what your issue is. + +-- +Lo?c Hoguin +http://ninenines.eu + +From pdtwonotes at gmail.com Tue Jan 27 14:44:14 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Tue, 27 Jan 2015 08:44:14 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <54C792B0.3040406@ninenines.eu> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> <1422364068.30127.5.camel@gmail.com> + <54C78E62.9020307@ninenines.eu> <1422365070.30127.8.camel@gmail.com> + <54C792B0.3040406@ninenines.eu> +Message-ID: <1422366254.30127.15.camel@gmail.com> + +Ok, here is all the code in bz_libmap.erl + +execute(Req, Env) -> + Path = cowboy_req:path(Req), + Parts = filename:split(Path), + + case cowboy_req:method(Req) of + <<"GET">> -> + % Check for "/music/" requests + rewrite( Parts, Req, Env ); + _Other -> + {ok, Req, Env} + end. + +rewrite( [<<"/">>, <<"music">>, LibName | UrlParts], Req, Env ) -> + % We want URLs of the form "/music/LIBNAME/everythingelse" + % Get library definition. If we do not know that name, then they + % are asking for something that does not exist. + case bz_db:get_library( LibName ) of + [] -> + io:format("No such library '~s'~n", [LibName] ), + {stop, cowboy_req:reply(404, Req)}; + + L when is_record(L,library) -> + % Replace the library name with the library base. + % This will be the head of an absolute file path. + LibBase = L#library.base, + NewPath = filename:join([LibBase | UrlParts]), + NewInfo = filename:split(NewPath), + Req2 = cowboy_req:set( [ + {path_info,[NewPath]}, + {path, [NewPath]}], Req), + {ok, Req2, Env} + end; +rewrite( _AnythingElse, Req, Env ) -> + {ok, Req, Env}. + + + + +From pdtwonotes at gmail.com Thu Jan 29 23:23:35 2015 +From: pdtwonotes at gmail.com (Paul Dickson) +Date: Thu, 29 Jan 2015 17:23:35 -0500 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: <1422366254.30127.15.camel@gmail.com> +References: <1422225008.17343.6.camel@gmail.com> + + <54C61662.4050309@ninenines.eu> + <1422309249.26262.15.camel@gmail.com> + <54C764D5.5020404@ninenines.eu> + <1422364068.30127.5.camel@gmail.com> + <54C78E62.9020307@ninenines.eu> + <1422365070.30127.8.camel@gmail.com> + <54C792B0.3040406@ninenines.eu> + <1422366254.30127.15.camel@gmail.com> +Message-ID: + +The status 400 is coming from cowboy_rest, when it complains that +handler cowboy_static lacks the functions 'service_available', +'known_methods', 'uri_too_long', and 'allowed_methods'. Which indeed +it does not have. + +The only place I mention cowboy_static is in the dispatch rule: + {"/music/[...]", cowboy_static, {dir, "", [ + {mimetypes, cow_mimetypes, all}]}}, + +From essen at ninenines.eu Thu Jan 29 23:24:59 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 29 Jan 2015 23:24:59 +0100 +Subject: [99s-extend] Rewriting URLs +In-Reply-To: +References: <1422225008.17343.6.camel@gmail.com> <54C61662.4050309@ninenines.eu> <1422309249.26262.15.camel@gmail.com> <54C764D5.5020404@ninenines.eu> <1422364068.30127.5.camel@gmail.com> <54C78E62.9020307@ninenines.eu> <1422365070.30127.8.camel@gmail.com> <54C792B0.3040406@ninenines.eu> <1422366254.30127.15.camel@gmail.com> + +Message-ID: <54CAB33B.7070606@ninenines.eu> + +They are optional callbacks, so I doubt that's it. + +On 01/29/2015 11:23 PM, Paul Dickson wrote: +> The status 400 is coming from cowboy_rest, when it complains that +> handler cowboy_static lacks the functions 'service_available', +> 'known_methods', 'uri_too_long', and 'allowed_methods'. Which indeed +> it does not have. +> +> The only place I mention cowboy_static is in the dispatch rule: +> {"/music/[...]", cowboy_static, {dir, "", [ +> {mimetypes, cow_mimetypes, all}]}}, +> + +-- +Lo?c Hoguin +http://ninenines.eu + diff --git a/_build/static/archives/extend/2015-January/000484.html b/_build/static/archives/extend/2015-January/000484.html new file mode 100644 index 00000000..74425562 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000484.html @@ -0,0 +1,110 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ e at bestmx.net + e at bestmx.net +
+ Sat Jan 10 14:55:58 CET 2015 +

+
+ +
Hello all.
+
+I am trying to alter my cowboy-based websocket server from plain to SSL 
+connection.
+And I found out that I have failed to understand very basics of the 
+combination of WS and SSL.
+
+As far as i've understood the very nature of the WS it is a bit altered 
+http connection (i open the http connection first, and then i change its 
+status to WS)
+
+On the other hand the whole "HTTP story" could be wrapped into SSL, so 
+that SSL is an outer layer of data encoding (as seen transparent by an 
+application)
+
+thus,
+if I open HTTPS connection (which implies SSL enveloping) and then alter 
+the connection status to WS, the whole "WS story" appears naturally 
+INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION.
+
+Is it true?
+
+In this regard i can hardly find a place in this world for the "WSS" 
+term, what does it stand for?
+
+Please, help me fit it in my head.
+
+However, i might be confusing some Client-Side entities, that are 
+involved in the process of starting up my WebSocket.
+
+I am using a Browser with JavaScript.
+
+The semantics of the very WebSocket.start() operation is not enough 
+clear to me. Please, do not laugh.
+
+when i do JS WebSocket.start() does it:
+(a) opens an http connection and then alters it to WS
+(b) alters the connection in the context of which the JS process is running
+????
+
+I'll be damned if the answer was lying on the surface of the internet!
+
+The third part of this ugly question is about cowboy actually.
+How all these entities mentioned above do map into my_app.erl file?
+what particular bits of cowboy's "configuration" (may i call this 
+particular piece of code a "setup" or "config"?) affect what aspects of 
+the connection initialization.
+
+well, i am afraid it could be put in a simpler way:
+"Exactly When and Where the WSS story begins?"
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000485.html b/_build/static/archives/extend/2015-January/000485.html new file mode 100644 index 00000000..03cccb2d --- /dev/null +++ b/_build/static/archives/extend/2015-January/000485.html @@ -0,0 +1,136 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Jan 10 15:21:04 CET 2015 +

+
+ +
Assuming you have no problem understanding HTTPS, the only differences 
+between plain Websocket and HTTPS Websocket are as follow:
+
+In your browser, your ws:// links become wss:// links.
+
+In Cowboy, use start_https instead of start_http. There is no change 
+required in your code otherwise.
+
+It may or may not be possible to use wss:// from an HTTP page or ws:// 
+from an HTTPS page, I'm not too up to date on that one. Otherwise, ws:// 
+from HTTP page or wss:// from HTTPS page works as intended.
+
+There is no requirement that a Websocket connection is initiated on a 
+new TCP connection. I am not sure if browsers reuse connections or not.
+
+On 01/10/2015 02:55 PM, e at bestmx.net wrote:
+> Hello all.
+>
+> I am trying to alter my cowboy-based websocket server from plain to SSL
+> connection.
+> And I found out that I have failed to understand very basics of the
+> combination of WS and SSL.
+>
+> As far as i've understood the very nature of the WS it is a bit altered
+> http connection (i open the http connection first, and then i change its
+> status to WS)
+>
+> On the other hand the whole "HTTP story" could be wrapped into SSL, so
+> that SSL is an outer layer of data encoding (as seen transparent by an
+> application)
+>
+> thus,
+> if I open HTTPS connection (which implies SSL enveloping) and then alter
+> the connection status to WS, the whole "WS story" appears naturally
+> INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION.
+>
+> Is it true?
+>
+> In this regard i can hardly find a place in this world for the "WSS"
+> term, what does it stand for?
+>
+> Please, help me fit it in my head.
+>
+> However, i might be confusing some Client-Side entities, that are
+> involved in the process of starting up my WebSocket.
+>
+> I am using a Browser with JavaScript.
+>
+> The semantics of the very WebSocket.start() operation is not enough
+> clear to me. Please, do not laugh.
+>
+> when i do JS WebSocket.start() does it:
+> (a) opens an http connection and then alters it to WS
+> (b) alters the connection in the context of which the JS process is running
+> ????
+>
+> I'll be damned if the answer was lying on the surface of the internet!
+>
+> The third part of this ugly question is about cowboy actually.
+> How all these entities mentioned above do map into my_app.erl file?
+> what particular bits of cowboy's "configuration" (may i call this
+> particular piece of code a "setup" or "config"?) affect what aspects of
+> the connection initialization.
+>
+> well, i am afraid it could be put in a simpler way:
+> "Exactly When and Where the WSS story begins?"
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000486.html b/_build/static/archives/extend/2015-January/000486.html new file mode 100644 index 00000000..b3802139 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000486.html @@ -0,0 +1,81 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ e at bestmx.net + e at bestmx.net +
+ Sat Jan 10 15:28:52 CET 2015 +

+
+ +
> In Cowboy, use start_https instead of start_http.
+
+thanx! it makes a lot of sense for me.
+tell me please what deps should be declared in the .app file?
+
+is the following correct?
+
+	{applications, [
+		kernel,
+		stdlib,
+		crypto,
+		public_key,
+		ssl,
+		cowboy
+	]},
+
+does the order matters?
+
+(i borrowed that from the internet without deep understanding of the 
+roles of each app on the list)
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000487.html b/_build/static/archives/extend/2015-January/000487.html new file mode 100644 index 00000000..7a69ae5c --- /dev/null +++ b/_build/static/archives/extend/2015-January/000487.html @@ -0,0 +1,90 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ Loïc Hoguin + essen at ninenines.eu +
+ Sat Jan 10 15:34:41 CET 2015 +

+
+ +
Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter 
+I think.
+
+On 01/10/2015 03:28 PM, e at bestmx.net wrote:
+>> In Cowboy, use start_https instead of start_http.
+>
+> thanx! it makes a lot of sense for me.
+> tell me please what deps should be declared in the .app file?
+>
+> is the following correct?
+>
+>      {applications, [
+>          kernel,
+>          stdlib,
+>          crypto,
+>          public_key,
+>          ssl,
+>          cowboy
+>      ]},
+>
+> does the order matters?
+>
+> (i borrowed that from the internet without deep understanding of the
+> roles of each app on the list)
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000488.html b/_build/static/archives/extend/2015-January/000488.html new file mode 100644 index 00000000..ada46131 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000488.html @@ -0,0 +1,112 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ Lee Sylvester + lee.sylvester at gmail.com +
+ Sat Jan 10 15:39:41 CET 2015 +

+
+ +
I use Cowboy for websockets, but I find it’s a lot easier (and less stressful) to run Nginx in front of it to provide the SSL layer.
+
+Lee
+
+
+> On 10 Jan 2015, at 13:55, e at bestmx.net wrote:
+> 
+> Hello all.
+> 
+> I am trying to alter my cowboy-based websocket server from plain to SSL connection.
+> And I found out that I have failed to understand very basics of the combination of WS and SSL.
+> 
+> As far as i've understood the very nature of the WS it is a bit altered http connection (i open the http connection first, and then i change its status to WS)
+> 
+> On the other hand the whole "HTTP story" could be wrapped into SSL, so that SSL is an outer layer of data encoding (as seen transparent by an application)
+> 
+> thus,
+> if I open HTTPS connection (which implies SSL enveloping) and then alter the connection status to WS, the whole "WS story" appears naturally INSIDE THE PREVIOUSLY ESTABLISHED SSL CONNECTION.
+> 
+> Is it true?
+> 
+> In this regard i can hardly find a place in this world for the "WSS" term, what does it stand for?
+> 
+> Please, help me fit it in my head.
+> 
+> However, i might be confusing some Client-Side entities, that are involved in the process of starting up my WebSocket.
+> 
+> I am using a Browser with JavaScript.
+> 
+> The semantics of the very WebSocket.start() operation is not enough clear to me. Please, do not laugh.
+> 
+> when i do JS WebSocket.start() does it:
+> (a) opens an http connection and then alters it to WS
+> (b) alters the connection in the context of which the JS process is running
+> ????
+> 
+> I'll be damned if the answer was lying on the surface of the internet!
+> 
+> The third part of this ugly question is about cowboy actually.
+> How all these entities mentioned above do map into my_app.erl file?
+> what particular bits of cowboy's "configuration" (may i call this particular piece of code a "setup" or "config"?) affect what aspects of the connection initialization.
+> 
+> well, i am afraid it could be put in a simpler way:
+> "Exactly When and Where the WSS story begins?"
+> 
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000489.html b/_build/static/archives/extend/2015-January/000489.html new file mode 100644 index 00000000..6539271d --- /dev/null +++ b/_build/static/archives/extend/2015-January/000489.html @@ -0,0 +1,73 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ e at bestmx.net + e at bestmx.net +
+ Sat Jan 10 15:46:23 CET 2015 +

+
+ +
 > I use Cowboy for websockets, but I find it’s a lot easier (and less
+ > stressful) to run Nginx in front of it to provide the SSL layer.
+
+well, nginx is my choice for almost everything, still i am trying to 
+minimize amount of intermediate software wherever possible.
+
+P.S.
+with nginx and postgreSQL i have managed to eliminate any trace of 
+server-side scripting  in my previous project :)
+just nginx connected to Postgres.
+
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000490.html b/_build/static/archives/extend/2015-January/000490.html new file mode 100644 index 00000000..b8782f15 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000490.html @@ -0,0 +1,90 @@ + + + + [99s-extend] websocket over ssl + + + + + + + + + + +

[99s-extend] websocket over ssl

+ e at bestmx.net + e at bestmx.net +
+ Sat Jan 10 16:28:19 CET 2015 +

+
+ +
thanx again.
+now everything "magically" works :)
+
+
+On 01/10/2015 03:34 PM, Loïc Hoguin wrote:
+> Just kernel, stdlib, ssl, cowboy should be enough. Order does not matter
+> I think.
+>
+> On 01/10/2015 03:28 PM, e at bestmx.net wrote:
+>>> In Cowboy, use start_https instead of start_http.
+>>
+>> thanx! it makes a lot of sense for me.
+>> tell me please what deps should be declared in the .app file?
+>>
+>> is the following correct?
+>>
+>>      {applications, [
+>>          kernel,
+>>          stdlib,
+>>          crypto,
+>>          public_key,
+>>          ssl,
+>>          cowboy
+>>      ]},
+>>
+>> does the order matters?
+>>
+>> (i borrowed that from the internet without deep understanding of the
+>> roles of each app on the list)
+>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000491.html b/_build/static/archives/extend/2015-January/000491.html new file mode 100644 index 00000000..b4f397a0 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000491.html @@ -0,0 +1,80 @@ + + + + [99s-extend] cowboy and handling exceptions + + + + + + + + + + +

[99s-extend] cowboy and handling exceptions

+ Stefan Strigler + stefan.strigler at gmail.com +
+ Wed Jan 14 17:45:41 CET 2015 +

+
+ +
Hey there,
+
+maybe I'm missing the obvious. What I want to do is add some generic
+handler for exception handling. Say we have a set of resources some of
+which delegating stuff to external, other services. These calls might
+result in a
+
+throw({error, timeout})
+
+for instance. How would I add/modify cowboy's middleware (right place?) to
+handle those (known) exception and return a custom error (like 504 -
+Gateway Timeout).
+
+Thanks for any hints,
+
+Steve
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150114/3267f73e/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000492.html b/_build/static/archives/extend/2015-January/000492.html new file mode 100644 index 00000000..2c11f0b5 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000492.html @@ -0,0 +1,91 @@ + + + + [99s-extend] cowboy and handling exceptions + + + + + + + + + + +

[99s-extend] cowboy and handling exceptions

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jan 14 18:49:39 CET 2015 +

+
+ +
I don't know, there is no such thing in Cowboy. :-)
+
+On 01/14/2015 05:45 PM, Stefan Strigler wrote:
+> Hey there,
+>
+> maybe I'm missing the obvious. What I want to do is add some generic
+> handler for exception handling. Say we have a set of resources some of
+> which delegating stuff to external, other services. These calls might
+> result in a
+>
+> throw({error, timeout})
+>
+> for instance. How would I add/modify cowboy's middleware (right place?)
+> to handle those (known) exception and return a custom error (like 504 -
+> Gateway Timeout).
+>
+> Thanks for any hints,
+>
+> Steve
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000493.html b/_build/static/archives/extend/2015-January/000493.html new file mode 100644 index 00000000..cb5bf10f --- /dev/null +++ b/_build/static/archives/extend/2015-January/000493.html @@ -0,0 +1,98 @@ + + + + [99s-extend] cowboy and handling exceptions + + + + + + + + + + +

[99s-extend] cowboy and handling exceptions

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jan 14 18:50:21 CET 2015 +

+
+ +
I send too early...
+
+I want to add a hook for when Cowboy receives exceptions in Cowboy 2, so 
+at that point you will be able to do it. But nothing in current Cowboy.
+
+On 01/14/2015 06:49 PM, Loïc Hoguin wrote:
+> I don't know, there is no such thing in Cowboy. :-)
+>
+> On 01/14/2015 05:45 PM, Stefan Strigler wrote:
+>> Hey there,
+>>
+>> maybe I'm missing the obvious. What I want to do is add some generic
+>> handler for exception handling. Say we have a set of resources some of
+>> which delegating stuff to external, other services. These calls might
+>> result in a
+>>
+>> throw({error, timeout})
+>>
+>> for instance. How would I add/modify cowboy's middleware (right place?)
+>> to handle those (known) exception and return a custom error (like 504 -
+>> Gateway Timeout).
+>>
+>> Thanks for any hints,
+>>
+>> Steve
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000494.html b/_build/static/archives/extend/2015-January/000494.html new file mode 100644 index 00000000..fb053469 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000494.html @@ -0,0 +1,105 @@ + + + + [99s-extend] Cowboy + SSL + + + + + + + + + + +

[99s-extend] Cowboy + SSL

+ e at bestmx.net + e at bestmx.net +
+ Mon Jan 19 20:32:00 CET 2015 +

+
+ +
Hello.
+
+i still have a problem with SSL.
+as soon as i change cowboy:start_http call to cowboy:start_https
+my release refuses to stop (when requested)
+and when i revert to "http" it starts and stops normally.
+
+i am sure it is the only difference: start_http vs. start_https
+
+i am using relx with default settings as it was provided by cowboy
+(Erlang R17, System: Debian "testing")
+
+here is my_app.erl:
+
+start(_Type, _Args) ->
+   Dispatch =
+   cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]),
+
+   cowboy:start_https( https, 100, [ {port, 8765}
+   , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"}
+   , {certfile, ?Dir ++ "/ssl/server.crt"}
+   , {keyfile, ?Dir ++ "/ssl/server.key"} ]
+   , [{env, [{dispatch, Dispatch}]}]),
+
+   online37_sup:start_link().
+
+stop(_State) -> ok.
+
+
+once i call:
+release/bin/my_release stop
+
+the erlang.log repeats hundreds of:
+
+=ERROR REPORT==== 19-Jan-2015::20:06:02 ===
+Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value: 
+{{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+
+
+what could it be?
+any misconfiguration of my system (regarding ssl support)?
+what exactly does ranch expect from me?
+
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000495.html b/_build/static/archives/extend/2015-January/000495.html new file mode 100644 index 00000000..155c3fda --- /dev/null +++ b/_build/static/archives/extend/2015-January/000495.html @@ -0,0 +1,138 @@ + + + + [99s-extend] Cowboy + SSL + + + + + + + + + + +

[99s-extend] Cowboy + SSL

+ e at bestmx.net + e at bestmx.net +
+ Wed Jan 21 19:28:40 CET 2015 +

+
+ +
reading the sources i have found that this crash i am trying to report 
+is intended behavior,
+but
+it happens in the middle of the SHUTDOWN procedure!
+
+
+I tried to investigate how a relx's release shuts down
+and i have found it is merely one call to: init:stop/0
+nothing else.
+
+the manual says:
+
+stop() -> ok
+
+All applications are taken down smoothly, all code is unloaded, and all 
+ports are closed before the system terminates. If the -heart command 
+line flag was given, the heart program is terminated before the Erlang 
+node terminates.
+
+I end up totally clueless -- everything is rock solid yet it crashes.
+maybe there is some clue in the sequence of shutting down applications?
+
+does anything controls/defines that sequence?
+
+
+
+On 01/19/2015 08:32 PM, e at bestmx.net wrote:
+> Hello.
+>
+> i still have a problem with SSL.
+> as soon as i change cowboy:start_http call to cowboy:start_https
+> my release refuses to stop (when requested)
+> and when i revert to "http" it starts and stops normally.
+>
+> i am sure it is the only difference: start_http vs. start_https
+>
+> i am using relx with default settings as it was provided by cowboy
+> (Erlang R17, System: Debian "testing")
+>
+> here is my_app.erl:
+>
+> start(_Type, _Args) ->
+>    Dispatch =
+>    cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]),
+>
+>    cowboy:start_https( https, 100, [ {port, 8765}
+>    , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"}
+>    , {certfile, ?Dir ++ "/ssl/server.crt"}
+>    , {keyfile, ?Dir ++ "/ssl/server.key"} ]
+>    , [{env, [{dispatch, Dispatch}]}]),
+>
+>    online37_sup:start_link().
+>
+> stop(_State) -> ok.
+>
+>
+> once i call:
+> release/bin/my_release stop
+>
+> the erlang.log repeats hundreds of:
+>
+> =ERROR REPORT==== 19-Jan-2015::20:06:02 ===
+> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value:
+> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+>
+>
+>
+> what could it be?
+> any misconfiguration of my system (regarding ssl support)?
+> what exactly does ranch expect from me?
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000496.html b/_build/static/archives/extend/2015-January/000496.html new file mode 100644 index 00000000..880322a2 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000496.html @@ -0,0 +1,86 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Sun Jan 25 23:30:08 CET 2015 +

+
+ +
I am trying to write a middleware step that will modify the URL in a
+request before it gets to the default static request handler.  I can not
+find an example of how to do this.  What I　have so far:
+
+execute( Req, Env ) ->
+    HostUrl = cowboy_req:host_url(Req),
+    NewUrl = rewrite( HostUrl ),
+    NewReq = ???
+    {ok, NewReq, Env}.
+
+How do I modify a Request object so that it contains my modified URL,
+which cowboy_static will then process normally?  My 'rewrite' function
+converts logical directory names into real file-system paths, using a
+dynamic algorithm that can not be simply written into cowboy's dispatch
+rules.
+
+The dispatch rules I am using is as follows, where 'bz_libmap' is my
+module containing the code above:
+	    {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}},
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150125/370811e4/attachment.html>
+
+ + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000497.html b/_build/static/archives/extend/2015-January/000497.html new file mode 100644 index 00000000..4cb02878 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000497.html @@ -0,0 +1,76 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Mon Jan 26 06:09:49 CET 2015 +

+
+ +
Some progress.  I think this is how the code should look in my middleware:
+
+execute( Req, Env ) ->
+    HostUrl = cowboy_req:path(Req),
+    NewUrl = rewrite( HostUrl ),
+    NewReq = cowboy_req:set( [{path,NewUrl}], Req),
+    {ok, NewReq, Env}.
+
+It is getting called, but cowboy_static is being passed the wrong
+thing afterward.  I think I do not understand how to write the
+dispatch rule.  The value of NewUrl is an absolute filename.
+
+    {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}},
+
+ + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000498.html b/_build/static/archives/extend/2015-January/000498.html new file mode 100644 index 00000000..5762dfa4 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000498.html @@ -0,0 +1,88 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Jan 26 11:26:42 CET 2015 +

+
+ +
You have to change path_info too if your middleware is after the router.
+
+On 01/26/2015 06:09 AM, Paul Dickson wrote:
+> Some progress.  I think this is how the code should look in my middleware:
+>
+> execute( Req, Env ) ->
+>      HostUrl = cowboy_req:path(Req),
+>      NewUrl = rewrite( HostUrl ),
+>      NewReq = cowboy_req:set( [{path,NewUrl}], Req),
+>      {ok, NewReq, Env}.
+>
+> It is getting called, but cowboy_static is being passed the wrong
+> thing afterward.  I think I do not understand how to write the
+> dispatch rule.  The value of NewUrl is an absolute filename.
+>
+>      {"/music/[...]", cowboy_static, {dir, bz_libmap, ""}},
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000499.html b/_build/static/archives/extend/2015-January/000499.html new file mode 100644 index 00000000..36cc0ebc --- /dev/null +++ b/_build/static/archives/extend/2015-January/000499.html @@ -0,0 +1,153 @@ + + + + [99s-extend] Cowboy + SSL + + + + + + + + + + +

[99s-extend] Cowboy + SSL

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Jan 26 11:29:34 CET 2015 +

+
+ +
Hey, this is a known issue with recent Erlang versions: 
+https://github.com/ninenines/ranch/issues/90
+
+I don't have a good fix for it other than requiring ssl for using 
+Cowboy/Ranch. I probably will.
+
+On 01/21/2015 07:28 PM, e at bestmx.net wrote:
+> reading the sources i have found that this crash i am trying to report
+> is intended behavior,
+> but
+> it happens in the middle of the SHUTDOWN procedure!
+>
+>
+> I tried to investigate how a relx's release shuts down
+> and i have found it is merely one call to: init:stop/0
+> nothing else.
+>
+> the manual says:
+>
+> stop() -> ok
+>
+> All applications are taken down smoothly, all code is unloaded, and all
+> ports are closed before the system terminates. If the -heart command
+> line flag was given, the heart program is terminated before the Erlang
+> node terminates.
+>
+> I end up totally clueless -- everything is rock solid yet it crashes.
+> maybe there is some clue in the sequence of shutting down applications?
+>
+> does anything controls/defines that sequence?
+>
+>
+>
+> On 01/19/2015 08:32 PM, e at bestmx.net wrote:
+>> Hello.
+>>
+>> i still have a problem with SSL.
+>> as soon as i change cowboy:start_http call to cowboy:start_https
+>> my release refuses to stop (when requested)
+>> and when i revert to "http" it starts and stops normally.
+>>
+>> i am sure it is the only difference: start_http vs. start_https
+>>
+>> i am using relx with default settings as it was provided by cowboy
+>> (Erlang R17, System: Debian "testing")
+>>
+>> here is my_app.erl:
+>>
+>> start(_Type, _Args) ->
+>>    Dispatch =
+>>    cowboy_router:compile([{'_', [{"/start", ws_handler, []}]}]),
+>>
+>>    cowboy:start_https( https, 100, [ {port, 8765}
+>>    , {cacertfile, ?Dir ++ "/ssl/cowboy-ca.crt"}
+>>    , {certfile, ?Dir ++ "/ssl/server.crt"}
+>>    , {keyfile, ?Dir ++ "/ssl/server.key"} ]
+>>    , [{env, [{dispatch, Dispatch}]}]),
+>>
+>>    online37_sup:start_link().
+>>
+>> stop(_State) -> ok.
+>>
+>>
+>> once i call:
+>> release/bin/my_release stop
+>>
+>> the erlang.log repeats hundreds of:
+>>
+>> =ERROR REPORT==== 19-Jan-2015::20:06:02 ===
+>> Error in process <0.234.0> on node 'online37 at 127.0.0.1' with exit value:
+>> {{case_clause,{error,closed}},[{ranch_acceptor,loop,3,[{file,"src/ranch_acceptor.erl"},{line,28}]}]}
+>>
+>>
+>>
+>>
+>> what could it be?
+>> any misconfiguration of my system (regarding ssl support)?
+>> what exactly does ranch expect from me?
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000500.html b/_build/static/archives/extend/2015-January/000500.html new file mode 100644 index 00000000..c77ec536 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000500.html @@ -0,0 +1,145 @@ + + + + [99s-extend] Cowboy + SSL + + + + + + + + + + +

[99s-extend] Cowboy + SSL

+ e at bestmx.net + e at bestmx.net +
+ Mon Jan 26 15:30:56 CET 2015 +

+
+ +
> Hey, this is a known issue with recent Erlang versions:
+> https://github.com/ninenines/ranch/issues/90
+
+sorry i didn't know a keyword for googling this issue
+
+well, it seems to me very interesting problem -- basically a dependency 
+that appears in runtime (if i do not pass an ssl socket to the ranch, 
+there will be no dependency).
+
+i dare to suggest few alternative approaches to the solution:
+
+(A) make the shutdown state distinguishable for the 'ranch_acceptor', so 
+that not to crash in one particular sub case of the preliminary socket 
+close. (a terrible STATEFUL solution, i do not dare to suggest how to 
+pass this state to the acceptor)
+
+(B) make it possible *in general* to pass additional dependencies to the 
+applications that your application depends on. (as for now i can define 
+in my .app.src any arbitrary deps for the "top" application, and then 
+this .app.src will be processed anyway, there is no harm in improving 
+this .app preparation procedure one step further, in order to affect 
+.app files of subordinate applications. (it is perhaps a suggestion for 
+relx devs, anyway, nobody forbid us to discuss it))
+
+there are some alternative ways to achieve (B)
+
+(B1)
+it would be a mere change of the type of the 'applications' option in 
+.app.src -- we may make it a tree instead of a list.
+for example:
+
+{applications, [
+         kernel,
+         stdlib,
+         mnesia,
+         {cowboy, [{ranch, [ssl]}]}
+]}
+%% which reads: my app requires all these,
+%% and cowboy must require ranch and ranch must require ssl
+
+it could (or should?) be shortened to:
+
+(B2)
+%% my app requires all these,
+%% and *IF* 'ranch' is somehow required then it must require ssl
+{applications, [
+         kernel,
+         stdlib,
+         mnesia,
+         cowboy,
+	{ranch, [ssl]}
+]}
+
+this in turn makes separation possible:
+
+(B3)
+we specify all applications we require as a plain list, and then we 
+specify PARTIAL ORDER: we need some certain pairs of applications to be 
+started in certain sequences.
+
+{applications, [
+         kernel,
+         stdlib,
+         mnesia,
+	ssl,
+         cowboy
+]},
+{sequence, [
+  	[ssl, ranch],
+]}
+
+%% which reads: my app requires those apps to start
+%% and among these it requires the ssl to be started BEFORE ranch
+
+%% generally we may specify any amount
+%% of subsequences we care about:
+{sequence, [
+  	[ssl, ranch],
+  	[ranch, cowboy_lib, cowboy],
+  	[appA1, appA2, appA3, ...],
+         ...
+]}
+
+of course the specified sequence MIGHT BE IMPOSSIBLE (self-refuting) and 
+it needs to be verified, which is formally possible.
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000501.html b/_build/static/archives/extend/2015-January/000501.html new file mode 100644 index 00000000..71c5f68c --- /dev/null +++ b/_build/static/archives/extend/2015-January/000501.html @@ -0,0 +1,103 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Mon Jan 26 22:54:09 CET 2015 +

+
+ +
On Mon, 2015-01-26 at 11:26 +0100, Loïc Hoguin wrote:
+> You have to change path_info too if your middleware is after the router.
+> 
+I have added that.  My cowboy:start_http parameters include this:
+    {middlewares, [cowboy_router, bz_libmap, cowboy_handler]}
+which I think means bz_libmap will get called on *every* request.  This
+seems to work.  Among the dispatch rules is this line:
+    {"/music/[...]", cowboy_static, {dir, "", ""}},
+so any request starting with "/music/ will do a standard file fetch.
+But due to the middlewares setup, bz_libmap will get a chance to
+look at it first.
+
+bz_libmap checks the path to see if it starts with "/music/", and if
+not, it just returns {ok,Req,Env} and lets processing proceed normally.
+This works, and other dispatch rules take care of it, usually fetching
+files from priv_dir.
+
+But if bz_libmap sees "/music/" at the start of the URL it transforms
+the URL into something else, an absolute filename typically of an mp3
+file.  This is what I want cowboy_static to process.  Hopefully, this
+does not run through the dispatch rules again.
+
+bz_libmap computes a new path and a new path_info and sets them with a
+cowboy_req:set call.  I am not sure what path_info should look like at
+this point, because the path is no longer covered by any of the dispatch
+rules.  I do not want it to be, as that would allow a browser to fetch
+any file in the file system, unchecked.
+
+But what happens is any attempts to fetch /music/Anything result in a
+status 400 error.
+
+The other approach I was considering was to make my own handler, based
+on cowboy_static, that does the URL/File transformation internally.  But
+even that might not be right, since it eventually upgrades to
+cowboy_rest and there is more processing after that.  This approach
+seems inelegant.
+
+The actual only call to file:open I found in all of cowboy is in
+cowboy_spdy.
+
+
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000502.html b/_build/static/archives/extend/2015-January/000502.html new file mode 100644 index 00000000..601c9e23 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000502.html @@ -0,0 +1,79 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jan 27 11:13:41 CET 2015 +

+
+ +
On 01/26/2015 10:54 PM, Paul Dickson wrote:
+> On Mon, 2015-01-26 at 11:26 +0100, Loïc Hoguin wrote:
+>> You have to change path_info too if your middleware is after the router.
+>>
+> I have added that.  My cowboy:start_http parameters include this:
+>      {middlewares, [cowboy_router, bz_libmap, cowboy_handler]}
+> which I think means bz_libmap will get called on *every* request.  This
+> seems to work.  Among the dispatch rules is this line:
+>      {"/music/[...]", cowboy_static, {dir, "", ""}},
+
+Is it the actual line? Cause {dir, "", ""} is wrong, the third element 
+must be an etag or mimetype tuple.
+
+Otherwise, I need a more complete error, or code.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000503.html b/_build/static/archives/extend/2015-January/000503.html new file mode 100644 index 00000000..4ed34cd0 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000503.html @@ -0,0 +1,97 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Tue Jan 27 14:07:48 CET 2015 +

+
+ +
On Tue, 2015-01-27 at 11:13 +0100, Loïc Hoguin wrote:
+> On 01/26/2015 10:54 PM, Paul Dickson wrote:
+> > On Mon, 2015-01-26 at 11:26 +0100, Loïc Hoguin wrote:
+> >> You have to change path_info too if your middleware is after the router.
+> >>
+> > I have added that.  My cowboy:start_http parameters include this:
+> >      {middlewares, [cowboy_router, bz_libmap, cowboy_handler]}
+> > which I think means bz_libmap will get called on *every* request.  This
+> > seems to work.  Among the dispatch rules is this line:
+> >      {"/music/[...]", cowboy_static, {dir, "", ""}},
+> 
+> Is it the actual line? Cause {dir, "", ""} is wrong, the third element 
+> must be an etag or mimetype tuple.
+> 
+> Otherwise, I need a more complete error, or code.
+
+I changed the rule line to:
+
+	    {"/music/[...]", cowboy_static, {dir, "", [
+	        {mimetypes, cow_mimetypes, all}]}},
+
+The client I am using is 'mplayer'.  The error message is:
+
+  Server returned 400:Bad Request
+  Failed to parse header.
+  Failed, exiting.
+
+I also included some tracing in my middleware module to print
+out the new path and path_info values it is setting, showing
+the result of the rewrite algorithm.
+
+ Path <<"/music/Library/Folk/Swiss/Alphorn.ogg">>
+ Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>,
+         <<"Alphorn.ogg">>]
+
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000504.html b/_build/static/archives/extend/2015-January/000504.html new file mode 100644 index 00000000..3609d77f --- /dev/null +++ b/_build/static/archives/extend/2015-January/000504.html @@ -0,0 +1,70 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jan 27 14:10:58 CET 2015 +

+
+ +
On 01/27/2015 02:07 PM, Paul Dickson wrote:
+>   Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>,
+>           <<"Alphorn.ogg">>]
+
+Should be from Library onward, and not include the first two elements.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000505.html b/_build/static/archives/extend/2015-January/000505.html new file mode 100644 index 00000000..e842c26d --- /dev/null +++ b/_build/static/archives/extend/2015-January/000505.html @@ -0,0 +1,82 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Tue Jan 27 14:24:30 CET 2015 +

+
+ +
On Tue, 2015-01-27 at 14:10 +0100, Loïc Hoguin wrote:
+
+> On 01/27/2015 02:07 PM, Paul Dickson wrote:
+> >   Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>,
+> >           <<"Alphorn.ogg">>]
+> 
+> Should be from Library onward, and not include the first two elements.
+> 
+
+
+This is perhaps a confusing case, because the incoming URL and the
+transformed URL both start with "/music".  What if that was not the
+case, and the resulting path was, for example,
+
+    /home/me/music/Folk/Swiss/Alphorn.ogg
+
+which does not match anything in the rules at all?  Is that allowed, or
+must the rewritten URL also match a rule?
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150127/1916d612/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000506.html b/_build/static/archives/extend/2015-January/000506.html new file mode 100644 index 00000000..851bc42f --- /dev/null +++ b/_build/static/archives/extend/2015-January/000506.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jan 27 14:29:20 CET 2015 +

+
+ +
On 01/27/2015 02:24 PM, Paul Dickson wrote:
+> On Tue, 2015-01-27 at 14:10 +0100, Loïc Hoguin wrote:
+>> On 01/27/2015 02:07 PM, Paul Dickson wrote:
+>> >   Info [<<"/">>,<<"music">>,<<"Library">>,<<"Folk">>,<<"Swiss">>,
+>> >           <<"Alphorn.ogg">>]
+>>
+>> Should be from Library onward, and not include the first two elements.
+>>
+>
+> This is perhaps a confusing case, because the incoming URL and the
+> transformed URL both start with "/music".  What if that was not the
+> case, and the resulting path was, for example,
+>
+>      /home/me/music/Folk/Swiss/Alphorn.ogg
+>
+> which does not match anything in the rules at all?  Is that allowed, or
+> must the rewritten URL also match a rule?
+
+Middlewares execute in order and only once, so not sure what you're asking.
+
+Again I'd need to see some code to help you as I am quite confused by 
+what you are trying to do and what your issue is.
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000507.html b/_build/static/archives/extend/2015-January/000507.html new file mode 100644 index 00000000..a16a39c2 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000507.html @@ -0,0 +1,100 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Tue Jan 27 14:44:14 CET 2015 +

+
+ +
Ok, here is all the code in bz_libmap.erl
+
+execute(Req, Env) ->
+    Path = cowboy_req:path(Req),
+    Parts = filename:split(Path),
+
+    case cowboy_req:method(Req) of
+      <<"GET">> ->
+         % Check for "/music/" requests
+         rewrite( Parts, Req, Env );
+      _Other ->
+         {ok, Req, Env}
+    end.
+
+rewrite( [<<"/">>, <<"music">>, LibName | UrlParts], Req, Env ) ->
+    % We want URLs of the form "/music/LIBNAME/everythingelse"
+    % Get library definition.  If we do not know that name, then they
+    % are asking for something that does not exist.
+    case bz_db:get_library( LibName ) of
+      [] ->
+         io:format("No such library '~s'~n", [LibName] ),
+         {stop, cowboy_req:reply(404, Req)};
+
+      L when is_record(L,library) ->
+          % Replace the library name with the library base.
+          % This will be the head of an absolute file path.
+          LibBase = L#library.base,
+          NewPath = filename:join([LibBase | UrlParts]),
+          NewInfo = filename:split(NewPath),
+          Req2 = cowboy_req:set( [
+            {path_info,[NewPath]},
+            {path, [NewPath]}], Req),
+          {ok, Req2, Env}
+    end;
+rewrite( _AnythingElse, Req, Env ) ->
+    {ok, Req, Env}.
+
+
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000508.html b/_build/static/archives/extend/2015-January/000508.html new file mode 100644 index 00000000..225df1f8 --- /dev/null +++ b/_build/static/archives/extend/2015-January/000508.html @@ -0,0 +1,69 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Paul Dickson + pdtwonotes at gmail.com +
+ Thu Jan 29 23:23:35 CET 2015 +

+
+ +
The status 400 is coming from cowboy_rest, when it complains that
+handler cowboy_static lacks the functions 'service_available',
+'known_methods', 'uri_too_long', and 'allowed_methods'.  Which indeed
+it does not have.
+
+The only place I mention cowboy_static is in the dispatch rule:
+   {"/music/[...]", cowboy_static, {dir, "", [
+       {mimetypes, cow_mimetypes, all}]}},
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/000509.html b/_build/static/archives/extend/2015-January/000509.html new file mode 100644 index 00000000..8d1ab69b --- /dev/null +++ b/_build/static/archives/extend/2015-January/000509.html @@ -0,0 +1,74 @@ + + + + [99s-extend] Rewriting URLs + + + + + + + + + + +

[99s-extend] Rewriting URLs

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Jan 29 23:24:59 CET 2015 +

+
+ +
They are optional callbacks, so I doubt that's it.
+
+On 01/29/2015 11:23 PM, Paul Dickson wrote:
+> The status 400 is coming from cowboy_rest, when it complains that
+> handler cowboy_static lacks the functions 'service_available',
+> 'known_methods', 'uri_too_long', and 'allowed_methods'.  Which indeed
+> it does not have.
+>
+> The only place I mention cowboy_static is in the dispatch rule:
+>     {"/music/[...]", cowboy_static, {dir, "", [
+>         {mimetypes, cow_mimetypes, all}]}},
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-January/author.html b/_build/static/archives/extend/2015-January/author.html new file mode 100644 index 00000000..eb2c5a79 --- /dev/null +++ b/_build/static/archives/extend/2015-January/author.html @@ -0,0 +1,177 @@ + + + + The Extend January 2015 Archive by author + + + + + +

January 2015 Archives by author

+ +

Starting: Sat Jan 10 14:55:58 CET 2015
+ Ending: Thu Jan 29 23:24:59 CET 2015
+ Messages: 26

+

+

+ Last message date: + Thu Jan 29 23:24:59 CET 2015
+ Archived on: Thu Jan 29 23:24:56 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-January/date.html b/_build/static/archives/extend/2015-January/date.html new file mode 100644 index 00000000..5cc9dfee --- /dev/null +++ b/_build/static/archives/extend/2015-January/date.html @@ -0,0 +1,177 @@ + + + + The Extend January 2015 Archive by date + + + + + +

January 2015 Archives by date

+ +

Starting: Sat Jan 10 14:55:58 CET 2015
+ Ending: Thu Jan 29 23:24:59 CET 2015
+ Messages: 26

+

+

+ Last message date: + Thu Jan 29 23:24:59 CET 2015
+ Archived on: Thu Jan 29 23:24:56 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-January/index.html b/_build/static/archives/extend/2015-January/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-January/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-January/subject.html b/_build/static/archives/extend/2015-January/subject.html new file mode 100644 index 00000000..f8a9e2f0 --- /dev/null +++ b/_build/static/archives/extend/2015-January/subject.html @@ -0,0 +1,177 @@ + + + + The Extend January 2015 Archive by subject + + + + + +

January 2015 Archives by subject

+ +

Starting: Sat Jan 10 14:55:58 CET 2015
+ Ending: Thu Jan 29 23:24:59 CET 2015
+ Messages: 26

+

+

+ Last message date: + Thu Jan 29 23:24:59 CET 2015
+ Archived on: Thu Jan 29 23:24:56 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-January/thread.html b/_build/static/archives/extend/2015-January/thread.html new file mode 100644 index 00000000..2cfb9866 --- /dev/null +++ b/_build/static/archives/extend/2015-January/thread.html @@ -0,0 +1,227 @@ + + + + The Extend January 2015 Archive by thread + + + + + +

January 2015 Archives by thread

+ +

Starting: Sat Jan 10 14:55:58 CET 2015
+ Ending: Thu Jan 29 23:24:59 CET 2015
+ Messages: 26

+

+

+ Last message date: + Thu Jan 29 23:24:59 CET 2015
+ Archived on: Thu Jan 29 23:24:56 CET 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-July.txt b/_build/static/archives/extend/2015-July.txt new file mode 100644 index 00000000..ac86d308 --- /dev/null +++ b/_build/static/archives/extend/2015-July.txt @@ -0,0 +1,85 @@ +From ethrbh at gmail.com Mon Jul 13 12:47:54 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Mon, 13 Jul 2015 12:47:54 +0200 +Subject: [99s-extend] help to combine websocket with basic authentication +Message-ID: + +hello, + +Sorry that I turned to the list again, but I would like to get some help +from you. I have a websocket based application, based on the +cowboy/examples/websocket. It is working well. Now I would like to add a +basic authentication, and I saw, there is an example how to do this. I +checked the cowboy/examples/rest_basic_auth example. +So I tried "add" the aut. example into my websocket app by doing the +following steps: + - add new module for handle the authentication + do_basic_auth.erl + - update cowboy_router:compile function call when star application with +{"/", do_basic_auth, []} + +Once the compilation done, I can start the app and I get the "basic auth" +window in the browser when connecting to localhost:8080, but the "ordinary" +index.html does not appears when I set the correct auth data (user/pwd). I +am pretty sure that I made something wrong, I do not see what I did wrong, +thus I kindly ask you, please try help me. + +The project what I am working on can be seen in the github: + https://github.com/ethrbh/websocket_2 + +thanks fro your help, +/Robi +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From e at bestmx.net Mon Jul 13 13:01:53 2015 +From: e at bestmx.net (e at bestmx.net) +Date: Mon, 13 Jul 2015 13:01:53 +0200 +Subject: [99s-extend] help to combine websocket with basic authentication +In-Reply-To: +References: +Message-ID: <55A39AA1.2080801@bestmx.net> + +> Now I would like to add a +> basic authentication, and I saw, there is an example how to do this. I +> checked the cowboy/examples/rest_basic_auth example. + +may i ask? +why do you want "basic" +while using WS, which keeps state implicitly. + +"basic" is a CRUTCH for stateless environments, +but you have cowboy that naturally passes the "State" variable trough +handlers. + +also, do you remember that "basic" gives you no option to logout? + + +> So I tried "add" the aut. example into my websocket app by doing the +> following steps: +> - add new module for handle the authentication +> do_basic_auth.erl +> - update cowboy_router:compile function call when star application with +> {"/", do_basic_auth, []} +> +> Once the compilation done, I can start the app and I get the "basic auth" +> window in the browser when connecting to localhost:8080, but the "ordinary" +> index.html does not appears when I set the correct auth data (user/pwd). I +> am pretty sure that I made something wrong, I do not see what I did wrong, +> thus I kindly ask you, please try help me. +> +> The project what I am working on can be seen in the github: +> https://github.com/ethrbh/websocket_2 +> +> thanks fro your help, +> /Robi +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + diff --git a/_build/static/archives/extend/2015-July/000545.html b/_build/static/archives/extend/2015-July/000545.html new file mode 100644 index 00000000..06f48e7a --- /dev/null +++ b/_build/static/archives/extend/2015-July/000545.html @@ -0,0 +1,87 @@ + + + + [99s-extend] help to combine websocket with basic authentication + + + + + + + + + + +

[99s-extend] help to combine websocket with basic authentication

+ Robert Balogh + ethrbh at gmail.com +
+ Mon Jul 13 12:47:54 CEST 2015 +

+
+ +
hello,
+
+Sorry that I turned to the list again, but I would like to get some help
+from you. I have a websocket based application, based on the
+cowboy/examples/websocket. It is working well. Now I would like to add a
+basic authentication, and I saw, there is an example how to do this. I
+checked the cowboy/examples/rest_basic_auth example.
+So I tried "add" the aut. example into my websocket app by doing the
+following steps:
+ - add new module for handle the authentication
+   do_basic_auth.erl
+ - update cowboy_router:compile function call when star application with
+{"/", do_basic_auth, []}
+
+Once the compilation done, I can start the app and I get the "basic auth"
+window in the browser when connecting to localhost:8080, but the "ordinary"
+index.html does not appears when I set the correct auth data (user/pwd). I
+am pretty sure that I made something wrong, I do not see what I did wrong,
+thus I kindly ask you, please try help me.
+
+The project what I am working on can be seen in the github:
+   https://github.com/ethrbh/websocket_2
+
+thanks fro your help,
+/Robi
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150713/eb33ab46/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-July/000546.html b/_build/static/archives/extend/2015-July/000546.html new file mode 100644 index 00000000..106c36b5 --- /dev/null +++ b/_build/static/archives/extend/2015-July/000546.html @@ -0,0 +1,99 @@ + + + + [99s-extend] help to combine websocket with basic authentication + + + + + + + + + + +

[99s-extend] help to combine websocket with basic authentication

+ e at bestmx.net + e at bestmx.net +
+ Mon Jul 13 13:01:53 CEST 2015 +

+
+ +
> Now I would like to add a
+> basic authentication, and I saw, there is an example how to do this. I
+> checked the cowboy/examples/rest_basic_auth example.
+
+may i ask?
+why do you want "basic"
+while using WS, which keeps state implicitly.
+
+"basic" is a CRUTCH for stateless environments,
+but you have cowboy that naturally passes the "State" variable trough 
+handlers.
+
+also, do you remember that "basic" gives you no option to logout?
+
+
+> So I tried "add" the aut. example into my websocket app by doing the
+> following steps:
+>   - add new module for handle the authentication
+>     do_basic_auth.erl
+>   - update cowboy_router:compile function call when star application with
+> {"/", do_basic_auth, []}
+>
+> Once the compilation done, I can start the app and I get the "basic auth"
+> window in the browser when connecting to localhost:8080, but the "ordinary"
+> index.html does not appears when I set the correct auth data (user/pwd). I
+> am pretty sure that I made something wrong, I do not see what I did wrong,
+> thus I kindly ask you, please try help me.
+>
+> The project what I am working on can be seen in the github:
+>     https://github.com/ethrbh/websocket_2
+>
+> thanks fro your help,
+> /Robi
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-July/author.html b/_build/static/archives/extend/2015-July/author.html new file mode 100644 index 00000000..ba3869b1 --- /dev/null +++ b/_build/static/archives/extend/2015-July/author.html @@ -0,0 +1,57 @@ + + + + The Extend July 2015 Archive by author + + + + + +

July 2015 Archives by author

+ +

Starting: Mon Jul 13 12:47:54 CEST 2015
+ Ending: Mon Jul 13 13:01:53 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Mon Jul 13 13:01:53 CEST 2015
+ Archived on: Mon Jul 13 13:03:40 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-July/date.html b/_build/static/archives/extend/2015-July/date.html new file mode 100644 index 00000000..fbbdf860 --- /dev/null +++ b/_build/static/archives/extend/2015-July/date.html @@ -0,0 +1,57 @@ + + + + The Extend July 2015 Archive by date + + + + + +

July 2015 Archives by date

+ +

Starting: Mon Jul 13 12:47:54 CEST 2015
+ Ending: Mon Jul 13 13:01:53 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Mon Jul 13 13:01:53 CEST 2015
+ Archived on: Mon Jul 13 13:03:40 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-July/index.html b/_build/static/archives/extend/2015-July/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-July/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-July/subject.html b/_build/static/archives/extend/2015-July/subject.html new file mode 100644 index 00000000..957b9917 --- /dev/null +++ b/_build/static/archives/extend/2015-July/subject.html @@ -0,0 +1,57 @@ + + + + The Extend July 2015 Archive by subject + + + + + +

July 2015 Archives by subject

+ +

Starting: Mon Jul 13 12:47:54 CEST 2015
+ Ending: Mon Jul 13 13:01:53 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Mon Jul 13 13:01:53 CEST 2015
+ Archived on: Mon Jul 13 13:03:40 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-July/thread.html b/_build/static/archives/extend/2015-July/thread.html new file mode 100644 index 00000000..61143a3f --- /dev/null +++ b/_build/static/archives/extend/2015-July/thread.html @@ -0,0 +1,61 @@ + + + + The Extend July 2015 Archive by thread + + + + + +

July 2015 Archives by thread

+ +

Starting: Mon Jul 13 12:47:54 CEST 2015
+ Ending: Mon Jul 13 13:01:53 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Mon Jul 13 13:01:53 CEST 2015
+ Archived on: Mon Jul 13 13:03:40 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-June.txt b/_build/static/archives/extend/2015-June.txt new file mode 100644 index 00000000..cb177603 --- /dev/null +++ b/_build/static/archives/extend/2015-June.txt @@ -0,0 +1,2012 @@ +From essen at ninenines.eu Fri Jun 19 15:47:14 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Fri, 19 Jun 2015 15:47:14 +0200 +Subject: [99s-extend] [ANN] The Erlanger Playbook early release +Message-ID: <55841D62.1070400@ninenines.eu> + +Hello, + +I hope it's OK for me to announce on erlang-questions: The Erlanger +Playbook, a book about software development using Erlang, has been +*early* released! + +The book is meant to be the missing developer manual. It covers all +steps from the start of a project to its release including writing code, +documentation and tests. + +There are books for learning Erlang, for running Erlang in production, +but not much for modern Erlang development. This is where The Erlanger +Playbook comes in. + +This is an early release. An update will be sent to everyone about every +month or so. I plan to cover anything that relates to the development of +Erlang software, ie the "dev" in "devops". Many tools and techniques +will be covered in future updates. + +We will do a print book if there is enough interest once the book gets +finished, but we're a few months off for now. :-) + +You can get more information here: + + http://ninenines.eu/articles/erlanger-playbook/ + +Thanks for your interest! + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From ethrbh at gmail.com Tue Jun 23 10:28:16 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Tue, 23 Jun 2015 10:28:16 +0200 +Subject: [99s-extend] Help to use frameset in index.html +Message-ID: + +hello, + +First of all I would say I am a beginner in Cowboy web server, so probably +I made something wrong, that is why I got the "fault", what I got. + +I would like to build up web page, where the client can communicate to +server, and server can do the same to client, if client does not send +anything to server too. The Cowboy has the websocket example, what does +what I would like to do. + +There is only one thing is missing what I would like to have. This is the +"frameset". My idea is to build the index.html using framsets. I made this +changes, and I build up the html files for the frames, and of course I set +these in the index.html. + +Here is how the index.html looks like + + + + Welcome to Websocket example 2 + + + + + + + + + + <body> + + </body> + + + + + +This is how the priv folder looks like +----------------------------------------------------------- + ls priv/ + frame_left.html frame_right.html frame_top.html index.html static + +This is how I changed the websocket_2_app:start/2 function +----------------------------------------------------------- + Dispatch = cowboy_router:compile([ + {'_', [ + + {"/", cowboy_static, {priv_file, websocket_2, "index.html"}}, + {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}}, + + {"/websocket_2", ws_handler_2, []}, + {"/static/[...]", cowboy_static, {priv_dir, websocket_2, +"static"}} + ]} + ]), + +After compile and make release package of the app, I can reach the +webserver on the port 8080, but some connection does not set up correctly. +The following texts are present in the browser + DISCONNECTED + + ERROR: undefined + + Connecting to: ws://localhost:8080/websocket_2 + +I made a dbg trace on all cowboy modules, to start some kind of +troubleshooting. In the "tons" of printout I can see this one. So in the +bottom of this, there is an {error,enoent}. It comes when tries connect to +the socket. But unfortunatelly I do not have idea what may cause this :-( + +The part of trace +----------------------------------------------------------- + (<0.177.0>) call +cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', + {{127,0,0,1},33241}, + <<"localhost">>,undefined,8080,<<"/websocket_2">>, + [<<"websocket_2">>], + <<>>,undefined,[], + [{<<"host">>,<<"localhost:8080">>}, + {<<"connection">>,<<"Upgrade">>}, + {<<"pragma">>,<<"no-cache">>}, + {<<"cache-control">>,<<"no-cache">>}, + {<<"upgrade">>,<<"websocket">>}, + {<<"origin">>,<<"http://localhost:8080">>}, + {<<"sec-websocket-version">>,<<"13">>}, + {<<"user-agent">>, + <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, +like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, + {<<"accept-encoding">>,<<"gzip, deflate, sdch">>}, + {<<"accept-language">>,<<"en-US,en;q=0.8">>}, + {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, + {<<"sec-websocket-extensions">>, + <<"permessage-deflate; client_max_window_bits">>}], + [{<<"connection">>,[<<"upgrade">>]}], + +undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, + {handler_opts,{priv_dir,websocket_2,[]}}, + {listener,http}, + {dispatch,[{'_',[], + [{[],[],cowboy_static, + {priv_file,websocket_2,"index.html"}}, + + {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, + {[<<"websocket_2">>],[],ws_handler_2,[]}, + {[<<"static">>,'...'], + [],cowboy_static, + {priv_dir,websocket_2,"static"}}]}]}], + <<"GET">>,cowboy_static, + +{<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, + {error,enoent}, + []}, + undefined,[],undefined,[],undefined,[],undefined,false,undefined, + undefined,undefined},#Fun) (Timestamp: +{1435, + +46126, + +935663}) + +I guess, I did something very wrong, but I did not found what is that, thus +I would like to get some help from you. + +Please find my small project in github: +https://github.com/ethrbh/websocket_2 + +thanks for your help, +/Robi +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Jun 23 10:56:02 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 23 Jun 2015 10:56:02 +0200 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: +References: +Message-ID: <55891F22.5050405@ninenines.eu> + +The {error, enoent}, especially there, is probably just because the +browser is trying to fetch the favicon. + +Your issue is that Websocket won't connect, so it has nothing to do with +cowboy_rest. Try tracing cowboy_websocket or enable SASL to have more info. + +On 06/23/2015 10:28 AM, Robert Balogh wrote: +> hello, +> +> First of all I would say I am a beginner in Cowboy web server, so +> probably I made something wrong, that is why I got the "fault", what I got. +> +> I would like to build up web page, where the client can communicate to +> server, and server can do the same to client, if client does not send +> anything to server too. The Cowboy has the websocket example, what does +> what I would like to do. +> +> There is only one thing is missing what I would like to have. This is +> the "frameset". My idea is to build the index.html using framsets. I +> made this changes, and I build up the html files for the frames, and of +> course I set these in the index.html. +> +> Here is how the index.html looks like +> +> +> +> Welcome to Websocket example 2 +> +> +> +> src="frame_top.html"> +> +> src="frame_left.html"> +> +> +> +> <body> +> +> </body> +> +> +> +> +> +> This is how the priv folder looks like +> ----------------------------------------------------------- +> ls priv/ +> frame_left.html frame_right.html frame_top.html index.html static +> +> This is how I changed the websocket_2_app:start/2 function +> ----------------------------------------------------------- +> Dispatch = cowboy_router:compile([ +> {'_', [ +> +> {"/", cowboy_static, {priv_file, websocket_2, "index.html"}}, +> {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}}, +> +> {"/websocket_2", ws_handler_2, []}, +> {"/static/[...]", cowboy_static, {priv_dir, websocket_2, +> "static"}} +> ]} +> ]), +> +> After compile and make release package of the app, I can reach the +> webserver on the port 8080, but some connection does not set up +> correctly. The following texts are present in the browser +> DISCONNECTED +> +> ERROR: undefined +> +> Connecting to: ws://localhost:8080/websocket_2 +> +> I made a dbg trace on all cowboy modules, to start some kind of +> troubleshooting. In the "tons" of printout I can see this one. So in the +> bottom of this, there is an {error,enoent}. It comes when tries connect +> to the socket. But unfortunatelly I do not have idea what may cause this :-( +> +> The part of trace +> ----------------------------------------------------------- +> (<0.177.0>) call +> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +> {{127,0,0,1},33241}, +> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +> [<<"websocket_2">>], +> <<>>,undefined,[], +> [{<<"host">>,<<"localhost:8080">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"upgrade">>,<<"websocket">>}, +> {<<"origin">>,<<"http://localhost:8080">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"user-agent">>, +> <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 +> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +> {<<"accept-encoding">>,<<"gzip, deflate, sdch">>}, +> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +> {<<"sec-websocket-extensions">>, +> <<"permessage-deflate; client_max_window_bits">>}], +> [{<<"connection">>,[<<"upgrade">>]}], +> +> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +> {handler_opts,{priv_dir,websocket_2,[]}}, +> {listener,http}, +> {dispatch,[{'_',[], +> [{[],[],cowboy_static, +> {priv_file,websocket_2,"index.html"}}, +> +> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +> {[<<"websocket_2">>],[],ws_handler_2,[]}, +> {[<<"static">>,'...'], +> [],cowboy_static, +> {priv_dir,websocket_2,"static"}}]}]}], +> <<"GET">>,cowboy_static, +> +> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +> {error,enoent}, +> []}, +> +> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +> undefined,undefined},#Fun) +> (Timestamp: {1435, +> +> 46126, +> +> 935663}) +> +> I guess, I did something very wrong, but I did not found what is that, +> thus I would like to get some help from you. +> +> Please find my small project in github: +> https://github.com/ethrbh/websocket_2 +> +> thanks for your help, +> /Robi +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From grahamrhay at gmail.com Tue Jun 23 11:06:35 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Tue, 23 Jun 2015 10:06:35 +0100 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: <55891F22.5050405@ninenines.eu> +References: + <55891F22.5050405@ninenines.eu> +Message-ID: + +I think the order of your routes is the problem, try putting this line + +last. + +On 23 June 2015 at 09:56, Lo?c Hoguin wrote: + +> The {error, enoent}, especially there, is probably just because the +> browser is trying to fetch the favicon. +> +> Your issue is that Websocket won't connect, so it has nothing to do with +> cowboy_rest. Try tracing cowboy_websocket or enable SASL to have more info. +> +> +> On 06/23/2015 10:28 AM, Robert Balogh wrote: +> +>> hello, +>> +>> First of all I would say I am a beginner in Cowboy web server, so +>> probably I made something wrong, that is why I got the "fault", what I +>> got. +>> +>> I would like to build up web page, where the client can communicate to +>> server, and server can do the same to client, if client does not send +>> anything to server too. The Cowboy has the websocket example, what does +>> what I would like to do. +>> +>> There is only one thing is missing what I would like to have. This is +>> the "frameset". My idea is to build the index.html using framsets. I +>> made this changes, and I build up the html files for the frames, and of +>> course I set these in the index.html. +>> +>> Here is how the index.html looks like +>> +>> +>> +>> Welcome to Websocket example 2 +>> +>> +>> +>> > src="frame_top.html"> +>> +>> > src="frame_left.html"> +>> +>> +>> +>> <body> +>> +>> </body> +>> +>> +>> +>> +>> +>> This is how the priv folder looks like +>> ----------------------------------------------------------- +>> ls priv/ +>> frame_left.html frame_right.html frame_top.html index.html static +>> +>> This is how I changed the websocket_2_app:start/2 function +>> ----------------------------------------------------------- +>> Dispatch = cowboy_router:compile([ +>> {'_', [ +>> +>> {"/", cowboy_static, {priv_file, websocket_2, "index.html"}}, +>> {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}}, +>> +>> {"/websocket_2", ws_handler_2, []}, +>> {"/static/[...]", cowboy_static, {priv_dir, websocket_2, +>> "static"}} +>> ]} +>> ]), +>> +>> After compile and make release package of the app, I can reach the +>> webserver on the port 8080, but some connection does not set up +>> correctly. The following texts are present in the browser +>> DISCONNECTED +>> +>> ERROR: undefined +>> +>> Connecting to: ws://localhost:8080/websocket_2 +>> +>> I made a dbg trace on all cowboy modules, to start some kind of +>> troubleshooting. In the "tons" of printout I can see this one. So in the +>> bottom of this, there is an {error,enoent}. It comes when tries connect +>> to the socket. But unfortunatelly I do not have idea what may cause this +>> :-( +>> +>> The part of trace +>> ----------------------------------------------------------- +>> (<0.177.0>) call +>> +>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +>> {{127,0,0,1},33241}, +>> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +>> [<<"websocket_2">>], +>> <<>>,undefined,[], +>> [{<<"host">>,<<"localhost:8080">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"upgrade">>,<<"websocket">>}, +>> {<<"origin">>,<<"http://localhost:8080">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"user-agent">>, +>> <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 +>> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +>> {<<"accept-encoding">>,<<"gzip, deflate, sdch">>}, +>> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +>> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"permessage-deflate; client_max_window_bits">>}], +>> [{<<"connection">>,[<<"upgrade">>]}], +>> +>> +>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +>> {handler_opts,{priv_dir,websocket_2,[]}}, +>> {listener,http}, +>> {dispatch,[{'_',[], +>> [{[],[],cowboy_static, +>> {priv_file,websocket_2,"index.html"}}, +>> +>> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +>> {[<<"websocket_2">>],[],ws_handler_2,[]}, +>> {[<<"static">>,'...'], +>> [],cowboy_static, +>> {priv_dir,websocket_2,"static"}}]}]}], +>> <<"GET">>,cowboy_static, +>> +>> +>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +>> {error,enoent}, +>> []}, +>> +>> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +>> undefined,undefined},#Fun) +>> (Timestamp: {1435, +>> +>> 46126, +>> +>> 935663}) +>> +>> I guess, I did something very wrong, but I did not found what is that, +>> thus I would like to get some help from you. +>> +>> Please find my small project in github: +>> https://github.com/ethrbh/websocket_2 +>> +>> thanks for your help, +>> /Robi +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Jun 23 11:09:27 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 23 Jun 2015 11:09:27 +0200 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: +References: <55891F22.5050405@ninenines.eu> + +Message-ID: <55892247.5010302@ninenines.eu> + +Oh nice catch ahah. We should probably warn when something like this +happens. + +On 06/23/2015 11:06 AM, Graham Hay wrote: +> I think the order of your routes is the problem, try putting this line +> +> last. +> +> On 23 June 2015 at 09:56, Lo?c Hoguin > wrote: +> +> The {error, enoent}, especially there, is probably just because the +> browser is trying to fetch the favicon. +> +> Your issue is that Websocket won't connect, so it has nothing to do +> with cowboy_rest. Try tracing cowboy_websocket or enable SASL to +> have more info. +> +> +> On 06/23/2015 10:28 AM, Robert Balogh wrote: +> +> hello, +> +> First of all I would say I am a beginner in Cowboy web server, so +> probably I made something wrong, that is why I got the "fault", +> what I got. +> +> I would like to build up web page, where the client can +> communicate to +> server, and server can do the same to client, if client does not +> send +> anything to server too. The Cowboy has the websocket example, +> what does +> what I would like to do. +> +> There is only one thing is missing what I would like to have. +> This is +> the "frameset". My idea is to build the index.html using framsets. I +> made this changes, and I build up the html files for the frames, +> and of +> course I set these in the index.html. +> +> Here is how the index.html looks like +> +> +> +> Welcome to Websocket example 2 +> +> +> +> src="frame_top.html"> +> +> src="frame_left.html"> +> +> +> +> <body> +> +> </body> +> +> +> +> +> +> This is how the priv folder looks like +> ----------------------------------------------------------- +> ls priv/ +> frame_left.html frame_right.html frame_top.html +> index.html static +> +> This is how I changed the websocket_2_app:start/2 function +> ----------------------------------------------------------- +> Dispatch = cowboy_router:compile([ +> {'_', [ +> +> {"/", cowboy_static, {priv_file, websocket_2, +> "index.html"}}, +> {"/[...]", cowboy_static, {priv_dir, websocket_2, +> ""}}, +> +> {"/websocket_2", ws_handler_2, []}, +> {"/static/[...]", cowboy_static, {priv_dir, +> websocket_2, +> "static"}} +> ]} +> ]), +> +> After compile and make release package of the app, I can reach the +> webserver on the port 8080, but some connection does not set up +> correctly. The following texts are present in the browser +> DISCONNECTED +> +> ERROR: undefined +> +> Connecting to: ws://localhost:8080/websocket_2 +> +> I made a dbg trace on all cowboy modules, to start some kind of +> troubleshooting. In the "tons" of printout I can see this one. +> So in the +> bottom of this, there is an {error,enoent}. It comes when tries +> connect +> to the socket. But unfortunatelly I do not have idea what may +> cause this :-( +> +> The part of trace +> ----------------------------------------------------------- +> (<0.177.0>) call +> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +> {{127,0,0,1},33241}, +> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +> [<<"websocket_2">>], +> <<>>,undefined,[], +> [{<<"host">>,<<"localhost:8080">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"upgrade">>,<<"websocket">>}, +> {<<"origin">>,<<"http://localhost:8080">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"user-agent">>, +> <<"Mozilla/5.0 (X11; Linux i686) +> AppleWebKit/537.36 +> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +> {<<"accept-encoding">>,<<"gzip, deflate, sdch">>}, +> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +> +> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +> {<<"sec-websocket-extensions">>, +> <<"permessage-deflate; +> client_max_window_bits">>}], +> [{<<"connection">>,[<<"upgrade">>]}], +> +> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +> {handler_opts,{priv_dir,websocket_2,[]}}, +> {listener,http}, +> {dispatch,[{'_',[], +> [{[],[],cowboy_static, +> +> {priv_file,websocket_2,"index.html"}}, +> +> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +> +> {[<<"websocket_2">>],[],ws_handler_2,[]}, +> {[<<"static">>,'...'], +> [],cowboy_static, +> +> {priv_dir,websocket_2,"static"}}]}]}], +> <<"GET">>,cowboy_static, +> +> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +> {error,enoent}, +> []}, +> +> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +> undefined,undefined},#Fun) +> (Timestamp: {1435, +> +> 46126, +> +> 935663}) +> +> I guess, I did something very wrong, but I did not found what is +> that, +> thus I would like to get some help from you. +> +> Please find my small project in github: +> https://github.com/ethrbh/websocket_2 +> +> thanks for your help, +> /Robi +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From ethrbh at gmail.com Tue Jun 23 11:11:42 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Tue, 23 Jun 2015 11:11:42 +0200 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: <55892247.5010302@ninenines.eu> +References: + <55891F22.5050405@ninenines.eu> + + <55892247.5010302@ninenines.eu> +Message-ID: + +hello, + +Thanks for all. The solution is to put the line at last + {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}} + +Now It works as I expect. + +thanks for your help again. + +br, +/Robi + + +2015-06-23 11:09 GMT+02:00 Lo?c Hoguin : + +> Oh nice catch ahah. We should probably warn when something like this +> happens. +> +> On 06/23/2015 11:06 AM, Graham Hay wrote: +> +>> I think the order of your routes is the problem, try putting this line +>> < +>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17 +>> > +>> last. +>> +>> On 23 June 2015 at 09:56, Lo?c Hoguin > > wrote: +>> +>> The {error, enoent}, especially there, is probably just because the +>> browser is trying to fetch the favicon. +>> +>> Your issue is that Websocket won't connect, so it has nothing to do +>> with cowboy_rest. Try tracing cowboy_websocket or enable SASL to +>> have more info. +>> +>> +>> On 06/23/2015 10:28 AM, Robert Balogh wrote: +>> +>> hello, +>> +>> First of all I would say I am a beginner in Cowboy web server, so +>> probably I made something wrong, that is why I got the "fault", +>> what I got. +>> +>> I would like to build up web page, where the client can +>> communicate to +>> server, and server can do the same to client, if client does not +>> send +>> anything to server too. The Cowboy has the websocket example, +>> what does +>> what I would like to do. +>> +>> There is only one thing is missing what I would like to have. +>> This is +>> the "frameset". My idea is to build the index.html using +>> framsets. I +>> made this changes, and I build up the html files for the frames, +>> and of +>> course I set these in the index.html. +>> +>> Here is how the index.html looks like +>> +>> +>> +>> Welcome to Websocket example 2 +>> +>> +>> +>> > scrolling="no" +>> src="frame_top.html"> +>> +>> > src="frame_left.html"> +>> +>> +>> +>> <body> +>> +>> </body> +>> +>> +>> +>> +>> +>> This is how the priv folder looks like +>> ----------------------------------------------------------- +>> ls priv/ +>> frame_left.html frame_right.html frame_top.html +>> index.html static +>> +>> This is how I changed the websocket_2_app:start/2 function +>> ----------------------------------------------------------- +>> Dispatch = cowboy_router:compile([ +>> {'_', [ +>> +>> {"/", cowboy_static, {priv_file, websocket_2, +>> "index.html"}}, +>> {"/[...]", cowboy_static, {priv_dir, websocket_2, +>> ""}}, +>> +>> {"/websocket_2", ws_handler_2, []}, +>> {"/static/[...]", cowboy_static, {priv_dir, +>> websocket_2, +>> "static"}} +>> ]} +>> ]), +>> +>> After compile and make release package of the app, I can reach the +>> webserver on the port 8080, but some connection does not set up +>> correctly. The following texts are present in the browser +>> DISCONNECTED +>> +>> ERROR: undefined +>> +>> Connecting to: ws://localhost:8080/websocket_2 +>> +>> I made a dbg trace on all cowboy modules, to start some kind of +>> troubleshooting. In the "tons" of printout I can see this one. +>> So in the +>> bottom of this, there is an {error,enoent}. It comes when tries +>> connect +>> to the socket. But unfortunatelly I do not have idea what may +>> cause this :-( +>> +>> The part of trace +>> ----------------------------------------------------------- +>> (<0.177.0>) call +>> +>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +>> {{127,0,0,1},33241}, +>> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +>> [<<"websocket_2">>], +>> <<>>,undefined,[], +>> [{<<"host">>,<<"localhost:8080">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"upgrade">>,<<"websocket">>}, +>> {<<"origin">>,<<"http://localhost:8080">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"user-agent">>, +>> <<"Mozilla/5.0 (X11; Linux i686) +>> AppleWebKit/537.36 +>> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +>> {<<"accept-encoding">>,<<"gzip, deflate, +>> sdch">>}, +>> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +>> +>> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"permessage-deflate; +>> client_max_window_bits">>}], +>> [{<<"connection">>,[<<"upgrade">>]}], +>> +>> +>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +>> {handler_opts,{priv_dir,websocket_2,[]}}, +>> {listener,http}, +>> {dispatch,[{'_',[], +>> [{[],[],cowboy_static, +>> +>> {priv_file,websocket_2,"index.html"}}, +>> +>> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +>> +>> {[<<"websocket_2">>],[],ws_handler_2,[]}, +>> {[<<"static">>,'...'], +>> [],cowboy_static, +>> +>> {priv_dir,websocket_2,"static"}}]}]}], +>> <<"GET">>,cowboy_static, +>> +>> +>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +>> {error,enoent}, +>> []}, +>> +>> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +>> undefined,undefined},#Fun) +>> (Timestamp: {1435, +>> +>> 46126, +>> +>> 935663}) +>> +>> I guess, I did something very wrong, but I did not found what is +>> that, +>> thus I would like to get some help from you. +>> +>> Please find my small project in github: +>> https://github.com/ethrbh/websocket_2 +>> +>> thanks for your help, +>> /Robi +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From grahamrhay at gmail.com Tue Jun 23 11:11:50 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Tue, 23 Jun 2015 10:11:50 +0100 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: <55892247.5010302@ninenines.eu> +References: + <55891F22.5050405@ninenines.eu> + + <55892247.5010302@ninenines.eu> +Message-ID: + +It's bitten me a few times :( + +On 23 June 2015 at 10:09, Lo?c Hoguin wrote: + +> Oh nice catch ahah. We should probably warn when something like this +> happens. +> +> On 06/23/2015 11:06 AM, Graham Hay wrote: +> +>> I think the order of your routes is the problem, try putting this line +>> < +>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17 +>> > +>> last. +>> +>> On 23 June 2015 at 09:56, Lo?c Hoguin > > wrote: +>> +>> The {error, enoent}, especially there, is probably just because the +>> browser is trying to fetch the favicon. +>> +>> Your issue is that Websocket won't connect, so it has nothing to do +>> with cowboy_rest. Try tracing cowboy_websocket or enable SASL to +>> have more info. +>> +>> +>> On 06/23/2015 10:28 AM, Robert Balogh wrote: +>> +>> hello, +>> +>> First of all I would say I am a beginner in Cowboy web server, so +>> probably I made something wrong, that is why I got the "fault", +>> what I got. +>> +>> I would like to build up web page, where the client can +>> communicate to +>> server, and server can do the same to client, if client does not +>> send +>> anything to server too. The Cowboy has the websocket example, +>> what does +>> what I would like to do. +>> +>> There is only one thing is missing what I would like to have. +>> This is +>> the "frameset". My idea is to build the index.html using +>> framsets. I +>> made this changes, and I build up the html files for the frames, +>> and of +>> course I set these in the index.html. +>> +>> Here is how the index.html looks like +>> +>> +>> +>> Welcome to Websocket example 2 +>> +>> +>> +>> > scrolling="no" +>> src="frame_top.html"> +>> +>> > src="frame_left.html"> +>> +>> +>> +>> <body> +>> +>> </body> +>> +>> +>> +>> +>> +>> This is how the priv folder looks like +>> ----------------------------------------------------------- +>> ls priv/ +>> frame_left.html frame_right.html frame_top.html +>> index.html static +>> +>> This is how I changed the websocket_2_app:start/2 function +>> ----------------------------------------------------------- +>> Dispatch = cowboy_router:compile([ +>> {'_', [ +>> +>> {"/", cowboy_static, {priv_file, websocket_2, +>> "index.html"}}, +>> {"/[...]", cowboy_static, {priv_dir, websocket_2, +>> ""}}, +>> +>> {"/websocket_2", ws_handler_2, []}, +>> {"/static/[...]", cowboy_static, {priv_dir, +>> websocket_2, +>> "static"}} +>> ]} +>> ]), +>> +>> After compile and make release package of the app, I can reach the +>> webserver on the port 8080, but some connection does not set up +>> correctly. The following texts are present in the browser +>> DISCONNECTED +>> +>> ERROR: undefined +>> +>> Connecting to: ws://localhost:8080/websocket_2 +>> +>> I made a dbg trace on all cowboy modules, to start some kind of +>> troubleshooting. In the "tons" of printout I can see this one. +>> So in the +>> bottom of this, there is an {error,enoent}. It comes when tries +>> connect +>> to the socket. But unfortunatelly I do not have idea what may +>> cause this :-( +>> +>> The part of trace +>> ----------------------------------------------------------- +>> (<0.177.0>) call +>> +>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +>> {{127,0,0,1},33241}, +>> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +>> [<<"websocket_2">>], +>> <<>>,undefined,[], +>> [{<<"host">>,<<"localhost:8080">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"upgrade">>,<<"websocket">>}, +>> {<<"origin">>,<<"http://localhost:8080">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"user-agent">>, +>> <<"Mozilla/5.0 (X11; Linux i686) +>> AppleWebKit/537.36 +>> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +>> {<<"accept-encoding">>,<<"gzip, deflate, +>> sdch">>}, +>> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +>> +>> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"permessage-deflate; +>> client_max_window_bits">>}], +>> [{<<"connection">>,[<<"upgrade">>]}], +>> +>> +>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +>> {handler_opts,{priv_dir,websocket_2,[]}}, +>> {listener,http}, +>> {dispatch,[{'_',[], +>> [{[],[],cowboy_static, +>> +>> {priv_file,websocket_2,"index.html"}}, +>> +>> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +>> +>> {[<<"websocket_2">>],[],ws_handler_2,[]}, +>> {[<<"static">>,'...'], +>> [],cowboy_static, +>> +>> {priv_dir,websocket_2,"static"}}]}]}], +>> <<"GET">>,cowboy_static, +>> +>> +>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +>> {error,enoent}, +>> []}, +>> +>> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +>> undefined,undefined},#Fun) +>> (Timestamp: {1435, +>> +>> 46126, +>> +>> 935663}) +>> +>> I guess, I did something very wrong, but I did not found what is +>> that, +>> thus I would like to get some help from you. +>> +>> Please find my small project in github: +>> https://github.com/ethrbh/websocket_2 +>> +>> thanks for your help, +>> /Robi +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Tue Jun 23 11:12:56 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Tue, 23 Jun 2015 11:12:56 +0200 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: +References: <55891F22.5050405@ninenines.eu> <55892247.5010302@ninenines.eu> + +Message-ID: <55892318.2080507@ninenines.eu> + +I've opened a ticket to remember so something will be done eventually. +Thanks for helping! + +On 06/23/2015 11:11 AM, Graham Hay wrote: +> It's bitten me a few times :( +> +> On 23 June 2015 at 10:09, Lo?c Hoguin > wrote: +> +> Oh nice catch ahah. We should probably warn when something like this +> happens. +> +> On 06/23/2015 11:06 AM, Graham Hay wrote: +> +> I think the order of your routes is the problem, try putting +> this line +> +> last. +> +> On 23 June 2015 at 09:56, Lo?c Hoguin +> >> wrote: +> +> The {error, enoent}, especially there, is probably just +> because the +> browser is trying to fetch the favicon. +> +> Your issue is that Websocket won't connect, so it has +> nothing to do +> with cowboy_rest. Try tracing cowboy_websocket or enable +> SASL to +> have more info. +> +> +> On 06/23/2015 10:28 AM, Robert Balogh wrote: +> +> hello, +> +> First of all I would say I am a beginner in Cowboy web +> server, so +> probably I made something wrong, that is why I got the +> "fault", +> what I got. +> +> I would like to build up web page, where the client can +> communicate to +> server, and server can do the same to client, if client +> does not +> send +> anything to server too. The Cowboy has the websocket +> example, +> what does +> what I would like to do. +> +> There is only one thing is missing what I would like to +> have. +> This is +> the "frameset". My idea is to build the index.html +> using framsets. I +> made this changes, and I build up the html files for +> the frames, +> and of +> course I set these in the index.html. +> +> Here is how the index.html looks like +> +> +> +> Welcome to Websocket example 2 +> +> +> +> scrolling="no" +> src="frame_top.html"> +> +> src="frame_left.html"> +> src="frame_right.html"> +> +> +> <body> +> +> </body> +> +> +> +> +> +> This is how the priv folder looks like +> ----------------------------------------------------------- +> ls priv/ +> frame_left.html frame_right.html frame_top.html +> index.html static +> +> This is how I changed the websocket_2_app:start/2 function +> ----------------------------------------------------------- +> Dispatch = cowboy_router:compile([ +> {'_', [ +> +> {"/", cowboy_static, {priv_file, websocket_2, +> "index.html"}}, +> {"/[...]", cowboy_static, {priv_dir, +> websocket_2, +> ""}}, +> +> {"/websocket_2", ws_handler_2, []}, +> {"/static/[...]", cowboy_static, {priv_dir, +> websocket_2, +> "static"}} +> ]} +> ]), +> +> After compile and make release package of the app, I +> can reach the +> webserver on the port 8080, but some connection does +> not set up +> correctly. The following texts are present in the browser +> DISCONNECTED +> +> ERROR: undefined +> +> Connecting to: ws://localhost:8080/websocket_2 +> +> I made a dbg trace on all cowboy modules, to start some +> kind of +> troubleshooting. In the "tons" of printout I can see +> this one. +> So in the +> bottom of this, there is an {error,enoent}. It comes +> when tries +> connect +> to the socket. But unfortunatelly I do not have idea +> what may +> cause this :-( +> +> The part of trace +> ----------------------------------------------------------- +> (<0.177.0>) call +> +> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +> {{127,0,0,1},33241}, +> +> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +> [<<"websocket_2">>], +> <<>>,undefined,[], +> [{<<"host">>,<<"localhost:8080">>}, +> {<<"connection">>,<<"Upgrade">>}, +> {<<"pragma">>,<<"no-cache">>}, +> {<<"cache-control">>,<<"no-cache">>}, +> {<<"upgrade">>,<<"websocket">>}, +> +> {<<"origin">>,<<"http://localhost:8080">>}, +> {<<"sec-websocket-version">>,<<"13">>}, +> {<<"user-agent">>, +> <<"Mozilla/5.0 (X11; Linux i686) +> AppleWebKit/537.36 +> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>}, +> {<<"accept-encoding">>,<<"gzip, +> deflate, sdch">>}, +> +> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +> +> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +> {<<"sec-websocket-extensions">>, +> <<"permessage-deflate; +> client_max_window_bits">>}], +> [{<<"connection">>,[<<"upgrade">>]}], +> +> +> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +> {handler_opts,{priv_dir,websocket_2,[]}}, +> {listener,http}, +> {dispatch,[{'_',[], +> [{[],[],cowboy_static, +> +> {priv_file,websocket_2,"index.html"}}, +> +> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +> +> {[<<"websocket_2">>],[],ws_handler_2,[]}, +> {[<<"static">>,'...'], +> [],cowboy_static, +> +> {priv_dir,websocket_2,"static"}}]}]}], +> <<"GET">>,cowboy_static, +> +> +> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +> {error,enoent}, +> []}, +> +> +> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +> +> undefined,undefined},#Fun) +> (Timestamp: {1435, +> +> 46126, +> +> 935663}) +> +> I guess, I did something very wrong, but I did not +> found what is +> that, +> thus I would like to get some help from you. +> +> Please find my small project in github: +> https://github.com/ethrbh/websocket_2 +> +> thanks for your help, +> /Robi +> +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> > +> https://lists.ninenines.eu/listinfo/extend +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> > +> https://lists.ninenines.eu/listinfo/extend +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From ethrbh at gmail.com Tue Jun 23 11:15:05 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Tue, 23 Jun 2015 11:15:05 +0200 +Subject: [99s-extend] Help to use frameset in index.html +In-Reply-To: <55892318.2080507@ninenines.eu> +References: + <55891F22.5050405@ninenines.eu> + + <55892247.5010302@ninenines.eu> + + <55892318.2080507@ninenines.eu> +Message-ID: + +hello, + +I would like to thanks for both of you the grate support. + +thanks again, +/Robi + +2015-06-23 11:12 GMT+02:00 Lo?c Hoguin : + +> I've opened a ticket to remember so something will be done eventually. +> Thanks for helping! +> +> On 06/23/2015 11:11 AM, Graham Hay wrote: +> +>> It's bitten me a few times :( +>> +>> On 23 June 2015 at 10:09, Lo?c Hoguin > > wrote: +>> +>> Oh nice catch ahah. We should probably warn when something like this +>> happens. +>> +>> On 06/23/2015 11:06 AM, Graham Hay wrote: +>> +>> I think the order of your routes is the problem, try putting +>> this line +>> < +>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17 +>> > +>> last. +>> +>> On 23 June 2015 at 09:56, Lo?c Hoguin > +>> >> wrote: +>> +>> The {error, enoent}, especially there, is probably just +>> because the +>> browser is trying to fetch the favicon. +>> +>> Your issue is that Websocket won't connect, so it has +>> nothing to do +>> with cowboy_rest. Try tracing cowboy_websocket or enable +>> SASL to +>> have more info. +>> +>> +>> On 06/23/2015 10:28 AM, Robert Balogh wrote: +>> +>> hello, +>> +>> First of all I would say I am a beginner in Cowboy web +>> server, so +>> probably I made something wrong, that is why I got the +>> "fault", +>> what I got. +>> +>> I would like to build up web page, where the client can +>> communicate to +>> server, and server can do the same to client, if client +>> does not +>> send +>> anything to server too. The Cowboy has the websocket +>> example, +>> what does +>> what I would like to do. +>> +>> There is only one thing is missing what I would like to +>> have. +>> This is +>> the "frameset". My idea is to build the index.html +>> using framsets. I +>> made this changes, and I build up the html files for +>> the frames, +>> and of +>> course I set these in the index.html. +>> +>> Here is how the index.html looks like +>> +>> +>> +>> Welcome to Websocket example 2 +>> +>> +>> +>> > scrolling="no" +>> src="frame_top.html"> +>> +>> > src="frame_left.html"> +>> > src="frame_right.html"> +>> +>> +>> <body> +>> +>> </body> +>> +>> +>> +>> +>> +>> This is how the priv folder looks like +>> +>> ----------------------------------------------------------- +>> ls priv/ +>> frame_left.html frame_right.html frame_top.html +>> index.html static +>> +>> This is how I changed the websocket_2_app:start/2 +>> function +>> +>> ----------------------------------------------------------- +>> Dispatch = cowboy_router:compile([ +>> {'_', [ +>> +>> {"/", cowboy_static, {priv_file, +>> websocket_2, +>> "index.html"}}, +>> {"/[...]", cowboy_static, {priv_dir, +>> websocket_2, +>> ""}}, +>> +>> {"/websocket_2", ws_handler_2, []}, +>> {"/static/[...]", cowboy_static, {priv_dir, +>> websocket_2, +>> "static"}} +>> ]} +>> ]), +>> +>> After compile and make release package of the app, I +>> can reach the +>> webserver on the port 8080, but some connection does +>> not set up +>> correctly. The following texts are present in the browser +>> DISCONNECTED +>> +>> ERROR: undefined +>> +>> Connecting to: ws://localhost:8080/websocket_2 +>> +>> I made a dbg trace on all cowboy modules, to start some +>> kind of +>> troubleshooting. In the "tons" of printout I can see +>> this one. +>> So in the +>> bottom of this, there is an {error,enoent}. It comes +>> when tries +>> connect +>> to the socket. But unfortunatelly I do not have idea +>> what may +>> cause this :-( +>> +>> The part of trace +>> +>> ----------------------------------------------------------- +>> (<0.177.0>) call +>> +>> +>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1', +>> {{127,0,0,1},33241}, +>> +>> <<"localhost">>,undefined,8080,<<"/websocket_2">>, +>> [<<"websocket_2">>], +>> <<>>,undefined,[], +>> [{<<"host">>,<<"localhost:8080">>}, +>> {<<"connection">>,<<"Upgrade">>}, +>> {<<"pragma">>,<<"no-cache">>}, +>> {<<"cache-control">>,<<"no-cache">>}, +>> {<<"upgrade">>,<<"websocket">>}, +>> +>> {<<"origin">>,<<"http://localhost:8080">>}, +>> {<<"sec-websocket-version">>,<<"13">>}, +>> {<<"user-agent">>, +>> <<"Mozilla/5.0 (X11; Linux i686) +>> AppleWebKit/537.36 +>> (KHTML, like Gecko) Chrome/40.0.2214.115 +>> Safari/537.36">>}, +>> {<<"accept-encoding">>,<<"gzip, +>> deflate, sdch">>}, +>> +>> {<<"accept-language">>,<<"en-US,en;q=0.8">>}, +>> +>> {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>}, +>> {<<"sec-websocket-extensions">>, +>> <<"permessage-deflate; +>> client_max_window_bits">>}], +>> [{<<"connection">>,[<<"upgrade">>]}], +>> +>> +>> +>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static}, +>> {handler_opts,{priv_dir,websocket_2,[]}}, +>> {listener,http}, +>> {dispatch,[{'_',[], +>> [{[],[],cowboy_static, +>> +>> {priv_file,websocket_2,"index.html"}}, +>> +>> {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}}, +>> +>> {[<<"websocket_2">>],[],ws_handler_2,[]}, +>> {[<<"static">>,'...'], +>> [],cowboy_static, +>> +>> {priv_dir,websocket_2,"static"}}]}]}], +>> <<"GET">>,cowboy_static, +>> +>> +>> +>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>, +>> {error,enoent}, +>> []}, +>> +>> +>> undefined,[],undefined,[],undefined,[],undefined,false,undefined, +>> +>> undefined,undefined},#Fun) +>> (Timestamp: {1435, +>> +>> 46126, +>> +>> 935663}) +>> +>> I guess, I did something very wrong, but I did not +>> found what is +>> that, +>> thus I would like to get some help from you. +>> +>> Please find my small project in github: +>> https://github.com/ethrbh/websocket_2 +>> +>> thanks for your help, +>> /Robi +>> +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> > > +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> > > +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ethrbh at gmail.com Wed Jun 24 11:18:50 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Wed, 24 Jun 2015 11:18:50 +0200 +Subject: [99s-extend] Websocket vs. Request-Response msg pair +Message-ID: + +hello, + +According to you grate support I got from you at yesterday, I could +continue my project, where I use Cowboy webserver and using Websocket. Now +I made an own web page with basic features I need, so the server and client +can communicates to eachother. I like it. + +Now I would like to step forward, and I would like to implement a +Request-Response mechanism. I read few articles in to this topic, and all +of them has mentioned this "feature" is not part of the Websocket standard. +They were suggested to use some sub-protocols for this, but I did not see +any written in Erlang. + +So, I would like to ask you, do I understand right that Cowboy does not +have this feature too? If so, do you have some idea how can I implement a +basic request-response mechanism? Probably one of you guys in this forum +have some idea. + +Btw, the links I read about this topic: + +http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol + http://alabor.me/articles/request-response-oriented-websockets/ + https://www.npmjs.com/package/primus-responder + +thanks for your help, +/Robi +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From grahamrhay at gmail.com Wed Jun 24 12:19:39 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Wed, 24 Jun 2015 11:19:39 +0100 +Subject: [99s-extend] Websocket vs. Request-Response msg pair +In-Reply-To: +References: +Message-ID: + +I think you'd have to roll your own, you just need some way to correlate + +responses +with the originating request. OTP does something similar under the hood +with gen_server calls +. + +It's also possible to treat the ws connection as a messaging channel, and +use something like selective consumer + to +de-multiplex the messages. e.g. you could add a type/channel field to each +message, and only subscribe to those messages. + +Remember that once you move into an async world, there are no guarantees +that you will receive a response! So you need to start thinking about +timeouts etc. + + +On 24 June 2015 at 10:18, Robert Balogh wrote: + +> hello, +> +> According to you grate support I got from you at yesterday, I could +> continue my project, where I use Cowboy webserver and using Websocket. Now +> I made an own web page with basic features I need, so the server and client +> can communicates to eachother. I like it. +> +> Now I would like to step forward, and I would like to implement a +> Request-Response mechanism. I read few articles in to this topic, and all +> of them has mentioned this "feature" is not part of the Websocket standard. +> They were suggested to use some sub-protocols for this, but I did not see +> any written in Erlang. +> +> So, I would like to ask you, do I understand right that Cowboy does not +> have this feature too? If so, do you have some idea how can I implement a +> basic request-response mechanism? Probably one of you guys in this forum +> have some idea. +> +> Btw, the links I read about this topic: +> +> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol +> http://alabor.me/articles/request-response-oriented-websockets/ +> https://www.npmjs.com/package/primus-responder +> +> thanks for your help, +> /Robi +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Jun 24 12:28:21 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Wed, 24 Jun 2015 12:28:21 +0200 +Subject: [99s-extend] Websocket vs. Request-Response msg pair +In-Reply-To: +References: +Message-ID: <558A8645.3010002@ninenines.eu> + +On 06/24/2015 11:18 AM, Robert Balogh wrote: +> Now I would like to step forward, and I would like to implement a +> Request-Response mechanism. I read few articles in to this topic, and +> all of them has mentioned this "feature" is not part of the Websocket +> standard. They were suggested to use some sub-protocols for this, but I +> did not see any written in Erlang. +> +> So, I would like to ask you, do I understand right that Cowboy does not +> have this feature too? If so, do you have some idea how can I implement +> a basic request-response mechanism? Probably one of you guys in this +> forum have some idea. + +Cowboy only comes with the Websocket protocol itself, all sub protocols +and mechanisms you want can then be implemented on top of it. + +I strongly recommend not to do RPC. Just send events to the server and +let the server send events to you. The difference is in the fact that +RPC tracks what requests were sent to tie requests and responses +together, while an event channel does not. You just send what the user +is doing and the server sends you what it wants the client to update or +do. Stay as stateless as possible. + +If you need to manage state to update the interface (locking a form +while waiting for the result, for example), do use timeouts to avoid +locking endlessly. + +Try and experiment, it's not very complicated. :-) + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From BasWegh at gmx.de Wed Jun 24 12:28:09 2015 +From: BasWegh at gmx.de (Bas Wegh) +Date: Wed, 24 Jun 2015 12:28:09 +0200 +Subject: [99s-extend] Websocket vs. Request-Response msg pair +In-Reply-To: +References: +Message-ID: <558A8639.2080901@gmx.de> + +hello Robi, + +you might be interested in erwa: +https://github.com/bwegh/erwa + +Cheers, +Bas + +On 06/24/2015 11:18 AM, Robert Balogh wrote: +> hello, +> +> According to you grate support I got from you at yesterday, I could +> continue my project, where I use Cowboy webserver and using Websocket. +> Now I made an own web page with basic features I need, so the server +> and client can communicates to eachother. I like it. +> +> Now I would like to step forward, and I would like to implement a +> Request-Response mechanism. I read few articles in to this topic, and +> all of them has mentioned this "feature" is not part of the Websocket +> standard. They were suggested to use some sub-protocols for this, but +> I did not see any written in Erlang. +> +> So, I would like to ask you, do I understand right that Cowboy does +> not have this feature too? If so, do you have some idea how can I +> implement a basic request-response mechanism? Probably one of you guys +> in this forum have some idea. +> +> Btw, the links I read about this topic: +> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol +> http://alabor.me/articles/request-response-oriented-websockets/ +> https://www.npmjs.com/package/primus-responder +> +> thanks for your help, +> /Robi +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From ethrbh at gmail.com Wed Jun 24 12:41:16 2015 +From: ethrbh at gmail.com (Robert Balogh) +Date: Wed, 24 Jun 2015 12:41:16 +0200 +Subject: [99s-extend] Websocket vs. Request-Response msg pair +In-Reply-To: <558A8639.2080901@gmx.de> +References: + <558A8639.2080901@gmx.de> +Message-ID: + +hello, + +I would like to thanks the response to all of you. I will try keep all +these in my mind. + +@Bas, thanks for your note about erwa , I +will take a look. + +thanks again, +/Robi + +2015-06-24 12:28 GMT+02:00 Bas Wegh : + +> hello Robi, +> +> you might be interested in erwa: +> https://github.com/bwegh/erwa +> +> Cheers, +> Bas +> +> On 06/24/2015 11:18 AM, Robert Balogh wrote: +> +> hello, +> +> According to you grate support I got from you at yesterday, I could +> continue my project, where I use Cowboy webserver and using Websocket. Now +> I made an own web page with basic features I need, so the server and client +> can communicates to eachother. I like it. +> +> Now I would like to step forward, and I would like to implement a +> Request-Response mechanism. I read few articles in to this topic, and all +> of them has mentioned this "feature" is not part of the Websocket standard. +> They were suggested to use some sub-protocols for this, but I did not see +> any written in Erlang. +> +> So, I would like to ask you, do I understand right that Cowboy does not +> have this feature too? If so, do you have some idea how can I implement a +> basic request-response mechanism? Probably one of you guys in this forum +> have some idea. +> +> Btw, the links I read about this topic: +> +> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol +> http://alabor.me/articles/request-response-oriented-websockets/ +> https://www.npmjs.com/package/primus-responder +> +> thanks for your help, +> /Robi +> +> +> _______________________________________________ +> Extend mailing listExtend at lists.ninenines.euhttps://lists.ninenines.eu/listinfo/extend +> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2015-June/000531.html b/_build/static/archives/extend/2015-June/000531.html new file mode 100644 index 00000000..fc648f2d --- /dev/null +++ b/_build/static/archives/extend/2015-June/000531.html @@ -0,0 +1,92 @@ + + + + [99s-extend] [ANN] The Erlanger Playbook early release + + + + + + + + + + +

[99s-extend] [ANN] The Erlanger Playbook early release

+ Loïc Hoguin + essen at ninenines.eu +
+ Fri Jun 19 15:47:14 CEST 2015 +

+
+ +
Hello,
+
+I hope it's OK for me to announce on erlang-questions: The Erlanger 
+Playbook, a book about software development using Erlang, has been 
+*early* released!
+
+The book is meant to be the missing developer manual. It covers all 
+steps from the start of a project to its release including writing code, 
+documentation and tests.
+
+There are books for learning Erlang, for running Erlang in production, 
+but not much for modern Erlang development. This is where The Erlanger 
+Playbook comes in.
+
+This is an early release. An update will be sent to everyone about every 
+month or so. I plan to cover anything that relates to the development of 
+Erlang software, ie the "dev" in "devops". Many tools and techniques 
+will be covered in future updates.
+
+We will do a print book if there is enough interest once the book gets 
+finished, but we're a few months off for now. :-)
+
+You can get more information here:
+
+   http://ninenines.eu/articles/erlanger-playbook/
+
+Thanks for your interest!
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000532.html b/_build/static/archives/extend/2015-June/000532.html new file mode 100644 index 00000000..c1578254 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000532.html @@ -0,0 +1,193 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Robert Balogh + ethrbh at gmail.com +
+ Tue Jun 23 10:28:16 CEST 2015 +

+
+ +
hello,
+
+First of all I would say I am a beginner in Cowboy web server, so probably
+I made something wrong, that is why I got the "fault", what I got.
+
+I would like to build up web page, where the client can communicate to
+server, and server can do the same to client, if client does not send
+anything to server too. The Cowboy has the websocket example, what does
+what I would like to do.
+
+There is only one thing is missing what I would like to have. This is the
+"frameset". My idea is to build the index.html using framsets. I made this
+changes, and I build up the html files for the frames, and of course I set
+these in the index.html.
+
+Here is how the index.html looks like
+    <html>
+
+    <head>
+    <title>Welcome to Websocket example 2</title>
+    </head>
+
+    <frameset rows="64,*">
+        <frame name="top_frame" noresize="noresize" scrolling="no"
+src="frame_top.html">
+        <frameset cols="450,*">
+            <frame name="left_frame" scrolling="auto" src="frame_left.html">
+            <frame name="right_frame" src="frame_right.html">
+        </frameset>
+        <noframes>
+        <body>
+
+        </body>
+        </noframes>
+    </frameset>
+
+    </html>
+
+This is how the priv folder looks like
+-----------------------------------------------------------
+    ls priv/
+    frame_left.html  frame_right.html  frame_top.html  index.html  static
+
+This is how I changed the websocket_2_app:start/2 function
+-----------------------------------------------------------
+    Dispatch = cowboy_router:compile([
+        {'_', [
+
+            {"/", cowboy_static, {priv_file, websocket_2, "index.html"}},
+            {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}},
+
+            {"/websocket_2", ws_handler_2, []},
+            {"/static/[...]", cowboy_static, {priv_dir, websocket_2,
+"static"}}
+        ]}
+    ]),
+
+After compile and make release package of the app, I can reach the
+webserver on the port 8080, but some connection does not set up correctly.
+The following texts are present in the browser
+    DISCONNECTED
+
+    ERROR: undefined
+
+    Connecting to: ws://localhost:8080/websocket_2
+
+I made a dbg trace on all cowboy modules, to start some kind of
+troubleshooting. In the "tons" of printout I can see this one. So in the
+bottom of this, there is an {error,enoent}. It comes when tries connect to
+the socket. But unfortunatelly I do not have idea what may cause this :-(
+
+The part of trace
+-----------------------------------------------------------
+    (<0.177.0>) call
+cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+              {{127,0,0,1},33241},
+              <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+              [<<"websocket_2">>],
+              <<>>,undefined,[],
+              [{<<"host">>,<<"localhost:8080">>},
+               {<<"connection">>,<<"Upgrade">>},
+               {<<"pragma">>,<<"no-cache">>},
+               {<<"cache-control">>,<<"no-cache">>},
+               {<<"upgrade">>,<<"websocket">>},
+               {<<"origin">>,<<"http://localhost:8080">>},
+               {<<"sec-websocket-version">>,<<"13">>},
+               {<<"user-agent">>,
+                <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML,
+like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+               {<<"accept-encoding">>,<<"gzip, deflate, sdch">>},
+               {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+               {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+               {<<"sec-websocket-extensions">>,
+                <<"permessage-deflate; client_max_window_bits">>}],
+              [{<<"connection">>,[<<"upgrade">>]}],
+
+undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+            {handler_opts,{priv_dir,websocket_2,[]}},
+            {listener,http},
+            {dispatch,[{'_',[],
+                            [{[],[],cowboy_static,
+                              {priv_file,websocket_2,"index.html"}},
+
+ {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+                             {[<<"websocket_2">>],[],ws_handler_2,[]},
+                             {[<<"static">>,'...'],
+                              [],cowboy_static,
+                              {priv_dir,websocket_2,"static"}}]}]}],
+           <<"GET">>,cowboy_static,
+
+{<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+            {error,enoent},
+            []},
+           undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+           undefined,undefined},#Fun<cowboy_rest.2.41839999>) (Timestamp:
+{1435,
+
+46126,
+
+935663})
+
+I guess, I did something very wrong, but I did not found what is that, thus
+I would like to get some help from you.
+
+Please find my small project in github:
+https://github.com/ethrbh/websocket_2
+
+thanks for your help,
+/Robi
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150623/69dfc8e4/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000533.html b/_build/static/archives/extend/2015-June/000533.html new file mode 100644 index 00000000..5b1a7df9 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000533.html @@ -0,0 +1,213 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jun 23 10:56:02 CEST 2015 +

+
+ +
The {error, enoent}, especially there, is probably just because the 
+browser is trying to fetch the favicon.
+
+Your issue is that Websocket won't connect, so it has nothing to do with 
+cowboy_rest. Try tracing cowboy_websocket or enable SASL to have more info.
+
+On 06/23/2015 10:28 AM, Robert Balogh wrote:
+> hello,
+>
+> First of all I would say I am a beginner in Cowboy web server, so
+> probably I made something wrong, that is why I got the "fault", what I got.
+>
+> I would like to build up web page, where the client can communicate to
+> server, and server can do the same to client, if client does not send
+> anything to server too. The Cowboy has the websocket example, what does
+> what I would like to do.
+>
+> There is only one thing is missing what I would like to have. This is
+> the "frameset". My idea is to build the index.html using framsets. I
+> made this changes, and I build up the html files for the frames, and of
+> course I set these in the index.html.
+>
+> Here is how the index.html looks like
+>      <html>
+>
+>      <head>
+>      <title>Welcome to Websocket example 2</title>
+>      </head>
+>
+>      <frameset rows="64,*">
+>          <frame name="top_frame" noresize="noresize" scrolling="no"
+> src="frame_top.html">
+>          <frameset cols="450,*">
+>              <frame name="left_frame" scrolling="auto"
+> src="frame_left.html">
+>              <frame name="right_frame" src="frame_right.html">
+>          </frameset>
+>          <noframes>
+>          <body>
+>
+>          </body>
+>          </noframes>
+>      </frameset>
+>
+>      </html>
+>
+> This is how the priv folder looks like
+> -----------------------------------------------------------
+>      ls priv/
+>      frame_left.html  frame_right.html  frame_top.html  index.html  static
+>
+> This is how I changed the websocket_2_app:start/2 function
+> -----------------------------------------------------------
+>      Dispatch = cowboy_router:compile([
+>          {'_', [
+>
+>              {"/", cowboy_static, {priv_file, websocket_2, "index.html"}},
+>              {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}},
+>
+>              {"/websocket_2", ws_handler_2, []},
+>              {"/static/[...]", cowboy_static, {priv_dir, websocket_2,
+> "static"}}
+>          ]}
+>      ]),
+>
+> After compile and make release package of the app, I can reach the
+> webserver on the port 8080, but some connection does not set up
+> correctly. The following texts are present in the browser
+>      DISCONNECTED
+>
+>      ERROR: undefined
+>
+>      Connecting to: ws://localhost:8080/websocket_2
+>
+> I made a dbg trace on all cowboy modules, to start some kind of
+> troubleshooting. In the "tons" of printout I can see this one. So in the
+> bottom of this, there is an {error,enoent}. It comes when tries connect
+> to the socket. But unfortunatelly I do not have idea what may cause this :-(
+>
+> The part of trace
+> -----------------------------------------------------------
+>      (<0.177.0>) call
+> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>                {{127,0,0,1},33241},
+>                <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>                [<<"websocket_2">>],
+>                <<>>,undefined,[],
+>                [{<<"host">>,<<"localhost:8080">>},
+>                 {<<"connection">>,<<"Upgrade">>},
+>                 {<<"pragma">>,<<"no-cache">>},
+>                 {<<"cache-control">>,<<"no-cache">>},
+>                 {<<"upgrade">>,<<"websocket">>},
+>                 {<<"origin">>,<<"http://localhost:8080">>},
+>                 {<<"sec-websocket-version">>,<<"13">>},
+>                 {<<"user-agent">>,
+>                  <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36
+> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>                 {<<"accept-encoding">>,<<"gzip, deflate, sdch">>},
+>                 {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>                 {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>                 {<<"sec-websocket-extensions">>,
+>                  <<"permessage-deflate; client_max_window_bits">>}],
+>                [{<<"connection">>,[<<"upgrade">>]}],
+>
+> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>              {handler_opts,{priv_dir,websocket_2,[]}},
+>              {listener,http},
+>              {dispatch,[{'_',[],
+>                              [{[],[],cowboy_static,
+>                                {priv_file,websocket_2,"index.html"}},
+>
+>   {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>                               {[<<"websocket_2">>],[],ws_handler_2,[]},
+>                               {[<<"static">>,'...'],
+>                                [],cowboy_static,
+>                                {priv_dir,websocket_2,"static"}}]}]}],
+>             <<"GET">>,cowboy_static,
+>
+> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>              {error,enoent},
+>              []},
+>
+> undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>             undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+> (Timestamp: {1435,
+>
+>     46126,
+>
+>     935663})
+>
+> I guess, I did something very wrong, but I did not found what is that,
+> thus I would like to get some help from you.
+>
+> Please find my small project in github:
+> https://github.com/ethrbh/websocket_2
+>
+> thanks for your help,
+> /Robi
+>
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000534.html b/_build/static/archives/extend/2015-June/000534.html new file mode 100644 index 00000000..3d353348 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000534.html @@ -0,0 +1,234 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Graham Hay + grahamrhay at gmail.com +
+ Tue Jun 23 11:06:35 CEST 2015 +

+
+ +
I think the order of your routes is the problem, try putting this line
+<https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17>
+last.
+
+On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> The {error, enoent}, especially there, is probably just because the
+> browser is trying to fetch the favicon.
+>
+> Your issue is that Websocket won't connect, so it has nothing to do with
+> cowboy_rest. Try tracing cowboy_websocket or enable SASL to have more info.
+>
+>
+> On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>
+>> hello,
+>>
+>> First of all I would say I am a beginner in Cowboy web server, so
+>> probably I made something wrong, that is why I got the "fault", what I
+>> got.
+>>
+>> I would like to build up web page, where the client can communicate to
+>> server, and server can do the same to client, if client does not send
+>> anything to server too. The Cowboy has the websocket example, what does
+>> what I would like to do.
+>>
+>> There is only one thing is missing what I would like to have. This is
+>> the "frameset". My idea is to build the index.html using framsets. I
+>> made this changes, and I build up the html files for the frames, and of
+>> course I set these in the index.html.
+>>
+>> Here is how the index.html looks like
+>>      <html>
+>>
+>>      <head>
+>>      <title>Welcome to Websocket example 2</title>
+>>      </head>
+>>
+>>      <frameset rows="64,*">
+>>          <frame name="top_frame" noresize="noresize" scrolling="no"
+>> src="frame_top.html">
+>>          <frameset cols="450,*">
+>>              <frame name="left_frame" scrolling="auto"
+>> src="frame_left.html">
+>>              <frame name="right_frame" src="frame_right.html">
+>>          </frameset>
+>>          <noframes>
+>>          <body>
+>>
+>>          </body>
+>>          </noframes>
+>>      </frameset>
+>>
+>>      </html>
+>>
+>> This is how the priv folder looks like
+>> -----------------------------------------------------------
+>>      ls priv/
+>>      frame_left.html  frame_right.html  frame_top.html  index.html  static
+>>
+>> This is how I changed the websocket_2_app:start/2 function
+>> -----------------------------------------------------------
+>>      Dispatch = cowboy_router:compile([
+>>          {'_', [
+>>
+>>              {"/", cowboy_static, {priv_file, websocket_2, "index.html"}},
+>>              {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}},
+>>
+>>              {"/websocket_2", ws_handler_2, []},
+>>              {"/static/[...]", cowboy_static, {priv_dir, websocket_2,
+>> "static"}}
+>>          ]}
+>>      ]),
+>>
+>> After compile and make release package of the app, I can reach the
+>> webserver on the port 8080, but some connection does not set up
+>> correctly. The following texts are present in the browser
+>>      DISCONNECTED
+>>
+>>      ERROR: undefined
+>>
+>>      Connecting to: ws://localhost:8080/websocket_2
+>>
+>> I made a dbg trace on all cowboy modules, to start some kind of
+>> troubleshooting. In the "tons" of printout I can see this one. So in the
+>> bottom of this, there is an {error,enoent}. It comes when tries connect
+>> to the socket. But unfortunatelly I do not have idea what may cause this
+>> :-(
+>>
+>> The part of trace
+>> -----------------------------------------------------------
+>>      (<0.177.0>) call
+>>
+>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>>                {{127,0,0,1},33241},
+>>                <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>>                [<<"websocket_2">>],
+>>                <<>>,undefined,[],
+>>                [{<<"host">>,<<"localhost:8080">>},
+>>                 {<<"connection">>,<<"Upgrade">>},
+>>                 {<<"pragma">>,<<"no-cache">>},
+>>                 {<<"cache-control">>,<<"no-cache">>},
+>>                 {<<"upgrade">>,<<"websocket">>},
+>>                 {<<"origin">>,<<"http://localhost:8080">>},
+>>                 {<<"sec-websocket-version">>,<<"13">>},
+>>                 {<<"user-agent">>,
+>>                  <<"Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36
+>> (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>>                 {<<"accept-encoding">>,<<"gzip, deflate, sdch">>},
+>>                 {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>>                 {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>>                 {<<"sec-websocket-extensions">>,
+>>                  <<"permessage-deflate; client_max_window_bits">>}],
+>>                [{<<"connection">>,[<<"upgrade">>]}],
+>>
+>>
+>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>>              {handler_opts,{priv_dir,websocket_2,[]}},
+>>              {listener,http},
+>>              {dispatch,[{'_',[],
+>>                              [{[],[],cowboy_static,
+>>                                {priv_file,websocket_2,"index.html"}},
+>>
+>>   {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>>                               {[<<"websocket_2">>],[],ws_handler_2,[]},
+>>                               {[<<"static">>,'...'],
+>>                                [],cowboy_static,
+>>                                {priv_dir,websocket_2,"static"}}]}]}],
+>>             <<"GET">>,cowboy_static,
+>>
+>>
+>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>>              {error,enoent},
+>>              []},
+>>
+>> undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>>             undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>> (Timestamp: {1435,
+>>
+>>     46126,
+>>
+>>     935663})
+>>
+>> I guess, I did something very wrong, but I did not found what is that,
+>> thus I would like to get some help from you.
+>>
+>> Please find my small project in github:
+>> https://github.com/ethrbh/websocket_2
+>>
+>> thanks for your help,
+>> /Robi
+>>
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150623/dd7366a3/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000535.html b/_build/static/archives/extend/2015-June/000535.html new file mode 100644 index 00000000..e653d8cc --- /dev/null +++ b/_build/static/archives/extend/2015-June/000535.html @@ -0,0 +1,259 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jun 23 11:09:27 CEST 2015 +

+
+ +
Oh nice catch ahah. We should probably warn when something like this 
+happens.
+
+On 06/23/2015 11:06 AM, Graham Hay wrote:
+> I think the order of your routes is the problem, try putting this line
+> <https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17>
+> last.
+>
+> On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     The {error, enoent}, especially there, is probably just because the
+>     browser is trying to fetch the favicon.
+>
+>     Your issue is that Websocket won't connect, so it has nothing to do
+>     with cowboy_rest. Try tracing cowboy_websocket or enable SASL to
+>     have more info.
+>
+>
+>     On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>
+>         hello,
+>
+>         First of all I would say I am a beginner in Cowboy web server, so
+>         probably I made something wrong, that is why I got the "fault",
+>         what I got.
+>
+>         I would like to build up web page, where the client can
+>         communicate to
+>         server, and server can do the same to client, if client does not
+>         send
+>         anything to server too. The Cowboy has the websocket example,
+>         what does
+>         what I would like to do.
+>
+>         There is only one thing is missing what I would like to have.
+>         This is
+>         the "frameset". My idea is to build the index.html using framsets. I
+>         made this changes, and I build up the html files for the frames,
+>         and of
+>         course I set these in the index.html.
+>
+>         Here is how the index.html looks like
+>               <html>
+>
+>               <head>
+>               <title>Welcome to Websocket example 2</title>
+>               </head>
+>
+>               <frameset rows="64,*">
+>                   <frame name="top_frame" noresize="noresize" scrolling="no"
+>         src="frame_top.html">
+>                   <frameset cols="450,*">
+>                       <frame name="left_frame" scrolling="auto"
+>         src="frame_left.html">
+>                       <frame name="right_frame" src="frame_right.html">
+>                   </frameset>
+>                   <noframes>
+>                   <body>
+>
+>                   </body>
+>                   </noframes>
+>               </frameset>
+>
+>               </html>
+>
+>         This is how the priv folder looks like
+>         -----------------------------------------------------------
+>               ls priv/
+>               frame_left.html  frame_right.html  frame_top.html
+>         index.html  static
+>
+>         This is how I changed the websocket_2_app:start/2 function
+>         -----------------------------------------------------------
+>               Dispatch = cowboy_router:compile([
+>                   {'_', [
+>
+>                       {"/", cowboy_static, {priv_file, websocket_2,
+>         "index.html"}},
+>                       {"/[...]", cowboy_static, {priv_dir, websocket_2,
+>         ""}},
+>
+>                       {"/websocket_2", ws_handler_2, []},
+>                       {"/static/[...]", cowboy_static, {priv_dir,
+>         websocket_2,
+>         "static"}}
+>                   ]}
+>               ]),
+>
+>         After compile and make release package of the app, I can reach the
+>         webserver on the port 8080, but some connection does not set up
+>         correctly. The following texts are present in the browser
+>               DISCONNECTED
+>
+>               ERROR: undefined
+>
+>               Connecting to: ws://localhost:8080/websocket_2
+>
+>         I made a dbg trace on all cowboy modules, to start some kind of
+>         troubleshooting. In the "tons" of printout I can see this one.
+>         So in the
+>         bottom of this, there is an {error,enoent}. It comes when tries
+>         connect
+>         to the socket. But unfortunatelly I do not have idea what may
+>         cause this :-(
+>
+>         The part of trace
+>         -----------------------------------------------------------
+>               (<0.177.0>) call
+>         cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>                         {{127,0,0,1},33241},
+>                         <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>                         [<<"websocket_2">>],
+>                         <<>>,undefined,[],
+>                         [{<<"host">>,<<"localhost:8080">>},
+>                          {<<"connection">>,<<"Upgrade">>},
+>                          {<<"pragma">>,<<"no-cache">>},
+>                          {<<"cache-control">>,<<"no-cache">>},
+>                          {<<"upgrade">>,<<"websocket">>},
+>                          {<<"origin">>,<<"http://localhost:8080">>},
+>                          {<<"sec-websocket-version">>,<<"13">>},
+>                          {<<"user-agent">>,
+>                           <<"Mozilla/5.0 (X11; Linux i686)
+>         AppleWebKit/537.36
+>         (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>                          {<<"accept-encoding">>,<<"gzip, deflate, sdch">>},
+>                          {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>
+>         {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>                          {<<"sec-websocket-extensions">>,
+>                           <<"permessage-deflate;
+>         client_max_window_bits">>}],
+>                         [{<<"connection">>,[<<"upgrade">>]}],
+>
+>         undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>                       {handler_opts,{priv_dir,websocket_2,[]}},
+>                       {listener,http},
+>                       {dispatch,[{'_',[],
+>                                       [{[],[],cowboy_static,
+>
+>           {priv_file,websocket_2,"index.html"}},
+>
+>            {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>
+>         {[<<"websocket_2">>],[],ws_handler_2,[]},
+>                                        {[<<"static">>,'...'],
+>                                         [],cowboy_static,
+>
+>           {priv_dir,websocket_2,"static"}}]}]}],
+>                      <<"GET">>,cowboy_static,
+>
+>         {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>                       {error,enoent},
+>                       []},
+>
+>         undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>                      undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>         (Timestamp: {1435,
+>
+>              46126,
+>
+>              935663})
+>
+>         I guess, I did something very wrong, but I did not found what is
+>         that,
+>         thus I would like to get some help from you.
+>
+>         Please find my small project in github:
+>         https://github.com/ethrbh/websocket_2
+>
+>         thanks for your help,
+>         /Robi
+>
+>
+>
+>         _______________________________________________
+>         Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         https://lists.ninenines.eu/listinfo/extend
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>     Author of The Erlanger Playbook,
+>     A book about software development using Erlang
+>     _______________________________________________
+>     Extend mailing list
+>     Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>     https://lists.ninenines.eu/listinfo/extend
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000536.html b/_build/static/archives/extend/2015-June/000536.html new file mode 100644 index 00000000..faffd3cc --- /dev/null +++ b/_build/static/archives/extend/2015-June/000536.html @@ -0,0 +1,287 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Robert Balogh + ethrbh at gmail.com +
+ Tue Jun 23 11:11:42 CEST 2015 +

+
+ +
hello,
+
+Thanks for all. The solution is to put the line at last
+    {"/[...]", cowboy_static, {priv_dir, websocket_2, ""}}
+
+Now It works as I expect.
+
+thanks for your help again.
+
+br,
+/Robi
+
+
+2015-06-23 11:09 GMT+02:00 Loïc Hoguin <essen at ninenines.eu>:
+
+> Oh nice catch ahah. We should probably warn when something like this
+> happens.
+>
+> On 06/23/2015 11:06 AM, Graham Hay wrote:
+>
+>> I think the order of your routes is the problem, try putting this line
+>> <
+>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17
+>> >
+>> last.
+>>
+>> On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     The {error, enoent}, especially there, is probably just because the
+>>     browser is trying to fetch the favicon.
+>>
+>>     Your issue is that Websocket won't connect, so it has nothing to do
+>>     with cowboy_rest. Try tracing cowboy_websocket or enable SASL to
+>>     have more info.
+>>
+>>
+>>     On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>>
+>>         hello,
+>>
+>>         First of all I would say I am a beginner in Cowboy web server, so
+>>         probably I made something wrong, that is why I got the "fault",
+>>         what I got.
+>>
+>>         I would like to build up web page, where the client can
+>>         communicate to
+>>         server, and server can do the same to client, if client does not
+>>         send
+>>         anything to server too. The Cowboy has the websocket example,
+>>         what does
+>>         what I would like to do.
+>>
+>>         There is only one thing is missing what I would like to have.
+>>         This is
+>>         the "frameset". My idea is to build the index.html using
+>> framsets. I
+>>         made this changes, and I build up the html files for the frames,
+>>         and of
+>>         course I set these in the index.html.
+>>
+>>         Here is how the index.html looks like
+>>               <html>
+>>
+>>               <head>
+>>               <title>Welcome to Websocket example 2</title>
+>>               </head>
+>>
+>>               <frameset rows="64,*">
+>>                   <frame name="top_frame" noresize="noresize"
+>> scrolling="no"
+>>         src="frame_top.html">
+>>                   <frameset cols="450,*">
+>>                       <frame name="left_frame" scrolling="auto"
+>>         src="frame_left.html">
+>>                       <frame name="right_frame" src="frame_right.html">
+>>                   </frameset>
+>>                   <noframes>
+>>                   <body>
+>>
+>>                   </body>
+>>                   </noframes>
+>>               </frameset>
+>>
+>>               </html>
+>>
+>>         This is how the priv folder looks like
+>>         -----------------------------------------------------------
+>>               ls priv/
+>>               frame_left.html  frame_right.html  frame_top.html
+>>         index.html  static
+>>
+>>         This is how I changed the websocket_2_app:start/2 function
+>>         -----------------------------------------------------------
+>>               Dispatch = cowboy_router:compile([
+>>                   {'_', [
+>>
+>>                       {"/", cowboy_static, {priv_file, websocket_2,
+>>         "index.html"}},
+>>                       {"/[...]", cowboy_static, {priv_dir, websocket_2,
+>>         ""}},
+>>
+>>                       {"/websocket_2", ws_handler_2, []},
+>>                       {"/static/[...]", cowboy_static, {priv_dir,
+>>         websocket_2,
+>>         "static"}}
+>>                   ]}
+>>               ]),
+>>
+>>         After compile and make release package of the app, I can reach the
+>>         webserver on the port 8080, but some connection does not set up
+>>         correctly. The following texts are present in the browser
+>>               DISCONNECTED
+>>
+>>               ERROR: undefined
+>>
+>>               Connecting to: ws://localhost:8080/websocket_2
+>>
+>>         I made a dbg trace on all cowboy modules, to start some kind of
+>>         troubleshooting. In the "tons" of printout I can see this one.
+>>         So in the
+>>         bottom of this, there is an {error,enoent}. It comes when tries
+>>         connect
+>>         to the socket. But unfortunatelly I do not have idea what may
+>>         cause this :-(
+>>
+>>         The part of trace
+>>         -----------------------------------------------------------
+>>               (<0.177.0>) call
+>>
+>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>>                         {{127,0,0,1},33241},
+>>                         <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>>                         [<<"websocket_2">>],
+>>                         <<>>,undefined,[],
+>>                         [{<<"host">>,<<"localhost:8080">>},
+>>                          {<<"connection">>,<<"Upgrade">>},
+>>                          {<<"pragma">>,<<"no-cache">>},
+>>                          {<<"cache-control">>,<<"no-cache">>},
+>>                          {<<"upgrade">>,<<"websocket">>},
+>>                          {<<"origin">>,<<"http://localhost:8080">>},
+>>                          {<<"sec-websocket-version">>,<<"13">>},
+>>                          {<<"user-agent">>,
+>>                           <<"Mozilla/5.0 (X11; Linux i686)
+>>         AppleWebKit/537.36
+>>         (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>>                          {<<"accept-encoding">>,<<"gzip, deflate,
+>> sdch">>},
+>>                          {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>>
+>>         {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>>                          {<<"sec-websocket-extensions">>,
+>>                           <<"permessage-deflate;
+>>         client_max_window_bits">>}],
+>>                         [{<<"connection">>,[<<"upgrade">>]}],
+>>
+>>
+>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>>                       {handler_opts,{priv_dir,websocket_2,[]}},
+>>                       {listener,http},
+>>                       {dispatch,[{'_',[],
+>>                                       [{[],[],cowboy_static,
+>>
+>>           {priv_file,websocket_2,"index.html"}},
+>>
+>>            {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>>
+>>         {[<<"websocket_2">>],[],ws_handler_2,[]},
+>>                                        {[<<"static">>,'...'],
+>>                                         [],cowboy_static,
+>>
+>>           {priv_dir,websocket_2,"static"}}]}]}],
+>>                      <<"GET">>,cowboy_static,
+>>
+>>
+>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>>                       {error,enoent},
+>>                       []},
+>>
+>>         undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>>                      undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>>         (Timestamp: {1435,
+>>
+>>              46126,
+>>
+>>              935663})
+>>
+>>         I guess, I did something very wrong, but I did not found what is
+>>         that,
+>>         thus I would like to get some help from you.
+>>
+>>         Please find my small project in github:
+>>         https://github.com/ethrbh/websocket_2
+>>
+>>         thanks for your help,
+>>         /Robi
+>>
+>>
+>>
+>>         _______________________________________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>     Author of The Erlanger Playbook,
+>>     A book about software development using Erlang
+>>     _______________________________________________
+>>     Extend mailing list
+>>     Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>     https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150623/fcdb2d7b/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000537.html b/_build/static/archives/extend/2015-June/000537.html new file mode 100644 index 00000000..a05fffdd --- /dev/null +++ b/_build/static/archives/extend/2015-June/000537.html @@ -0,0 +1,276 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Graham Hay + grahamrhay at gmail.com +
+ Tue Jun 23 11:11:50 CEST 2015 +

+
+ +
It's bitten me a few times :(
+
+On 23 June 2015 at 10:09, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Oh nice catch ahah. We should probably warn when something like this
+> happens.
+>
+> On 06/23/2015 11:06 AM, Graham Hay wrote:
+>
+>> I think the order of your routes is the problem, try putting this line
+>> <
+>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17
+>> >
+>> last.
+>>
+>> On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     The {error, enoent}, especially there, is probably just because the
+>>     browser is trying to fetch the favicon.
+>>
+>>     Your issue is that Websocket won't connect, so it has nothing to do
+>>     with cowboy_rest. Try tracing cowboy_websocket or enable SASL to
+>>     have more info.
+>>
+>>
+>>     On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>>
+>>         hello,
+>>
+>>         First of all I would say I am a beginner in Cowboy web server, so
+>>         probably I made something wrong, that is why I got the "fault",
+>>         what I got.
+>>
+>>         I would like to build up web page, where the client can
+>>         communicate to
+>>         server, and server can do the same to client, if client does not
+>>         send
+>>         anything to server too. The Cowboy has the websocket example,
+>>         what does
+>>         what I would like to do.
+>>
+>>         There is only one thing is missing what I would like to have.
+>>         This is
+>>         the "frameset". My idea is to build the index.html using
+>> framsets. I
+>>         made this changes, and I build up the html files for the frames,
+>>         and of
+>>         course I set these in the index.html.
+>>
+>>         Here is how the index.html looks like
+>>               <html>
+>>
+>>               <head>
+>>               <title>Welcome to Websocket example 2</title>
+>>               </head>
+>>
+>>               <frameset rows="64,*">
+>>                   <frame name="top_frame" noresize="noresize"
+>> scrolling="no"
+>>         src="frame_top.html">
+>>                   <frameset cols="450,*">
+>>                       <frame name="left_frame" scrolling="auto"
+>>         src="frame_left.html">
+>>                       <frame name="right_frame" src="frame_right.html">
+>>                   </frameset>
+>>                   <noframes>
+>>                   <body>
+>>
+>>                   </body>
+>>                   </noframes>
+>>               </frameset>
+>>
+>>               </html>
+>>
+>>         This is how the priv folder looks like
+>>         -----------------------------------------------------------
+>>               ls priv/
+>>               frame_left.html  frame_right.html  frame_top.html
+>>         index.html  static
+>>
+>>         This is how I changed the websocket_2_app:start/2 function
+>>         -----------------------------------------------------------
+>>               Dispatch = cowboy_router:compile([
+>>                   {'_', [
+>>
+>>                       {"/", cowboy_static, {priv_file, websocket_2,
+>>         "index.html"}},
+>>                       {"/[...]", cowboy_static, {priv_dir, websocket_2,
+>>         ""}},
+>>
+>>                       {"/websocket_2", ws_handler_2, []},
+>>                       {"/static/[...]", cowboy_static, {priv_dir,
+>>         websocket_2,
+>>         "static"}}
+>>                   ]}
+>>               ]),
+>>
+>>         After compile and make release package of the app, I can reach the
+>>         webserver on the port 8080, but some connection does not set up
+>>         correctly. The following texts are present in the browser
+>>               DISCONNECTED
+>>
+>>               ERROR: undefined
+>>
+>>               Connecting to: ws://localhost:8080/websocket_2
+>>
+>>         I made a dbg trace on all cowboy modules, to start some kind of
+>>         troubleshooting. In the "tons" of printout I can see this one.
+>>         So in the
+>>         bottom of this, there is an {error,enoent}. It comes when tries
+>>         connect
+>>         to the socket. But unfortunatelly I do not have idea what may
+>>         cause this :-(
+>>
+>>         The part of trace
+>>         -----------------------------------------------------------
+>>               (<0.177.0>) call
+>>
+>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>>                         {{127,0,0,1},33241},
+>>                         <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>>                         [<<"websocket_2">>],
+>>                         <<>>,undefined,[],
+>>                         [{<<"host">>,<<"localhost:8080">>},
+>>                          {<<"connection">>,<<"Upgrade">>},
+>>                          {<<"pragma">>,<<"no-cache">>},
+>>                          {<<"cache-control">>,<<"no-cache">>},
+>>                          {<<"upgrade">>,<<"websocket">>},
+>>                          {<<"origin">>,<<"http://localhost:8080">>},
+>>                          {<<"sec-websocket-version">>,<<"13">>},
+>>                          {<<"user-agent">>,
+>>                           <<"Mozilla/5.0 (X11; Linux i686)
+>>         AppleWebKit/537.36
+>>         (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>>                          {<<"accept-encoding">>,<<"gzip, deflate,
+>> sdch">>},
+>>                          {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>>
+>>         {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>>                          {<<"sec-websocket-extensions">>,
+>>                           <<"permessage-deflate;
+>>         client_max_window_bits">>}],
+>>                         [{<<"connection">>,[<<"upgrade">>]}],
+>>
+>>
+>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>>                       {handler_opts,{priv_dir,websocket_2,[]}},
+>>                       {listener,http},
+>>                       {dispatch,[{'_',[],
+>>                                       [{[],[],cowboy_static,
+>>
+>>           {priv_file,websocket_2,"index.html"}},
+>>
+>>            {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>>
+>>         {[<<"websocket_2">>],[],ws_handler_2,[]},
+>>                                        {[<<"static">>,'...'],
+>>                                         [],cowboy_static,
+>>
+>>           {priv_dir,websocket_2,"static"}}]}]}],
+>>                      <<"GET">>,cowboy_static,
+>>
+>>
+>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>>                       {error,enoent},
+>>                       []},
+>>
+>>         undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>>                      undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>>         (Timestamp: {1435,
+>>
+>>              46126,
+>>
+>>              935663})
+>>
+>>         I guess, I did something very wrong, but I did not found what is
+>>         that,
+>>         thus I would like to get some help from you.
+>>
+>>         Please find my small project in github:
+>>         https://github.com/ethrbh/websocket_2
+>>
+>>         thanks for your help,
+>>         /Robi
+>>
+>>
+>>
+>>         _______________________________________________
+>>         Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>     Author of The Erlanger Playbook,
+>>     A book about software development using Erlang
+>>     _______________________________________________
+>>     Extend mailing list
+>>     Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>     https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150623/3556788c/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000538.html b/_build/static/archives/extend/2015-June/000538.html new file mode 100644 index 00000000..b7079e06 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000538.html @@ -0,0 +1,312 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Jun 23 11:12:56 CEST 2015 +

+
+ +
I've opened a ticket to remember so something will be done eventually. 
+Thanks for helping!
+
+On 06/23/2015 11:11 AM, Graham Hay wrote:
+> It's bitten me a few times :(
+>
+> On 23 June 2015 at 10:09, Loïc Hoguin <essen at ninenines.eu
+> <mailto:essen at ninenines.eu>> wrote:
+>
+>     Oh nice catch ahah. We should probably warn when something like this
+>     happens.
+>
+>     On 06/23/2015 11:06 AM, Graham Hay wrote:
+>
+>         I think the order of your routes is the problem, try putting
+>         this line
+>         <https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17>
+>         last.
+>
+>         On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu
+>         <mailto:essen at ninenines.eu>
+>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>
+>              The {error, enoent}, especially there, is probably just
+>         because the
+>              browser is trying to fetch the favicon.
+>
+>              Your issue is that Websocket won't connect, so it has
+>         nothing to do
+>              with cowboy_rest. Try tracing cowboy_websocket or enable
+>         SASL to
+>              have more info.
+>
+>
+>              On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>
+>                  hello,
+>
+>                  First of all I would say I am a beginner in Cowboy web
+>         server, so
+>                  probably I made something wrong, that is why I got the
+>         "fault",
+>                  what I got.
+>
+>                  I would like to build up web page, where the client can
+>                  communicate to
+>                  server, and server can do the same to client, if client
+>         does not
+>                  send
+>                  anything to server too. The Cowboy has the websocket
+>         example,
+>                  what does
+>                  what I would like to do.
+>
+>                  There is only one thing is missing what I would like to
+>         have.
+>                  This is
+>                  the "frameset". My idea is to build the index.html
+>         using framsets. I
+>                  made this changes, and I build up the html files for
+>         the frames,
+>                  and of
+>                  course I set these in the index.html.
+>
+>                  Here is how the index.html looks like
+>                        <html>
+>
+>                        <head>
+>                        <title>Welcome to Websocket example 2</title>
+>                        </head>
+>
+>                        <frameset rows="64,*">
+>                            <frame name="top_frame" noresize="noresize"
+>         scrolling="no"
+>                  src="frame_top.html">
+>                            <frameset cols="450,*">
+>                                <frame name="left_frame" scrolling="auto"
+>                  src="frame_left.html">
+>                                <frame name="right_frame"
+>         src="frame_right.html">
+>                            </frameset>
+>                            <noframes>
+>                            <body>
+>
+>                            </body>
+>                            </noframes>
+>                        </frameset>
+>
+>                        </html>
+>
+>                  This is how the priv folder looks like
+>                  -----------------------------------------------------------
+>                        ls priv/
+>                        frame_left.html  frame_right.html  frame_top.html
+>                  index.html  static
+>
+>                  This is how I changed the websocket_2_app:start/2 function
+>                  -----------------------------------------------------------
+>                        Dispatch = cowboy_router:compile([
+>                            {'_', [
+>
+>                                {"/", cowboy_static, {priv_file, websocket_2,
+>                  "index.html"}},
+>                                {"/[...]", cowboy_static, {priv_dir,
+>         websocket_2,
+>                  ""}},
+>
+>                                {"/websocket_2", ws_handler_2, []},
+>                                {"/static/[...]", cowboy_static, {priv_dir,
+>                  websocket_2,
+>                  "static"}}
+>                            ]}
+>                        ]),
+>
+>                  After compile and make release package of the app, I
+>         can reach the
+>                  webserver on the port 8080, but some connection does
+>         not set up
+>                  correctly. The following texts are present in the browser
+>                        DISCONNECTED
+>
+>                        ERROR: undefined
+>
+>                        Connecting to: ws://localhost:8080/websocket_2
+>
+>                  I made a dbg trace on all cowboy modules, to start some
+>         kind of
+>                  troubleshooting. In the "tons" of printout I can see
+>         this one.
+>                  So in the
+>                  bottom of this, there is an {error,enoent}. It comes
+>         when tries
+>                  connect
+>                  to the socket. But unfortunatelly I do not have idea
+>         what may
+>                  cause this :-(
+>
+>                  The part of trace
+>                  -----------------------------------------------------------
+>                        (<0.177.0>) call
+>
+>         cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>                                  {{127,0,0,1},33241},
+>
+>         <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>                                  [<<"websocket_2">>],
+>                                  <<>>,undefined,[],
+>                                  [{<<"host">>,<<"localhost:8080">>},
+>                                   {<<"connection">>,<<"Upgrade">>},
+>                                   {<<"pragma">>,<<"no-cache">>},
+>                                   {<<"cache-control">>,<<"no-cache">>},
+>                                   {<<"upgrade">>,<<"websocket">>},
+>
+>           {<<"origin">>,<<"http://localhost:8080">>},
+>                                   {<<"sec-websocket-version">>,<<"13">>},
+>                                   {<<"user-agent">>,
+>                                    <<"Mozilla/5.0 (X11; Linux i686)
+>                  AppleWebKit/537.36
+>                  (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36">>},
+>                                   {<<"accept-encoding">>,<<"gzip,
+>         deflate, sdch">>},
+>
+>           {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>
+>                  {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>                                   {<<"sec-websocket-extensions">>,
+>                                    <<"permessage-deflate;
+>                  client_max_window_bits">>}],
+>                                  [{<<"connection">>,[<<"upgrade">>]}],
+>
+>
+>         undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>                                {handler_opts,{priv_dir,websocket_2,[]}},
+>                                {listener,http},
+>                                {dispatch,[{'_',[],
+>                                                [{[],[],cowboy_static,
+>
+>                    {priv_file,websocket_2,"index.html"}},
+>
+>                     {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>
+>                  {[<<"websocket_2">>],[],ws_handler_2,[]},
+>                                                 {[<<"static">>,'...'],
+>                                                  [],cowboy_static,
+>
+>                    {priv_dir,websocket_2,"static"}}]}]}],
+>                               <<"GET">>,cowboy_static,
+>
+>
+>         {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>                                {error,enoent},
+>                                []},
+>
+>
+>         undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>
+>           undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>                  (Timestamp: {1435,
+>
+>                       46126,
+>
+>                       935663})
+>
+>                  I guess, I did something very wrong, but I did not
+>         found what is
+>                  that,
+>                  thus I would like to get some help from you.
+>
+>                  Please find my small project in github:
+>         https://github.com/ethrbh/websocket_2
+>
+>                  thanks for your help,
+>                  /Robi
+>
+>
+>
+>                  _______________________________________________
+>                  Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         https://lists.ninenines.eu/listinfo/extend
+>
+>
+>              --
+>              Loïc Hoguin
+>         http://ninenines.eu
+>              Author of The Erlanger Playbook,
+>              A book about software development using Erlang
+>              _______________________________________________
+>              Extend mailing list
+>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>         <mailto:Extend at lists.ninenines.eu
+>         <mailto:Extend at lists.ninenines.eu>>
+>         https://lists.ninenines.eu/listinfo/extend
+>
+>
+>
+>     --
+>     Loïc Hoguin
+>     http://ninenines.eu
+>     Author of The Erlanger Playbook,
+>     A book about software development using Erlang
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000539.html b/_build/static/archives/extend/2015-June/000539.html new file mode 100644 index 00000000..aab2d330 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000539.html @@ -0,0 +1,337 @@ + + + + [99s-extend] Help to use frameset in index.html + + + + + + + + + + +

[99s-extend] Help to use frameset in index.html

+ Robert Balogh + ethrbh at gmail.com +
+ Tue Jun 23 11:15:05 CEST 2015 +

+
+ +
hello,
+
+I would like to thanks for both of you the grate support.
+
+thanks again,
+/Robi
+
+2015-06-23 11:12 GMT+02:00 Loïc Hoguin <essen at ninenines.eu>:
+
+> I've opened a ticket to remember so something will be done eventually.
+> Thanks for helping!
+>
+> On 06/23/2015 11:11 AM, Graham Hay wrote:
+>
+>> It's bitten me a few times :(
+>>
+>> On 23 June 2015 at 10:09, Loïc Hoguin <essen at ninenines.eu
+>> <mailto:essen at ninenines.eu>> wrote:
+>>
+>>     Oh nice catch ahah. We should probably warn when something like this
+>>     happens.
+>>
+>>     On 06/23/2015 11:06 AM, Graham Hay wrote:
+>>
+>>         I think the order of your routes is the problem, try putting
+>>         this line
+>>         <
+>> https://github.com/ethrbh/websocket_2/blob/master/src/websocket_2_app.erl#L17
+>> >
+>>         last.
+>>
+>>         On 23 June 2015 at 09:56, Loïc Hoguin <essen at ninenines.eu
+>>         <mailto:essen at ninenines.eu>
+>>         <mailto:essen at ninenines.eu <mailto:essen at ninenines.eu>>> wrote:
+>>
+>>              The {error, enoent}, especially there, is probably just
+>>         because the
+>>              browser is trying to fetch the favicon.
+>>
+>>              Your issue is that Websocket won't connect, so it has
+>>         nothing to do
+>>              with cowboy_rest. Try tracing cowboy_websocket or enable
+>>         SASL to
+>>              have more info.
+>>
+>>
+>>              On 06/23/2015 10:28 AM, Robert Balogh wrote:
+>>
+>>                  hello,
+>>
+>>                  First of all I would say I am a beginner in Cowboy web
+>>         server, so
+>>                  probably I made something wrong, that is why I got the
+>>         "fault",
+>>                  what I got.
+>>
+>>                  I would like to build up web page, where the client can
+>>                  communicate to
+>>                  server, and server can do the same to client, if client
+>>         does not
+>>                  send
+>>                  anything to server too. The Cowboy has the websocket
+>>         example,
+>>                  what does
+>>                  what I would like to do.
+>>
+>>                  There is only one thing is missing what I would like to
+>>         have.
+>>                  This is
+>>                  the "frameset". My idea is to build the index.html
+>>         using framsets. I
+>>                  made this changes, and I build up the html files for
+>>         the frames,
+>>                  and of
+>>                  course I set these in the index.html.
+>>
+>>                  Here is how the index.html looks like
+>>                        <html>
+>>
+>>                        <head>
+>>                        <title>Welcome to Websocket example 2</title>
+>>                        </head>
+>>
+>>                        <frameset rows="64,*">
+>>                            <frame name="top_frame" noresize="noresize"
+>>         scrolling="no"
+>>                  src="frame_top.html">
+>>                            <frameset cols="450,*">
+>>                                <frame name="left_frame" scrolling="auto"
+>>                  src="frame_left.html">
+>>                                <frame name="right_frame"
+>>         src="frame_right.html">
+>>                            </frameset>
+>>                            <noframes>
+>>                            <body>
+>>
+>>                            </body>
+>>                            </noframes>
+>>                        </frameset>
+>>
+>>                        </html>
+>>
+>>                  This is how the priv folder looks like
+>>
+>>  -----------------------------------------------------------
+>>                        ls priv/
+>>                        frame_left.html  frame_right.html  frame_top.html
+>>                  index.html  static
+>>
+>>                  This is how I changed the websocket_2_app:start/2
+>> function
+>>
+>>  -----------------------------------------------------------
+>>                        Dispatch = cowboy_router:compile([
+>>                            {'_', [
+>>
+>>                                {"/", cowboy_static, {priv_file,
+>> websocket_2,
+>>                  "index.html"}},
+>>                                {"/[...]", cowboy_static, {priv_dir,
+>>         websocket_2,
+>>                  ""}},
+>>
+>>                                {"/websocket_2", ws_handler_2, []},
+>>                                {"/static/[...]", cowboy_static, {priv_dir,
+>>                  websocket_2,
+>>                  "static"}}
+>>                            ]}
+>>                        ]),
+>>
+>>                  After compile and make release package of the app, I
+>>         can reach the
+>>                  webserver on the port 8080, but some connection does
+>>         not set up
+>>                  correctly. The following texts are present in the browser
+>>                        DISCONNECTED
+>>
+>>                        ERROR: undefined
+>>
+>>                        Connecting to: ws://localhost:8080/websocket_2
+>>
+>>                  I made a dbg trace on all cowboy modules, to start some
+>>         kind of
+>>                  troubleshooting. In the "tons" of printout I can see
+>>         this one.
+>>                  So in the
+>>                  bottom of this, there is an {error,enoent}. It comes
+>>         when tries
+>>                  connect
+>>                  to the socket. But unfortunatelly I do not have idea
+>>         what may
+>>                  cause this :-(
+>>
+>>                  The part of trace
+>>
+>>  -----------------------------------------------------------
+>>                        (<0.177.0>) call
+>>
+>>
+>> cowboy_rest:next({http_req,#Port<0.646>,ranch_tcp,keepalive,<0.177.0>,<<"GET">>,'HTTP/1.1',
+>>                                  {{127,0,0,1},33241},
+>>
+>>         <<"localhost">>,undefined,8080,<<"/websocket_2">>,
+>>                                  [<<"websocket_2">>],
+>>                                  <<>>,undefined,[],
+>>                                  [{<<"host">>,<<"localhost:8080">>},
+>>                                   {<<"connection">>,<<"Upgrade">>},
+>>                                   {<<"pragma">>,<<"no-cache">>},
+>>                                   {<<"cache-control">>,<<"no-cache">>},
+>>                                   {<<"upgrade">>,<<"websocket">>},
+>>
+>>           {<<"origin">>,<<"http://localhost:8080">>},
+>>                                   {<<"sec-websocket-version">>,<<"13">>},
+>>                                   {<<"user-agent">>,
+>>                                    <<"Mozilla/5.0 (X11; Linux i686)
+>>                  AppleWebKit/537.36
+>>                  (KHTML, like Gecko) Chrome/40.0.2214.115
+>> Safari/537.36">>},
+>>                                   {<<"accept-encoding">>,<<"gzip,
+>>         deflate, sdch">>},
+>>
+>>           {<<"accept-language">>,<<"en-US,en;q=0.8">>},
+>>
+>>                  {<<"sec-websocket-key">>,<<"by/gwaQvb/51W7Wa9zrGQg==">>},
+>>                                   {<<"sec-websocket-extensions">>,
+>>                                    <<"permessage-deflate;
+>>                  client_max_window_bits">>}],
+>>                                  [{<<"connection">>,[<<"upgrade">>]}],
+>>
+>>
+>>
+>> undefined,[],waiting,<<>>,undefined,false,waiting,[],<<>>,undefined},{state,[{handler,cowboy_static},
+>>                                {handler_opts,{priv_dir,websocket_2,[]}},
+>>                                {listener,http},
+>>                                {dispatch,[{'_',[],
+>>                                                [{[],[],cowboy_static,
+>>
+>>                    {priv_file,websocket_2,"index.html"}},
+>>
+>>                     {['...'],[],cowboy_static,{priv_dir,websocket_2,[]}},
+>>
+>>                  {[<<"websocket_2">>],[],ws_handler_2,[]},
+>>                                                 {[<<"static">>,'...'],
+>>                                                  [],cowboy_static,
+>>
+>>                    {priv_dir,websocket_2,"static"}}]}]}],
+>>                               <<"GET">>,cowboy_static,
+>>
+>>
+>>
+>> {<<"/home/ethrbh/projects/github/websocket_2/_rel/websocket_2/lib/websocket_2-1/priv/websocket_2">>,
+>>                                {error,enoent},
+>>                                []},
+>>
+>>
+>>         undefined,[],undefined,[],undefined,[],undefined,false,undefined,
+>>
+>>           undefined,undefined},#Fun<cowboy_rest.2.41839999>)
+>>                  (Timestamp: {1435,
+>>
+>>                       46126,
+>>
+>>                       935663})
+>>
+>>                  I guess, I did something very wrong, but I did not
+>>         found what is
+>>                  that,
+>>                  thus I would like to get some help from you.
+>>
+>>                  Please find my small project in github:
+>>         https://github.com/ethrbh/websocket_2
+>>
+>>                  thanks for your help,
+>>                  /Robi
+>>
+>>
+>>
+>>                  _______________________________________________
+>>                  Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         <mailto:Extend at lists.ninenines.eu
+>>         <mailto:Extend at lists.ninenines.eu>>
+>>         https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>              --
+>>              Loïc Hoguin
+>>         http://ninenines.eu
+>>              Author of The Erlanger Playbook,
+>>              A book about software development using Erlang
+>>              _______________________________________________
+>>              Extend mailing list
+>>         Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>>         <mailto:Extend at lists.ninenines.eu
+>>         <mailto:Extend at lists.ninenines.eu>>
+>>         https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>
+>>     --
+>>     Loïc Hoguin
+>>     http://ninenines.eu
+>>     Author of The Erlanger Playbook,
+>>     A book about software development using Erlang
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150623/f7c19f68/attachment-0001.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000540.html b/_build/static/archives/extend/2015-June/000540.html new file mode 100644 index 00000000..2816aabb --- /dev/null +++ b/_build/static/archives/extend/2015-June/000540.html @@ -0,0 +1,90 @@ + + + + [99s-extend] Websocket vs. Request-Response msg pair + + + + + + + + + + +

[99s-extend] Websocket vs. Request-Response msg pair

+ Robert Balogh + ethrbh at gmail.com +
+ Wed Jun 24 11:18:50 CEST 2015 +

+
+ +
hello,
+
+According to you grate support I got from you at yesterday, I could
+continue my project, where I use Cowboy webserver and using Websocket. Now
+I made an own web page with basic features I need, so the server and client
+can communicates to eachother. I like it.
+
+Now I would like to step forward, and I would like to implement a
+Request-Response mechanism. I read few articles in to this topic, and all
+of them has mentioned this "feature" is not part of the Websocket standard.
+They were suggested to use some sub-protocols for this, but I did not see
+any written in Erlang.
+
+So, I would like to ask you, do I understand right that Cowboy does not
+have this feature too? If so, do you have some idea how can I implement a
+basic request-response mechanism? Probably one of you guys in this forum
+have some idea.
+
+Btw, the links I read about this topic:
+
+http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol
+    http://alabor.me/articles/request-response-oriented-websockets/
+    https://www.npmjs.com/package/primus-responder
+
+thanks for your help,
+/Robi
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150624/204c1308/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000541.html b/_build/static/archives/extend/2015-June/000541.html new file mode 100644 index 00000000..e0f25c6f --- /dev/null +++ b/_build/static/archives/extend/2015-June/000541.html @@ -0,0 +1,118 @@ + + + + [99s-extend] Websocket vs. Request-Response msg pair + + + + + + + + + + +

[99s-extend] Websocket vs. Request-Response msg pair

+ Graham Hay + grahamrhay at gmail.com +
+ Wed Jun 24 12:19:39 CEST 2015 +

+
+ +
I think you'd have to roll your own, you just need some way to correlate
+<http://www.enterpriseintegrationpatterns.com/CorrelationIdentifier.html>
+responses
+with the originating request. OTP does something similar under the hood
+with gen_server calls <http://www.erlang.org/doc/man/gen_server.html#call-2>
+.
+
+It's also possible to treat the ws connection as a messaging channel, and
+use something like selective consumer
+<http://www.enterpriseintegrationpatterns.com/MessageSelector.html> to
+de-multiplex the messages. e.g. you could add a type/channel field to each
+message, and only subscribe to those messages.
+
+Remember that once you move into an async world, there are no guarantees
+that you will receive a response! So you need to start thinking about
+timeouts etc.
+
+
+On 24 June 2015 at 10:18, Robert Balogh <ethrbh at gmail.com> wrote:
+
+> hello,
+>
+> According to you grate support I got from you at yesterday, I could
+> continue my project, where I use Cowboy webserver and using Websocket. Now
+> I made an own web page with basic features I need, so the server and client
+> can communicates to eachother. I like it.
+>
+> Now I would like to step forward, and I would like to implement a
+> Request-Response mechanism. I read few articles in to this topic, and all
+> of them has mentioned this "feature" is not part of the Websocket standard.
+> They were suggested to use some sub-protocols for this, but I did not see
+> any written in Erlang.
+>
+> So, I would like to ask you, do I understand right that Cowboy does not
+> have this feature too? If so, do you have some idea how can I implement a
+> basic request-response mechanism? Probably one of you guys in this forum
+> have some idea.
+>
+> Btw, the links I read about this topic:
+>
+> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol
+>     http://alabor.me/articles/request-response-oriented-websockets/
+>     https://www.npmjs.com/package/primus-responder
+>
+> thanks for your help,
+> /Robi
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150624/6d15706e/attachment.html>
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000542.html b/_build/static/archives/extend/2015-June/000542.html new file mode 100644 index 00000000..f2fe6371 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000542.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Websocket vs. Request-Response msg pair + + + + + + + + + + +

[99s-extend] Websocket vs. Request-Response msg pair

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Jun 24 12:28:21 CEST 2015 +

+
+ +
On 06/24/2015 11:18 AM, Robert Balogh wrote:
+> Now I would like to step forward, and I would like to implement a
+> Request-Response mechanism. I read few articles in to this topic, and
+> all of them has mentioned this "feature" is not part of the Websocket
+> standard. They were suggested to use some sub-protocols for this, but I
+> did not see any written in Erlang.
+>
+> So, I would like to ask you, do I understand right that Cowboy does not
+> have this feature too? If so, do you have some idea how can I implement
+> a basic request-response mechanism? Probably one of you guys in this
+> forum have some idea.
+
+Cowboy only comes with the Websocket protocol itself, all sub protocols 
+and mechanisms you want can then be implemented on top of it.
+
+I strongly recommend not to do RPC. Just send events to the server and 
+let the server send events to you. The difference is in the fact that 
+RPC tracks what requests were sent to tie requests and responses 
+together, while an event channel does not. You just send what the user 
+is doing and the server sends you what it wants the client to update or 
+do. Stay as stateless as possible.
+
+If you need to manage state to update the interface (locking a form 
+while waiting for the result, for example), do use timeouts to avoid 
+locking endlessly.
+
+Try and experiment, it's not very complicated. :-)
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000543.html b/_build/static/archives/extend/2015-June/000543.html new file mode 100644 index 00000000..222e4a75 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000543.html @@ -0,0 +1,105 @@ + + + + [99s-extend] Websocket vs. Request-Response msg pair + + + + + + + + + + +

[99s-extend] Websocket vs. Request-Response msg pair

+ Bas Wegh + BasWegh at gmx.de +
+ Wed Jun 24 12:28:09 CEST 2015 +

+
+ +
hello Robi,
+
+you might be interested in erwa:
+https://github.com/bwegh/erwa
+
+Cheers,
+Bas
+
+On 06/24/2015 11:18 AM, Robert Balogh wrote:
+> hello,
+>
+> According to you grate support I got from you at yesterday, I could 
+> continue my project, where I use Cowboy webserver and using Websocket. 
+> Now I made an own web page with basic features I need, so the server 
+> and client can communicates to eachother. I like it.
+>
+> Now I would like to step forward, and I would like to implement a 
+> Request-Response mechanism. I read few articles in to this topic, and 
+> all of them has mentioned this "feature" is not part of the Websocket 
+> standard. They were suggested to use some sub-protocols for this, but 
+> I did not see any written in Erlang.
+>
+> So, I would like to ask you, do I understand right that Cowboy does 
+> not have this feature too? If so, do you have some idea how can I 
+> implement a basic request-response mechanism? Probably one of you guys 
+> in this forum have some idea.
+>
+> Btw, the links I read about this topic:
+> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol
+> http://alabor.me/articles/request-response-oriented-websockets/
+> https://www.npmjs.com/package/primus-responder
+>
+> thanks for your help,
+> /Robi
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150624/b67122b6/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/000544.html b/_build/static/archives/extend/2015-June/000544.html new file mode 100644 index 00000000..c6d63e63 --- /dev/null +++ b/_build/static/archives/extend/2015-June/000544.html @@ -0,0 +1,119 @@ + + + + [99s-extend] Websocket vs. Request-Response msg pair + + + + + + + + + + +

[99s-extend] Websocket vs. Request-Response msg pair

+ Robert Balogh + ethrbh at gmail.com +
+ Wed Jun 24 12:41:16 CEST 2015 +

+
+ +
hello,
+
+I would like to thanks the response to all of you. I will try keep all
+these in my mind.
+
+@Bas, thanks for your note about erwa <https://github.com/bwegh/erwa>, I
+will take a look.
+
+thanks again,
+/Robi
+
+2015-06-24 12:28 GMT+02:00 Bas Wegh <BasWegh at gmx.de>:
+
+>  hello Robi,
+>
+> you might be interested in erwa:
+> https://github.com/bwegh/erwa
+>
+> Cheers,
+> Bas
+>
+> On 06/24/2015 11:18 AM, Robert Balogh wrote:
+>
+>   hello,
+>
+>  According to you grate support I got from you at yesterday, I could
+> continue my project, where I use Cowboy webserver and using Websocket. Now
+> I made an own web page with basic features I need, so the server and client
+> can communicates to eachother. I like it.
+>
+> Now I would like to step forward, and I would like to implement a
+> Request-Response mechanism. I read few articles in to this topic, and all
+> of them has mentioned this "feature" is not part of the Websocket standard.
+> They were suggested to use some sub-protocols for this, but I did not see
+> any written in Erlang.
+>
+>  So, I would like to ask you, do I understand right that Cowboy does not
+> have this feature too? If so, do you have some idea how can I implement a
+> basic request-response mechanism? Probably one of you guys in this forum
+> have some idea.
+>
+>  Btw, the links I read about this topic:
+>
+> http://stackoverflow.com/questions/10882370/websocket-request-response-subprotocol
+>     http://alabor.me/articles/request-response-oriented-websockets/
+>     https://www.npmjs.com/package/primus-responder
+>
+>  thanks for your help,
+>  /Robi
+>
+>
+> _______________________________________________
+> Extend mailing listExtend at lists.ninenines.euhttps://lists.ninenines.eu/listinfo/extend
+>
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150624/72689ab9/attachment-0001.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-June/author.html b/_build/static/archives/extend/2015-June/author.html new file mode 100644 index 00000000..c3d02dbc --- /dev/null +++ b/_build/static/archives/extend/2015-June/author.html @@ -0,0 +1,117 @@ + + + + The Extend June 2015 Archive by author + + + + + +

June 2015 Archives by author

+ +

Starting: Fri Jun 19 15:47:14 CEST 2015
+ Ending: Wed Jun 24 12:41:16 CEST 2015
+ Messages: 14

+

+

+ Last message date: + Wed Jun 24 12:41:16 CEST 2015
+ Archived on: Wed Jun 24 12:41:06 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-June/date.html b/_build/static/archives/extend/2015-June/date.html new file mode 100644 index 00000000..ea0c5202 --- /dev/null +++ b/_build/static/archives/extend/2015-June/date.html @@ -0,0 +1,117 @@ + + + + The Extend June 2015 Archive by date + + + + + +

June 2015 Archives by date

+ +

Starting: Fri Jun 19 15:47:14 CEST 2015
+ Ending: Wed Jun 24 12:41:16 CEST 2015
+ Messages: 14

+

+

+ Last message date: + Wed Jun 24 12:41:16 CEST 2015
+ Archived on: Wed Jun 24 12:41:06 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-June/index.html b/_build/static/archives/extend/2015-June/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-June/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-June/subject.html b/_build/static/archives/extend/2015-June/subject.html new file mode 100644 index 00000000..61715ef2 --- /dev/null +++ b/_build/static/archives/extend/2015-June/subject.html @@ -0,0 +1,117 @@ + + + + The Extend June 2015 Archive by subject + + + + + +

June 2015 Archives by subject

+ +

Starting: Fri Jun 19 15:47:14 CEST 2015
+ Ending: Wed Jun 24 12:41:16 CEST 2015
+ Messages: 14

+

+

+ Last message date: + Wed Jun 24 12:41:16 CEST 2015
+ Archived on: Wed Jun 24 12:41:06 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-June/thread.html b/_build/static/archives/extend/2015-June/thread.html new file mode 100644 index 00000000..993cb69f --- /dev/null +++ b/_build/static/archives/extend/2015-June/thread.html @@ -0,0 +1,141 @@ + + + + The Extend June 2015 Archive by thread + + + + + +

June 2015 Archives by thread

+ +

Starting: Fri Jun 19 15:47:14 CEST 2015
+ Ending: Wed Jun 24 12:41:16 CEST 2015
+ Messages: 14

+

+

+ Last message date: + Wed Jun 24 12:41:16 CEST 2015
+ Archived on: Wed Jun 24 12:41:06 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-March.txt b/_build/static/archives/extend/2015-March.txt new file mode 100644 index 00000000..4737e01a --- /dev/null +++ b/_build/static/archives/extend/2015-March.txt @@ -0,0 +1,774 @@ +From samset at wanadoo.fr Thu Mar 19 18:08:54 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 19 Mar 2015 18:08:54 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +Message-ID: + +Hi there, + +I would appreciate your help to understand the following error when running the websocket example. + +Context is : + +ERL 17 +Cowboy 2.0.0-pre (master) +no source modification + + +=ERROR REPORT==== 19-Mar-2015::18:04:36 === +Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? + +Thank you. + +Samir + +From essen at ninenines.eu Thu Mar 19 18:10:29 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 19 Mar 2015 18:10:29 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: +References: +Message-ID: <550B0305.5080108@ninenines.eu> + +How do you run it? + +On 03/19/2015 06:08 PM, Samir Sow wrote: +> Hi there, +> +> I would appreciate your help to understand the following error when running the websocket example. +> +> Context is : +> +> ERL 17 +> Cowboy 2.0.0-pre (master) +> no source modification +> +> +> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +> +> Thank you. +> +> Samir +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From stephane at wirtel.be Thu Mar 19 18:10:58 2015 +From: stephane at wirtel.be (=?utf-8?q?St=C3=A9phane?= Wirtel) +Date: Thu, 19 Mar 2015 18:10:58 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: +References: +Message-ID: + +do you have a priv/ directory in your application ? + + +On 19 Mar 2015, at 18:08, Samir Sow wrote: + +> Hi there, +> +> I would appreciate your help to understand the following error when +> running the websocket example. +> +> Context is : +> +> ERL 17 +> Cowboy 2.0.0-pre (master) +> no source modification +> +> +> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't +> resolve the priv_dir of application +> websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +> +> Thank you. +> +> Samir +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend + + +-- +St?phane Wirtel - http://wirtel.be - @matrixise + +From samset at wanadoo.fr Thu Mar 19 18:31:23 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 19 Mar 2015 18:31:23 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: <550B0305.5080108@ninenines.eu> +References: + <550B0305.5080108@ninenines.eu> +Message-ID: <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + +Manually from the application root dir. +with exec erl +Then starting all required applications + +Not very clever i admit but could not print debug info with _rel/bin/websocket + +Samir + + +> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +> +> How do you run it? +> +> On 03/19/2015 06:08 PM, Samir Sow wrote: +>> Hi there, +>> +>> I would appreciate your help to understand the following error when running the websocket example. +>> +>> Context is : +>> +>> ERL 17 +>> Cowboy 2.0.0-pre (master) +>> no source modification +>> +>> +>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>> +>> Thank you. +>> +>> Samir +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Thu Mar 19 18:40:00 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 19 Mar 2015 18:40:00 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> +Message-ID: <550B09F0.9000907@ninenines.eu> + +If you don't use the release start script it can still work but you must +define ERL_LIBS to let Erlang know where applications are located (-pa +**ebin only says where *beams* are located). + +Maybe more things. + +On 03/19/2015 06:31 PM, Samir Sow wrote: +> Manually from the application root dir. +> with exec erl +> Then starting all required applications +> +> Not very clever i admit but could not print debug info with _rel/bin/websocket +> +> Samir +> +> +>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>> +>> How do you run it? +>> +>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>> Hi there, +>>> +>>> I would appreciate your help to understand the following error when running the websocket example. +>>> +>>> Context is : +>>> +>>> ERL 17 +>>> Cowboy 2.0.0-pre (master) +>>> no source modification +>>> +>>> +>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>> +>>> Thank you. +>>> +>>> Samir +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Thu Mar 19 18:46:38 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 19 Mar 2015 18:46:38 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: <550B09F0.9000907@ninenines.eu> +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + <550B09F0.9000907@ninenines.eu> +Message-ID: + +I?ve exported ERL_LIBS= before erl execution. but got same error ... + + +> On 19 mars 2015, at 18:40, Lo?c Hoguin wrote: +> +> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located). +> +> Maybe more things. +> +> On 03/19/2015 06:31 PM, Samir Sow wrote: +>> Manually from the application root dir. +>> with exec erl +>> Then starting all required applications +>> +>> Not very clever i admit but could not print debug info with _rel/bin/websocket +>> +>> Samir +>> +>> +>>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>>> +>>> How do you run it? +>>> +>>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>>> Hi there, +>>>> +>>>> I would appreciate your help to understand the following error when running the websocket example. +>>>> +>>>> Context is : +>>>> +>>>> ERL 17 +>>>> Cowboy 2.0.0-pre (master) +>>>> no source modification +>>>> +>>>> +>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>>> +>>>> Thank you. +>>>> +>>>> Samir +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Thu Mar 19 18:56:09 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 19 Mar 2015 18:56:09 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + <550B09F0.9000907@ninenines.eu> + +Message-ID: <550B0DB9.9030906@ninenines.eu> + +ERL_LIBS should point to the lib directory (where the application +directories are), not to the root directory of the release. + +On 03/19/2015 06:46 PM, Samir Sow wrote: +> I?ve exported ERL_LIBS= before erl execution. but got same error ... +> +> +>> On 19 mars 2015, at 18:40, Lo?c Hoguin wrote: +>> +>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located). +>> +>> Maybe more things. +>> +>> On 03/19/2015 06:31 PM, Samir Sow wrote: +>>> Manually from the application root dir. +>>> with exec erl +>>> Then starting all required applications +>>> +>>> Not very clever i admit but could not print debug info with _rel/bin/websocket +>>> +>>> Samir +>>> +>>> +>>>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>>>> +>>>> How do you run it? +>>>> +>>>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>>>> Hi there, +>>>>> +>>>>> I would appreciate your help to understand the following error when running the websocket example. +>>>>> +>>>>> Context is : +>>>>> +>>>>> ERL 17 +>>>>> Cowboy 2.0.0-pre (master) +>>>>> no source modification +>>>>> +>>>>> +>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>>>> +>>>>> Thank you. +>>>>> +>>>>> Samir +>>>>> _______________________________________________ +>>>>> Extend mailing list +>>>>> Extend at lists.ninenines.eu +>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Thu Mar 19 19:01:38 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 19 Mar 2015 19:01:38 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: <550B0DB9.9030906@ninenines.eu> +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + <550B09F0.9000907@ninenines.eu> + + <550B0DB9.9030906@ninenines.eu> +Message-ID: + +You mean where src, priv, ebin, deps ? are, right ? + +Samir + +> On 19 mars 2015, at 18:56, Lo?c Hoguin wrote: +> +> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release. +> +> On 03/19/2015 06:46 PM, Samir Sow wrote: +>> I?ve exported ERL_LIBS= before erl execution. but got same error ... +>> +>> +>>> On 19 mars 2015, at 18:40, Lo?c Hoguin wrote: +>>> +>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located). +>>> +>>> Maybe more things. +>>> +>>> On 03/19/2015 06:31 PM, Samir Sow wrote: +>>>> Manually from the application root dir. +>>>> with exec erl +>>>> Then starting all required applications +>>>> +>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket +>>>> +>>>> Samir +>>>> +>>>> +>>>>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>>>>> +>>>>> How do you run it? +>>>>> +>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>>>>> Hi there, +>>>>>> +>>>>>> I would appreciate your help to understand the following error when running the websocket example. +>>>>>> +>>>>>> Context is : +>>>>>> +>>>>>> ERL 17 +>>>>>> Cowboy 2.0.0-pre (master) +>>>>>> no source modification +>>>>>> +>>>>>> +>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>>>>> +>>>>>> Thank you. +>>>>>> +>>>>>> Samir +>>>>>> _______________________________________________ +>>>>>> Extend mailing list +>>>>>> Extend at lists.ninenines.eu +>>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>>> +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> http://ninenines.eu +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From essen at ninenines.eu Thu Mar 19 19:03:50 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Thu, 19 Mar 2015 19:03:50 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + <550B09F0.9000907@ninenines.eu> + + <550B0DB9.9030906@ninenines.eu> + +Message-ID: <550B0F86.7080509@ninenines.eu> + +No. ERL_LIBS=_rel/hello_world_example/lib + +Or, ERL_LIBS=..:deps if you want the non-release version. Beware of +what's in .. though (should be fine if you are in the examples folder). + +On 03/19/2015 07:01 PM, Samir Sow wrote: +> You mean where src, priv, ebin, deps ? are, right ? +> +> Samir +> +>> On 19 mars 2015, at 18:56, Lo?c Hoguin wrote: +>> +>> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release. +>> +>> On 03/19/2015 06:46 PM, Samir Sow wrote: +>>> I?ve exported ERL_LIBS= before erl execution. but got same error ... +>>> +>>> +>>>> On 19 mars 2015, at 18:40, Lo?c Hoguin wrote: +>>>> +>>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located). +>>>> +>>>> Maybe more things. +>>>> +>>>> On 03/19/2015 06:31 PM, Samir Sow wrote: +>>>>> Manually from the application root dir. +>>>>> with exec erl +>>>>> Then starting all required applications +>>>>> +>>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket +>>>>> +>>>>> Samir +>>>>> +>>>>> +>>>>>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>>>>>> +>>>>>> How do you run it? +>>>>>> +>>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>>>>>> Hi there, +>>>>>>> +>>>>>>> I would appreciate your help to understand the following error when running the websocket example. +>>>>>>> +>>>>>>> Context is : +>>>>>>> +>>>>>>> ERL 17 +>>>>>>> Cowboy 2.0.0-pre (master) +>>>>>>> no source modification +>>>>>>> +>>>>>>> +>>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>>>>>> +>>>>>>> Thank you. +>>>>>>> +>>>>>>> Samir +>>>>>>> _______________________________________________ +>>>>>>> Extend mailing list +>>>>>>> Extend at lists.ninenines.eu +>>>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>>>> +>>>>>> +>>>>>> -- +>>>>>> Lo?c Hoguin +>>>>>> http://ninenines.eu +>>>>> +>>>> +>>>> -- +>>>> Lo?c Hoguin +>>>> http://ninenines.eu +>>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Thu Mar 19 19:32:11 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Thu, 19 Mar 2015 19:32:11 +0100 +Subject: [99s-extend] cowboy websocket example runtime error +In-Reply-To: <550B0F86.7080509@ninenines.eu> +References: + <550B0305.5080108@ninenines.eu> + <2BC2405E-905C-4BE7-A579-61FC2AE3E737@wanadoo.fr> + <550B09F0.9000907@ninenines.eu> + + <550B0DB9.9030906@ninenines.eu> + + <550B0F86.7080509@ninenines.eu> +Message-ID: <21D40E7B-2E5E-4EF8-AC2A-2D5229A091AF@wanadoo.fr> + +OK. The error is cleared. +Now i get a 404 on the client when trying to connect. + +Thank you. + +Samir + +> On 19 mars 2015, at 19:03, Lo?c Hoguin wrote: +> +> No. ERL_LIBS=_rel/hello_world_example/lib +> +> Or, ERL_LIBS=..:deps if you want the non-release version. Beware of what's in .. though (should be fine if you are in the examples folder). +> +> On 03/19/2015 07:01 PM, Samir Sow wrote: +>> You mean where src, priv, ebin, deps ? are, right ? +>> +>> Samir +>> +>>> On 19 mars 2015, at 18:56, Lo?c Hoguin wrote: +>>> +>>> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release. +>>> +>>> On 03/19/2015 06:46 PM, Samir Sow wrote: +>>>> I?ve exported ERL_LIBS= before erl execution. but got same error ... +>>>> +>>>> +>>>>> On 19 mars 2015, at 18:40, Lo?c Hoguin wrote: +>>>>> +>>>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located). +>>>>> +>>>>> Maybe more things. +>>>>> +>>>>> On 03/19/2015 06:31 PM, Samir Sow wrote: +>>>>>> Manually from the application root dir. +>>>>>> with exec erl +>>>>>> Then starting all required applications +>>>>>> +>>>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket +>>>>>> +>>>>>> Samir +>>>>>> +>>>>>> +>>>>>>> On 19 mars 2015, at 18:10, Lo?c Hoguin wrote: +>>>>>>> +>>>>>>> How do you run it? +>>>>>>> +>>>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote: +>>>>>>>> Hi there, +>>>>>>>> +>>>>>>>> I would appreciate your help to understand the following error when running the websocket example. +>>>>>>>> +>>>>>>>> Context is : +>>>>>>>> +>>>>>>>> ERL 17 +>>>>>>>> Cowboy 2.0.0-pre (master) +>>>>>>>> no source modification +>>>>>>>> +>>>>>>>> +>>>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 === +>>>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file? +>>>>>>>> +>>>>>>>> Thank you. +>>>>>>>> +>>>>>>>> Samir +>>>>>>>> _______________________________________________ +>>>>>>>> Extend mailing list +>>>>>>>> Extend at lists.ninenines.eu +>>>>>>>> https://lists.ninenines.eu/listinfo/extend +>>>>>>>> +>>>>>>> +>>>>>>> -- +>>>>>>> Lo?c Hoguin +>>>>>>> http://ninenines.eu +>>>>>> +>>>>> +>>>>> -- +>>>>> Lo?c Hoguin +>>>>> http://ninenines.eu +>>>> +>>> +>>> -- +>>> Lo?c Hoguin +>>> http://ninenines.eu +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + +From samset at wanadoo.fr Mon Mar 30 17:12:12 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 30 Mar 2015 17:12:12 +0200 +Subject: [99s-extend] websocket handler +Message-ID: <13CCCB29-ECBD-4CC8-BD53-36A73DD7A62D@wanadoo.fr> + +Hi, + +I would like to pass data to my websocket handler (Opts params). + +init({tcp, http}, Req, Opts) -> + {upgrade, protocol, cowboy_websocket, Req, Opts}. + +websocket_init(_TransportName, Req, Opts) -> + +I guess the Opts param is read from the routing data. +What?s the right syntax to do that. + +Dispatch = cowboy_router:compile([ + {'_', [ + {'_', , []} + ]} + ]), + +Thank you. + +Sincerely. + +Samir Sow + +From essen at ninenines.eu Mon Mar 30 17:18:02 2015 +From: essen at ninenines.eu (=?UTF-8?B?TG/Dr2MgSG9ndWlu?=) +Date: Mon, 30 Mar 2015 17:18:02 +0200 +Subject: [99s-extend] websocket handler +In-Reply-To: <13CCCB29-ECBD-4CC8-BD53-36A73DD7A62D@wanadoo.fr> +References: <13CCCB29-ECBD-4CC8-BD53-36A73DD7A62D@wanadoo.fr> +Message-ID: <5519692A.4070200@ninenines.eu> + +[] is "Opts" in init/3. Whatever value you put there you receive +in your handler. + +On 03/30/2015 05:12 PM, Samir Sow wrote: +> Hi, +> +> I would like to pass data to my websocket handler (Opts params). +> +> init({tcp, http}, Req, Opts) -> +> {upgrade, protocol, cowboy_websocket, Req, Opts}. +> +> websocket_init(_TransportName, Req, Opts) -> +> +> I guess the Opts param is read from the routing data. +> What?s the right syntax to do that. +> +> Dispatch = cowboy_router:compile([ +> {'_', [ +> {'_', , []} +> ]} +> ]), +> +> Thank you. +> +> Sincerely. +> +> Samir Sow +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu + +From samset at wanadoo.fr Mon Mar 30 17:24:09 2015 +From: samset at wanadoo.fr (Samir Sow) +Date: Mon, 30 Mar 2015 17:24:09 +0200 +Subject: [99s-extend] websocket handler +In-Reply-To: <5519692A.4070200@ninenines.eu> +References: <13CCCB29-ECBD-4CC8-BD53-36A73DD7A62D@wanadoo.fr> + <5519692A.4070200@ninenines.eu> +Message-ID: + +Thanks Lo?c. + +Samir + +> On 30 mars 2015, at 17:18, Lo?c Hoguin wrote: +> +> [] is "Opts" in init/3. Whatever value you put there you receive in your handler. +> +> On 03/30/2015 05:12 PM, Samir Sow wrote: +>> Hi, +>> +>> I would like to pass data to my websocket handler (Opts params). +>> +>> init({tcp, http}, Req, Opts) -> +>> {upgrade, protocol, cowboy_websocket, Req, Opts}. +>> +>> websocket_init(_TransportName, Req, Opts) -> +>> +>> I guess the Opts param is read from the routing data. +>> What?s the right syntax to do that. +>> +>> Dispatch = cowboy_router:compile([ +>> {'_', [ +>> {'_', , []} +>> ]} +>> ]), +>> +>> Thank you. +>> +>> Sincerely. +>> +>> Samir Sow +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu + + diff --git a/_build/static/archives/extend/2015-March/000514.html b/_build/static/archives/extend/2015-March/000514.html new file mode 100644 index 00000000..03e420ba --- /dev/null +++ b/_build/static/archives/extend/2015-March/000514.html @@ -0,0 +1,76 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Samir Sow + samset at wanadoo.fr +
+ Thu Mar 19 18:08:54 CET 2015 +

+
+ +
Hi there,
+
+I would appreciate your help to understand the following error when running the websocket example.
+
+Context is :
+
+ERL 17
+Cowboy 2.0.0-pre (master)
+no source modification
+
+
+=ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+
+Thank you.
+
+Samir
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000515.html b/_build/static/archives/extend/2015-March/000515.html new file mode 100644 index 00000000..073476ee --- /dev/null +++ b/_build/static/archives/extend/2015-March/000515.html @@ -0,0 +1,91 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 19 18:10:29 CET 2015 +

+
+ +
How do you run it?
+
+On 03/19/2015 06:08 PM, Samir Sow wrote:
+> Hi there,
+>
+> I would appreciate your help to understand the following error when running the websocket example.
+>
+> Context is :
+>
+> ERL 17
+> Cowboy 2.0.0-pre (master)
+> no source modification
+>
+>
+> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>
+> Thank you.
+>
+> Samir
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000516.html b/_build/static/archives/extend/2015-March/000516.html new file mode 100644 index 00000000..60bd65ab --- /dev/null +++ b/_build/static/archives/extend/2015-March/000516.html @@ -0,0 +1,101 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Stéphane Wirtel + stephane at wirtel.be +
+ Thu Mar 19 18:10:58 CET 2015 +

+
+ +
do you have a priv/ directory in your application ?
+
+
+On 19 Mar 2015, at 18:08, Samir Sow wrote:
+
+> Hi there,
+>
+> I would appreciate your help to understand the following error when 
+> running the websocket example.
+>
+> Context is :
+>
+> ERL 17
+> Cowboy 2.0.0-pre (master)
+> no source modification
+>
+>
+> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't 
+> resolve the priv_dir of application 
+> websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>
+> Thank you.
+>
+> Samir
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+
+
+--
+Stéphane Wirtel - http://wirtel.be - @matrixise
+
+ + + + + + + + + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000517.html b/_build/static/archives/extend/2015-March/000517.html new file mode 100644 index 00000000..e8008d10 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000517.html @@ -0,0 +1,102 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Samir Sow + samset at wanadoo.fr +
+ Thu Mar 19 18:31:23 CET 2015 +

+
+ +
Manually from the application root dir.
+with exec erl <paths> 
+Then starting all required applications 
+
+Not very clever i admit but could not print debug info with _rel/bin/websocket 
+
+Samir
+
+
+> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> How do you run it?
+> 
+> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>> Hi there,
+>> 
+>> I would appreciate your help to understand the following error when running the websocket example.
+>> 
+>> Context is :
+>> 
+>> ERL 17
+>> Cowboy 2.0.0-pre (master)
+>> no source modification
+>> 
+>> 
+>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>> 
+>> Thank you.
+>> 
+>> Samir
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000518.html b/_build/static/archives/extend/2015-March/000518.html new file mode 100644 index 00000000..59bb4fcc --- /dev/null +++ b/_build/static/archives/extend/2015-March/000518.html @@ -0,0 +1,113 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 19 18:40:00 CET 2015 +

+
+ +
If you don't use the release start script it can still work but you must 
+define ERL_LIBS to let Erlang know where applications are located (-pa 
+**ebin only says where *beams* are located).
+
+Maybe more things.
+
+On 03/19/2015 06:31 PM, Samir Sow wrote:
+> Manually from the application root dir.
+> with exec erl <paths>
+> Then starting all required applications
+>
+> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>
+> Samir
+>
+>
+>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> How do you run it?
+>>
+>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>> Hi there,
+>>>
+>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>
+>>> Context is :
+>>>
+>>> ERL 17
+>>> Cowboy 2.0.0-pre (master)
+>>> no source modification
+>>>
+>>>
+>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>
+>>> Thank you.
+>>>
+>>> Samir
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000519.html b/_build/static/archives/extend/2015-March/000519.html new file mode 100644 index 00000000..825de321 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000519.html @@ -0,0 +1,117 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Samir Sow + samset at wanadoo.fr +
+ Thu Mar 19 18:46:38 CET 2015 +

+
+ +
I’ve exported ERL_LIBS=<root_dir> before erl execution. but got same error ...
+
+
+> On 19 mars 2015, at 18:40, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located).
+> 
+> Maybe more things.
+> 
+> On 03/19/2015 06:31 PM, Samir Sow wrote:
+>> Manually from the application root dir.
+>> with exec erl <paths>
+>> Then starting all required applications
+>> 
+>> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>> 
+>> Samir
+>> 
+>> 
+>>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>> How do you run it?
+>>> 
+>>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>>> Hi there,
+>>>> 
+>>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>> 
+>>>> Context is :
+>>>> 
+>>>> ERL 17
+>>>> Cowboy 2.0.0-pre (master)
+>>>> no source modification
+>>>> 
+>>>> 
+>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>> 
+>>>> Thank you.
+>>>> 
+>>>> Samir
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> https://lists.ninenines.eu/listinfo/extend
+>>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000520.html b/_build/static/archives/extend/2015-March/000520.html new file mode 100644 index 00000000..25104e5d --- /dev/null +++ b/_build/static/archives/extend/2015-March/000520.html @@ -0,0 +1,125 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 19 18:56:09 CET 2015 +

+
+ +
ERL_LIBS should point to the lib directory (where the application 
+directories are), not to the root directory of the release.
+
+On 03/19/2015 06:46 PM, Samir Sow wrote:
+> I’ve exported ERL_LIBS=<root_dir> before erl execution. but got same error ...
+>
+>
+>> On 19 mars 2015, at 18:40, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located).
+>>
+>> Maybe more things.
+>>
+>> On 03/19/2015 06:31 PM, Samir Sow wrote:
+>>> Manually from the application root dir.
+>>> with exec erl <paths>
+>>> Then starting all required applications
+>>>
+>>> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>>>
+>>> Samir
+>>>
+>>>
+>>>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>
+>>>> How do you run it?
+>>>>
+>>>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>>>> Hi there,
+>>>>>
+>>>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>>>
+>>>>> Context is :
+>>>>>
+>>>>> ERL 17
+>>>>> Cowboy 2.0.0-pre (master)
+>>>>> no source modification
+>>>>>
+>>>>>
+>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>>>
+>>>>> Thank you.
+>>>>>
+>>>>> Samir
+>>>>> _______________________________________________
+>>>>> Extend mailing list
+>>>>> Extend at lists.ninenines.eu
+>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> http://ninenines.eu
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000521.html b/_build/static/archives/extend/2015-March/000521.html new file mode 100644 index 00000000..ba83f013 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000521.html @@ -0,0 +1,131 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Samir Sow + samset at wanadoo.fr +
+ Thu Mar 19 19:01:38 CET 2015 +

+
+ +
You mean where src, priv, ebin, deps … are, right ?
+
+Samir
+
+> On 19 mars 2015, at 18:56, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release.
+> 
+> On 03/19/2015 06:46 PM, Samir Sow wrote:
+>> I’ve exported ERL_LIBS=<root_dir> before erl execution. but got same error ...
+>> 
+>> 
+>>> On 19 mars 2015, at 18:40, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located).
+>>> 
+>>> Maybe more things.
+>>> 
+>>> On 03/19/2015 06:31 PM, Samir Sow wrote:
+>>>> Manually from the application root dir.
+>>>> with exec erl <paths>
+>>>> Then starting all required applications
+>>>> 
+>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>>>> 
+>>>> Samir
+>>>> 
+>>>> 
+>>>>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>> 
+>>>>> How do you run it?
+>>>>> 
+>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>>>>> Hi there,
+>>>>>> 
+>>>>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>>>> 
+>>>>>> Context is :
+>>>>>> 
+>>>>>> ERL 17
+>>>>>> Cowboy 2.0.0-pre (master)
+>>>>>> no source modification
+>>>>>> 
+>>>>>> 
+>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>>>> 
+>>>>>> Thank you.
+>>>>>> 
+>>>>>> Samir
+>>>>>> _______________________________________________
+>>>>>> Extend mailing list
+>>>>>> Extend at lists.ninenines.eu
+>>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>> 
+>>>>> 
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> http://ninenines.eu
+>>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000522.html b/_build/static/archives/extend/2015-March/000522.html new file mode 100644 index 00000000..9ccfcea0 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000522.html @@ -0,0 +1,141 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Mar 19 19:03:50 CET 2015 +

+
+ +
No. ERL_LIBS=_rel/hello_world_example/lib
+
+Or, ERL_LIBS=..:deps if you want the non-release version. Beware of 
+what's in .. though (should be fine if you are in the examples folder).
+
+On 03/19/2015 07:01 PM, Samir Sow wrote:
+> You mean where src, priv, ebin, deps … are, right ?
+>
+> Samir
+>
+>> On 19 mars 2015, at 18:56, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>
+>> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release.
+>>
+>> On 03/19/2015 06:46 PM, Samir Sow wrote:
+>>> I’ve exported ERL_LIBS=<root_dir> before erl execution. but got same error ...
+>>>
+>>>
+>>>> On 19 mars 2015, at 18:40, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>
+>>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located).
+>>>>
+>>>> Maybe more things.
+>>>>
+>>>> On 03/19/2015 06:31 PM, Samir Sow wrote:
+>>>>> Manually from the application root dir.
+>>>>> with exec erl <paths>
+>>>>> Then starting all required applications
+>>>>>
+>>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>>>>>
+>>>>> Samir
+>>>>>
+>>>>>
+>>>>>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>>>
+>>>>>> How do you run it?
+>>>>>>
+>>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>>>>>> Hi there,
+>>>>>>>
+>>>>>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>>>>>
+>>>>>>> Context is :
+>>>>>>>
+>>>>>>> ERL 17
+>>>>>>> Cowboy 2.0.0-pre (master)
+>>>>>>> no source modification
+>>>>>>>
+>>>>>>>
+>>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>>>>>
+>>>>>>> Thank you.
+>>>>>>>
+>>>>>>> Samir
+>>>>>>> _______________________________________________
+>>>>>>> Extend mailing list
+>>>>>>> Extend at lists.ninenines.eu
+>>>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>>>
+>>>>>>
+>>>>>> --
+>>>>>> Loïc Hoguin
+>>>>>> http://ninenines.eu
+>>>>>
+>>>>
+>>>> --
+>>>> Loïc Hoguin
+>>>> http://ninenines.eu
+>>>
+>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000523.html b/_build/static/archives/extend/2015-March/000523.html new file mode 100644 index 00000000..98bbaa98 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000523.html @@ -0,0 +1,149 @@ + + + + [99s-extend] cowboy websocket example runtime error + + + + + + + + + + +

[99s-extend] cowboy websocket example runtime error

+ Samir Sow + samset at wanadoo.fr +
+ Thu Mar 19 19:32:11 CET 2015 +

+
+ +
OK. The error is cleared.
+Now i get a 404 on the client when trying to connect. 
+
+Thank you.
+
+Samir
+
+> On 19 mars 2015, at 19:03, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> No. ERL_LIBS=_rel/hello_world_example/lib
+> 
+> Or, ERL_LIBS=..:deps if you want the non-release version. Beware of what's in .. though (should be fine if you are in the examples folder).
+> 
+> On 03/19/2015 07:01 PM, Samir Sow wrote:
+>> You mean where src, priv, ebin, deps … are, right ?
+>> 
+>> Samir
+>> 
+>>> On 19 mars 2015, at 18:56, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>> 
+>>> ERL_LIBS should point to the lib directory (where the application directories are), not to the root directory of the release.
+>>> 
+>>> On 03/19/2015 06:46 PM, Samir Sow wrote:
+>>>> I’ve exported ERL_LIBS=<root_dir> before erl execution. but got same error ...
+>>>> 
+>>>> 
+>>>>> On 19 mars 2015, at 18:40, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>> 
+>>>>> If you don't use the release start script it can still work but you must define ERL_LIBS to let Erlang know where applications are located (-pa **ebin only says where *beams* are located).
+>>>>> 
+>>>>> Maybe more things.
+>>>>> 
+>>>>> On 03/19/2015 06:31 PM, Samir Sow wrote:
+>>>>>> Manually from the application root dir.
+>>>>>> with exec erl <paths>
+>>>>>> Then starting all required applications
+>>>>>> 
+>>>>>> Not very clever i admit but could not print debug info with _rel/bin/websocket
+>>>>>> 
+>>>>>> Samir
+>>>>>> 
+>>>>>> 
+>>>>>>> On 19 mars 2015, at 18:10, Loïc Hoguin <essen at ninenines.eu> wrote:
+>>>>>>> 
+>>>>>>> How do you run it?
+>>>>>>> 
+>>>>>>> On 03/19/2015 06:08 PM, Samir Sow wrote:
+>>>>>>>> Hi there,
+>>>>>>>> 
+>>>>>>>> I would appreciate your help to understand the following error when running the websocket example.
+>>>>>>>> 
+>>>>>>>> Context is :
+>>>>>>>> 
+>>>>>>>> ERL 17
+>>>>>>>> Cowboy 2.0.0-pre (master)
+>>>>>>>> no source modification
+>>>>>>>> 
+>>>>>>>> 
+>>>>>>>> =ERROR REPORT==== 19-Mar-2015::18:04:36 ===
+>>>>>>>> Error in process <0.160.0> with exit value: {[{reason,{badarg,"Can't resolve the priv_dir of application websocket"}},{mfa,{cowboy_static,init,2}},{stacktrace,[{cowboy_static,priv_path,2,[{file,"src/cowboy_static.erl"},{line,66}]},{cowboy_static,init_opts,2,[{file…
+>>>>>>>> 
+>>>>>>>> Thank you.
+>>>>>>>> 
+>>>>>>>> Samir
+>>>>>>>> _______________________________________________
+>>>>>>>> Extend mailing list
+>>>>>>>> Extend at lists.ninenines.eu
+>>>>>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>>>>> 
+>>>>>>> 
+>>>>>>> --
+>>>>>>> Loïc Hoguin
+>>>>>>> http://ninenines.eu
+>>>>>> 
+>>>>> 
+>>>>> --
+>>>>> Loïc Hoguin
+>>>>> http://ninenines.eu
+>>>> 
+>>> 
+>>> --
+>>> Loïc Hoguin
+>>> http://ninenines.eu
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000524.html b/_build/static/archives/extend/2015-March/000524.html new file mode 100644 index 00000000..8b391fe5 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000524.html @@ -0,0 +1,84 @@ + + + + [99s-extend] websocket handler + + + + + + + + + + +

[99s-extend] websocket handler

+ Samir Sow + samset at wanadoo.fr +
+ Mon Mar 30 17:12:12 CEST 2015 +

+
+ +
Hi,
+
+I would like to pass data to my websocket handler (Opts params).
+
+init({tcp, http}, Req, Opts) ->
+	{upgrade, protocol, cowboy_websocket, Req, Opts}.
+
+websocket_init(_TransportName, Req, Opts) ->
+
+I guess the Opts param is read from the routing data.
+What’s the right syntax to do that.
+
+Dispatch = cowboy_router:compile([
+		{'_', [
+			{'_', <my_handler>, [<Opts>]}
+		]}
+	]),
+
+Thank you.
+
+Sincerely.
+
+Samir Sow
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000525.html b/_build/static/archives/extend/2015-March/000525.html new file mode 100644 index 00000000..96cd5051 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000525.html @@ -0,0 +1,97 @@ + + + + [99s-extend] websocket handler + + + + + + + + + + +

[99s-extend] websocket handler

+ Loïc Hoguin + essen at ninenines.eu +
+ Mon Mar 30 17:18:02 CEST 2015 +

+
+ +
[<Opts>] is "Opts" in init/3. Whatever value you put there you receive 
+in your handler.
+
+On 03/30/2015 05:12 PM, Samir Sow wrote:
+> Hi,
+>
+> I would like to pass data to my websocket handler (Opts params).
+>
+> init({tcp, http}, Req, Opts) ->
+> 	{upgrade, protocol, cowboy_websocket, Req, Opts}.
+>
+> websocket_init(_TransportName, Req, Opts) ->
+>
+> I guess the Opts param is read from the routing data.
+> What’s the right syntax to do that.
+>
+> Dispatch = cowboy_router:compile([
+> 		{'_', [
+> 			{'_', <my_handler>, [<Opts>]}
+> 		]}
+> 	]),
+>
+> Thank you.
+>
+> Sincerely.
+>
+> Samir Sow
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/000526.html b/_build/static/archives/extend/2015-March/000526.html new file mode 100644 index 00000000..1dda3220 --- /dev/null +++ b/_build/static/archives/extend/2015-March/000526.html @@ -0,0 +1,100 @@ + + + + [99s-extend] websocket handler + + + + + + + + + + +

[99s-extend] websocket handler

+ Samir Sow + samset at wanadoo.fr +
+ Mon Mar 30 17:24:09 CEST 2015 +

+
+ +
Thanks Loïc.
+
+Samir
+
+> On 30 mars 2015, at 17:18, Loïc Hoguin <essen at ninenines.eu> wrote:
+> 
+> [<Opts>] is "Opts" in init/3. Whatever value you put there you receive in your handler.
+> 
+> On 03/30/2015 05:12 PM, Samir Sow wrote:
+>> Hi,
+>> 
+>> I would like to pass data to my websocket handler (Opts params).
+>> 
+>> init({tcp, http}, Req, Opts) ->
+>> 	{upgrade, protocol, cowboy_websocket, Req, Opts}.
+>> 
+>> websocket_init(_TransportName, Req, Opts) ->
+>> 
+>> I guess the Opts param is read from the routing data.
+>> What’s the right syntax to do that.
+>> 
+>> Dispatch = cowboy_router:compile([
+>> 		{'_', [
+>> 			{'_', <my_handler>, [<Opts>]}
+>> 		]}
+>> 	]),
+>> 
+>> Thank you.
+>> 
+>> Sincerely.
+>> 
+>> Samir Sow
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>> 
+> 
+> -- 
+> Loïc Hoguin
+> http://ninenines.eu
+
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-March/author.html b/_build/static/archives/extend/2015-March/author.html new file mode 100644 index 00000000..30795745 --- /dev/null +++ b/_build/static/archives/extend/2015-March/author.html @@ -0,0 +1,112 @@ + + + + The Extend March 2015 Archive by author + + + + + +

March 2015 Archives by author

+ +

Starting: Thu Mar 19 18:08:54 CET 2015
+ Ending: Mon Mar 30 17:24:09 CEST 2015
+ Messages: 13

+

+

+ Last message date: + Mon Mar 30 17:24:09 CEST 2015
+ Archived on: Mon Mar 30 17:24:05 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-March/date.html b/_build/static/archives/extend/2015-March/date.html new file mode 100644 index 00000000..a2b348a3 --- /dev/null +++ b/_build/static/archives/extend/2015-March/date.html @@ -0,0 +1,112 @@ + + + + The Extend March 2015 Archive by date + + + + + +

March 2015 Archives by date

+ +

Starting: Thu Mar 19 18:08:54 CET 2015
+ Ending: Mon Mar 30 17:24:09 CEST 2015
+ Messages: 13

+

+

+ Last message date: + Mon Mar 30 17:24:09 CEST 2015
+ Archived on: Mon Mar 30 17:24:05 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-March/index.html b/_build/static/archives/extend/2015-March/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-March/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-March/subject.html b/_build/static/archives/extend/2015-March/subject.html new file mode 100644 index 00000000..c1d58fde --- /dev/null +++ b/_build/static/archives/extend/2015-March/subject.html @@ -0,0 +1,112 @@ + + + + The Extend March 2015 Archive by subject + + + + + +

March 2015 Archives by subject

+ +

Starting: Thu Mar 19 18:08:54 CET 2015
+ Ending: Mon Mar 30 17:24:09 CEST 2015
+ Messages: 13

+

+

+ Last message date: + Mon Mar 30 17:24:09 CEST 2015
+ Archived on: Mon Mar 30 17:24:05 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-March/thread.html b/_build/static/archives/extend/2015-March/thread.html new file mode 100644 index 00000000..d1255939 --- /dev/null +++ b/_build/static/archives/extend/2015-March/thread.html @@ -0,0 +1,135 @@ + + + + The Extend March 2015 Archive by thread + + + + + +

March 2015 Archives by thread

+ +

Starting: Thu Mar 19 18:08:54 CET 2015
+ Ending: Mon Mar 30 17:24:09 CEST 2015
+ Messages: 13

+

+

+ Last message date: + Mon Mar 30 17:24:09 CEST 2015
+ Archived on: Mon Mar 30 17:24:05 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-October.txt b/_build/static/archives/extend/2015-October.txt new file mode 100644 index 00000000..53f718ed --- /dev/null +++ b/_build/static/archives/extend/2015-October.txt @@ -0,0 +1,80 @@ +From ivan at llaisdy.com Tue Oct 20 15:19:05 2015 +From: ivan at llaisdy.com (Ivan Uemlianin) +Date: Tue, 20 Oct 2015 14:19:05 +0100 +Subject: [99s-extend] Cowboy: Maps instead of records for context variables +Message-ID: <56263F49.2000206@llaisdy.com> + +Dear All + +Would there be any reason against using a map instead of a record for +the context variable in a Cowboy REST resource? + +Quite often I have a few resources doing very similar things in their +callbacks, and I'd like to abstract out the similarities into a module - +but I don't want to share a record between modules. + +Maps seem to be a good fit, and I can't think of any downside +(performance hit should be tiny). + +Can anyone give me reasons to stick with records? + +With thanks and best wishes + +Ivan + + +-- +============================================================ +Ivan A. Uemlianin PhD +Llaisdy +Speech Technology Research and Development + + ivan at llaisdy.com + @llaisdy + llaisdy.wordpress.com + github.com/llaisdy + www.linkedin.com/in/ivanuemlianin + + festina lente +============================================================ + + +From essen at ninenines.eu Tue Oct 20 15:22:39 2015 +From: essen at ninenines.eu (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) +Date: Tue, 20 Oct 2015 15:22:39 +0200 +Subject: [99s-extend] Cowboy: Maps instead of records for context + variables +In-Reply-To: <56263F49.2000206@llaisdy.com> +References: <56263F49.2000206@llaisdy.com> +Message-ID: <5626401F.9050907@ninenines.eu> + +On 10/20/2015 03:19 PM, Ivan Uemlianin wrote: +> Dear All +> +> Would there be any reason against using a map instead of a record for +> the context variable in a Cowboy REST resource? +> +> Quite often I have a few resources doing very similar things in their +> callbacks, and I'd like to abstract out the similarities into a module - +> but I don't want to share a record between modules. +> +> Maps seem to be a good fit, and I can't think of any downside +> (performance hit should be tiny). +> +> Can anyone give me reasons to stick with records? + +The only reason to use records is to keep typespecs information to +improve Dialyzer's error reporting. + +Personally I have no problems going with just maps for all kinds of +states, even if they are in the same module. This is partly because I +rely a lot more on tests than on Dialyzer to tell me my program is wrong. + +Cheers, + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + diff --git a/_build/static/archives/extend/2015-October/000557.html b/_build/static/archives/extend/2015-October/000557.html new file mode 100644 index 00000000..6d8fb533 --- /dev/null +++ b/_build/static/archives/extend/2015-October/000557.html @@ -0,0 +1,93 @@ + + + + [99s-extend] Cowboy: Maps instead of records for context variables + + + + + + + + + + +

[99s-extend] Cowboy: Maps instead of records for context variables

+ Ivan Uemlianin + ivan at llaisdy.com +
+ Tue Oct 20 15:19:05 CEST 2015 +

+
+ +
Dear All
+
+Would there be any reason against using a map instead of a record for 
+the context variable in a Cowboy REST resource?
+
+Quite often I have a few resources doing very similar things in their 
+callbacks, and I'd like to abstract out the similarities into a module - 
+but I don't want to share a record between modules.
+
+Maps seem to be a good fit, and I can't think of any downside 
+(performance hit should be tiny).
+
+Can anyone give me reasons to stick with records?
+
+With thanks and best wishes
+
+Ivan
+
+
+-- 
+============================================================
+Ivan A. Uemlianin PhD
+Llaisdy
+Speech Technology Research and Development
+
+                     ivan at llaisdy.com
+                         @llaisdy
+                          llaisdy.wordpress.com
+               github.com/llaisdy
+                      www.linkedin.com/in/ivanuemlianin
+
+                         festina lente
+============================================================
+
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-October/000558.html b/_build/static/archives/extend/2015-October/000558.html new file mode 100644 index 00000000..87f3fdc2 --- /dev/null +++ b/_build/static/archives/extend/2015-October/000558.html @@ -0,0 +1,87 @@ + + + + [99s-extend] Cowboy: Maps instead of records for context variables + + + + + + + + + + +

[99s-extend] Cowboy: Maps instead of records for context variables

+ Loïc Hoguin + essen at ninenines.eu +
+ Tue Oct 20 15:22:39 CEST 2015 +

+
+ +
On 10/20/2015 03:19 PM, Ivan Uemlianin wrote:
+> Dear All
+>
+> Would there be any reason against using a map instead of a record for
+> the context variable in a Cowboy REST resource?
+>
+> Quite often I have a few resources doing very similar things in their
+> callbacks, and I'd like to abstract out the similarities into a module -
+> but I don't want to share a record between modules.
+>
+> Maps seem to be a good fit, and I can't think of any downside
+> (performance hit should be tiny).
+>
+> Can anyone give me reasons to stick with records?
+
+The only reason to use records is to keep typespecs information to 
+improve Dialyzer's error reporting.
+
+Personally I have no problems going with just maps for all kinds of 
+states, even if they are in the same module. This is partly because I 
+rely a lot more on tests than on Dialyzer to tell me my program is wrong.
+
+Cheers,
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-October/author.html b/_build/static/archives/extend/2015-October/author.html new file mode 100644 index 00000000..9e3529fd --- /dev/null +++ b/_build/static/archives/extend/2015-October/author.html @@ -0,0 +1,57 @@ + + + + The Extend October 2015 Archive by author + + + + + +

October 2015 Archives by author

+ +

Starting: Tue Oct 20 15:19:05 CEST 2015
+ Ending: Tue Oct 20 15:22:39 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Tue Oct 20 15:22:39 CEST 2015
+ Archived on: Tue Oct 20 15:22:18 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-October/date.html b/_build/static/archives/extend/2015-October/date.html new file mode 100644 index 00000000..c4931da1 --- /dev/null +++ b/_build/static/archives/extend/2015-October/date.html @@ -0,0 +1,57 @@ + + + + The Extend October 2015 Archive by date + + + + + +

October 2015 Archives by date

+ +

Starting: Tue Oct 20 15:19:05 CEST 2015
+ Ending: Tue Oct 20 15:22:39 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Tue Oct 20 15:22:39 CEST 2015
+ Archived on: Tue Oct 20 15:22:18 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-October/index.html b/_build/static/archives/extend/2015-October/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-October/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-October/subject.html b/_build/static/archives/extend/2015-October/subject.html new file mode 100644 index 00000000..83befc6a --- /dev/null +++ b/_build/static/archives/extend/2015-October/subject.html @@ -0,0 +1,57 @@ + + + + The Extend October 2015 Archive by subject + + + + + +

October 2015 Archives by subject

+ +

Starting: Tue Oct 20 15:19:05 CEST 2015
+ Ending: Tue Oct 20 15:22:39 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Tue Oct 20 15:22:39 CEST 2015
+ Archived on: Tue Oct 20 15:22:18 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-October/thread.html b/_build/static/archives/extend/2015-October/thread.html new file mode 100644 index 00000000..03ab3275 --- /dev/null +++ b/_build/static/archives/extend/2015-October/thread.html @@ -0,0 +1,61 @@ + + + + The Extend October 2015 Archive by thread + + + + + +

October 2015 Archives by thread

+ +

Starting: Tue Oct 20 15:19:05 CEST 2015
+ Ending: Tue Oct 20 15:22:39 CEST 2015
+ Messages: 2

+

+

+ Last message date: + Tue Oct 20 15:22:39 CEST 2015
+ Archived on: Tue Oct 20 15:22:18 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-September.txt b/_build/static/archives/extend/2015-September.txt new file mode 100644 index 00000000..314f3582 --- /dev/null +++ b/_build/static/archives/extend/2015-September.txt @@ -0,0 +1,552 @@ +From grahamrhay at gmail.com Wed Sep 23 19:45:01 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Wed, 23 Sep 2015 18:45:01 +0100 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +Message-ID: + +I was fiddling with some js, and got tired of restarting the server. I was +under the +impression that using dev_mode with relx was the solution to this problem, +but +I can't seem to get it to work. I have an example here: + +https://github.com/grahamrhay/cowboy_devmode + +If I look in _rel, the lib folder for my app is a symlink, as expected. Yet +when I change +the web page, the rendered page is unchanged. I've tried a hard reload, and +clearing +the cache. + +And, in case that wasn't annoying enough, even restarting the server isn't +enough! +Nor is running make again. In fact, the only way I've found of getting it +to update, +is to turn off dev mode, and build the release. + +Am I missing something really obvious? As far as I can tell from perusing +the code, +the cowboy static handler just serves the file directly from the file +system. + +(P.S. I am using vagrant, but I would expect that to cause errors rather +than this, if +the symlink wasn't working.) +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Thu Sep 24 16:35:52 2015 +From: essen at ninenines.eu (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) +Date: Thu, 24 Sep 2015 16:35:52 +0200 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: +References: +Message-ID: <56040A48.6090800@ninenines.eu> + +Running the release, stopping it, editing the file, running the release +again works here. I suspect something related to Vagrant. + +Also I suggest 'make run' rather than your start.sh. + +On 09/23/2015 07:45 PM, Graham Hay wrote: +> I was fiddling with some js, and got tired of restarting the server. I +> was under the +> impression that using dev_mode with relx was the solution to this +> problem, but +> I can't seem to get it to work. I have an example here: +> +> https://github.com/grahamrhay/cowboy_devmode +> +> If I look in _rel, the lib folder for my app is a symlink, as expected. +> Yet when I change +> the web page, the rendered page is unchanged. I've tried a hard reload, +> and clearing +> the cache. +> +> And, in case that wasn't annoying enough, even restarting the server +> isn't enough! +> Nor is running make again. In fact, the only way I've found of getting +> it to update, +> is to turn off dev mode, and build the release. +> +> Am I missing something really obvious? As far as I can tell from +> perusing the code, +> the cowboy static handler just serves the file directly from the file +> system. +> +> (P.S. I am using vagrant, but I would expect that to cause errors rather +> than this, if +> the symlink wasn't working.) +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From essen at ninenines.eu Thu Sep 24 16:39:17 2015 +From: essen at ninenines.eu (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) +Date: Thu, 24 Sep 2015 16:39:17 +0200 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: <56040A48.6090800@ninenines.eu> +References: + <56040A48.6090800@ninenines.eu> +Message-ID: <56040B15.3090702@ninenines.eu> + +Wait, I'm dumb. These steps also work: + +Running the release, opening the website and seeing ohai, editing the +file with some extra text, reloading, seeing the extra text. + +On 09/24/2015 04:35 PM, Lo?c Hoguin wrote: +> Running the release, stopping it, editing the file, running the release +> again works here. I suspect something related to Vagrant. +> +> Also I suggest 'make run' rather than your start.sh. +> +> On 09/23/2015 07:45 PM, Graham Hay wrote: +>> I was fiddling with some js, and got tired of restarting the server. I +>> was under the +>> impression that using dev_mode with relx was the solution to this +>> problem, but +>> I can't seem to get it to work. I have an example here: +>> +>> https://github.com/grahamrhay/cowboy_devmode +>> +>> If I look in _rel, the lib folder for my app is a symlink, as expected. +>> Yet when I change +>> the web page, the rendered page is unchanged. I've tried a hard reload, +>> and clearing +>> the cache. +>> +>> And, in case that wasn't annoying enough, even restarting the server +>> isn't enough! +>> Nor is running make again. In fact, the only way I've found of getting +>> it to update, +>> is to turn off dev mode, and build the release. +>> +>> Am I missing something really obvious? As far as I can tell from +>> perusing the code, +>> the cowboy static handler just serves the file directly from the file +>> system. +>> +>> (P.S. I am using vagrant, but I would expect that to cause errors rather +>> than this, if +>> the symlink wasn't working.) +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu +>> https://lists.ninenines.eu/listinfo/extend +>> +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From grahamrhay at gmail.com Thu Sep 24 16:57:37 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Thu, 24 Sep 2015 15:57:37 +0100 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: <56040B15.3090702@ninenines.eu> +References: + <56040A48.6090800@ninenines.eu> <56040B15.3090702@ninenines.eu> +Message-ID: + +Yeah, that's how I expected it to work. I'll see if I can identify how +vagrant is causing me problems. + +Didn't know about "make run", thanks :) + +On 24 September 2015 at 15:39, Lo?c Hoguin wrote: + +> Wait, I'm dumb. These steps also work: +> +> Running the release, opening the website and seeing ohai, editing the file +> with some extra text, reloading, seeing the extra text. +> +> +> On 09/24/2015 04:35 PM, Lo?c Hoguin wrote: +> +>> Running the release, stopping it, editing the file, running the release +>> again works here. I suspect something related to Vagrant. +>> +>> Also I suggest 'make run' rather than your start.sh. +>> +>> On 09/23/2015 07:45 PM, Graham Hay wrote: +>> +>>> I was fiddling with some js, and got tired of restarting the server. I +>>> was under the +>>> impression that using dev_mode with relx was the solution to this +>>> problem, but +>>> I can't seem to get it to work. I have an example here: +>>> +>>> https://github.com/grahamrhay/cowboy_devmode +>>> +>>> If I look in _rel, the lib folder for my app is a symlink, as expected. +>>> Yet when I change +>>> the web page, the rendered page is unchanged. I've tried a hard reload, +>>> and clearing +>>> the cache. +>>> +>>> And, in case that wasn't annoying enough, even restarting the server +>>> isn't enough! +>>> Nor is running make again. In fact, the only way I've found of getting +>>> it to update, +>>> is to turn off dev mode, and build the release. +>>> +>>> Am I missing something really obvious? As far as I can tell from +>>> perusing the code, +>>> the cowboy static handler just serves the file directly from the file +>>> system. +>>> +>>> (P.S. I am using vagrant, but I would expect that to cause errors rather +>>> than this, if +>>> the symlink wasn't working.) +>>> +>>> +>>> _______________________________________________ +>>> Extend mailing list +>>> Extend at lists.ninenines.eu +>>> https://lists.ninenines.eu/listinfo/extend +>>> +>>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From grahamrhay at gmail.com Wed Sep 30 18:57:49 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Wed, 30 Sep 2015 17:57:49 +0100 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: +References: + <56040A48.6090800@ninenines.eu> <56040B15.3090702@ninenines.eu> + +Message-ID: + +https://www.virtualbox.org/ticket/9069 + +Opened 4 years ago :( Maybe I should give VMware some money. + +On 24 September 2015 at 15:57, Graham Hay wrote: + +> Yeah, that's how I expected it to work. I'll see if I can identify how +> vagrant is causing me problems. +> +> Didn't know about "make run", thanks :) +> +> On 24 September 2015 at 15:39, Lo?c Hoguin wrote: +> +>> Wait, I'm dumb. These steps also work: +>> +>> Running the release, opening the website and seeing ohai, editing the +>> file with some extra text, reloading, seeing the extra text. +>> +>> +>> On 09/24/2015 04:35 PM, Lo?c Hoguin wrote: +>> +>>> Running the release, stopping it, editing the file, running the release +>>> again works here. I suspect something related to Vagrant. +>>> +>>> Also I suggest 'make run' rather than your start.sh. +>>> +>>> On 09/23/2015 07:45 PM, Graham Hay wrote: +>>> +>>>> I was fiddling with some js, and got tired of restarting the server. I +>>>> was under the +>>>> impression that using dev_mode with relx was the solution to this +>>>> problem, but +>>>> I can't seem to get it to work. I have an example here: +>>>> +>>>> https://github.com/grahamrhay/cowboy_devmode +>>>> +>>>> If I look in _rel, the lib folder for my app is a symlink, as expected. +>>>> Yet when I change +>>>> the web page, the rendered page is unchanged. I've tried a hard reload, +>>>> and clearing +>>>> the cache. +>>>> +>>>> And, in case that wasn't annoying enough, even restarting the server +>>>> isn't enough! +>>>> Nor is running make again. In fact, the only way I've found of getting +>>>> it to update, +>>>> is to turn off dev mode, and build the release. +>>>> +>>>> Am I missing something really obvious? As far as I can tell from +>>>> perusing the code, +>>>> the cowboy static handler just serves the file directly from the file +>>>> system. +>>>> +>>>> (P.S. I am using vagrant, but I would expect that to cause errors rather +>>>> than this, if +>>>> the symlink wasn't working.) +>>>> +>>>> +>>>> _______________________________________________ +>>>> Extend mailing list +>>>> Extend at lists.ninenines.eu +>>>> https://lists.ninenines.eu/listinfo/extend +>>>> +>>>> +>>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> +> +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + +From essen at ninenines.eu Wed Sep 30 19:03:11 2015 +From: essen at ninenines.eu (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) +Date: Wed, 30 Sep 2015 19:03:11 +0200 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: +References: + <56040A48.6090800@ninenines.eu> <56040B15.3090702@ninenines.eu> + + +Message-ID: <560C15CF.7000300@ninenines.eu> + +It's not the first time I see this bug. Can you open a ticket on the +Cowboy project so it gets documented in some kind of "gotchas" section? + +On 09/30/2015 06:57 PM, Graham Hay wrote: +> https://www.virtualbox.org/ticket/9069 +> +> Opened 4 years ago :( Maybe I should give VMware some money. +> +> On 24 September 2015 at 15:57, Graham Hay > wrote: +> +> Yeah, that's how I expected it to work. I'll see if I can identify +> how vagrant is causing me problems. +> +> Didn't know about "make run", thanks :) +> +> On 24 September 2015 at 15:39, Lo?c Hoguin > wrote: +> +> Wait, I'm dumb. These steps also work: +> +> Running the release, opening the website and seeing ohai, +> editing the file with some extra text, reloading, seeing the +> extra text. +> +> +> On 09/24/2015 04:35 PM, Lo?c Hoguin wrote: +> +> Running the release, stopping it, editing the file, running +> the release +> again works here. I suspect something related to Vagrant. +> +> Also I suggest 'make run' rather than your start.sh. +> +> On 09/23/2015 07:45 PM, Graham Hay wrote: +> +> I was fiddling with some js, and got tired of restarting +> the server. I +> was under the +> impression that using dev_mode with relx was the +> solution to this +> problem, but +> I can't seem to get it to work. I have an example here: +> +> https://github.com/grahamrhay/cowboy_devmode +> +> If I look in _rel, the lib folder for my app is a +> symlink, as expected. +> Yet when I change +> the web page, the rendered page is unchanged. I've tried +> a hard reload, +> and clearing +> the cache. +> +> And, in case that wasn't annoying enough, even +> restarting the server +> isn't enough! +> Nor is running make again. In fact, the only way I've +> found of getting +> it to update, +> is to turn off dev mode, and build the release. +> +> Am I missing something really obvious? As far as I can +> tell from +> perusing the code, +> the cowboy static handler just serves the file directly +> from the file +> system. +> +> (P.S. I am using vagrant, but I would expect that to +> cause errors rather +> than this, if +> the symlink wasn't working.) +> +> +> _______________________________________________ +> Extend mailing list +> Extend at lists.ninenines.eu +> https://lists.ninenines.eu/listinfo/extend +> +> +> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +> +> + +-- +Lo?c Hoguin +http://ninenines.eu +Author of The Erlanger Playbook, +A book about software development using Erlang + +From grahamrhay at gmail.com Wed Sep 30 19:22:58 2015 +From: grahamrhay at gmail.com (Graham Hay) +Date: Wed, 30 Sep 2015 18:22:58 +0100 +Subject: [99s-extend] Cowboy, relx, and dev mode, oh my! +In-Reply-To: <560C15CF.7000300@ninenines.eu> +References: + <56040A48.6090800@ninenines.eu> <56040B15.3090702@ninenines.eu> + + + <560C15CF.7000300@ninenines.eu> +Message-ID: + +Done. + +https://github.com/ninenines/cowboy/issues/897 + +On 30 September 2015 at 18:03, Lo?c Hoguin wrote: + +> It's not the first time I see this bug. Can you open a ticket on the +> Cowboy project so it gets documented in some kind of "gotchas" section? +> +> On 09/30/2015 06:57 PM, Graham Hay wrote: +> +>> https://www.virtualbox.org/ticket/9069 +>> +>> Opened 4 years ago :( Maybe I should give VMware some money. +>> +>> On 24 September 2015 at 15:57, Graham Hay > > wrote: +>> +>> Yeah, that's how I expected it to work. I'll see if I can identify +>> how vagrant is causing me problems. +>> +>> Didn't know about "make run", thanks :) +>> +>> On 24 September 2015 at 15:39, Lo?c Hoguin > > wrote: +>> +>> Wait, I'm dumb. These steps also work: +>> +>> Running the release, opening the website and seeing ohai, +>> editing the file with some extra text, reloading, seeing the +>> extra text. +>> +>> +>> On 09/24/2015 04:35 PM, Lo?c Hoguin wrote: +>> +>> Running the release, stopping it, editing the file, running +>> the release +>> again works here. I suspect something related to Vagrant. +>> +>> Also I suggest 'make run' rather than your start.sh. +>> +>> On 09/23/2015 07:45 PM, Graham Hay wrote: +>> +>> I was fiddling with some js, and got tired of restarting +>> the server. I +>> was under the +>> impression that using dev_mode with relx was the +>> solution to this +>> problem, but +>> I can't seem to get it to work. I have an example here: +>> +>> https://github.com/grahamrhay/cowboy_devmode +>> +>> If I look in _rel, the lib folder for my app is a +>> symlink, as expected. +>> Yet when I change +>> the web page, the rendered page is unchanged. I've tried +>> a hard reload, +>> and clearing +>> the cache. +>> +>> And, in case that wasn't annoying enough, even +>> restarting the server +>> isn't enough! +>> Nor is running make again. In fact, the only way I've +>> found of getting +>> it to update, +>> is to turn off dev mode, and build the release. +>> +>> Am I missing something really obvious? As far as I can +>> tell from +>> perusing the code, +>> the cowboy static handler just serves the file directly +>> from the file +>> system. +>> +>> (P.S. I am using vagrant, but I would expect that to +>> cause errors rather +>> than this, if +>> the symlink wasn't working.) +>> +>> +>> _______________________________________________ +>> Extend mailing list +>> Extend at lists.ninenines.eu > Extend at lists.ninenines.eu> +>> https://lists.ninenines.eu/listinfo/extend +>> +>> +>> +>> -- +>> Lo?c Hoguin +>> http://ninenines.eu +>> Author of The Erlanger Playbook, +>> A book about software development using Erlang +>> +>> +>> +>> +> -- +> Lo?c Hoguin +> http://ninenines.eu +> Author of The Erlanger Playbook, +> A book about software development using Erlang +> +-------------- next part -------------- +An HTML attachment was scrubbed... +URL: + diff --git a/_build/static/archives/extend/2015-September/000550.html b/_build/static/archives/extend/2015-September/000550.html new file mode 100644 index 00000000..f379f4ea --- /dev/null +++ b/_build/static/archives/extend/2015-September/000550.html @@ -0,0 +1,90 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Graham Hay + grahamrhay at gmail.com +
+ Wed Sep 23 19:45:01 CEST 2015 +

+
+ +
I was fiddling with some js, and got tired of restarting the server. I was
+under the
+impression that using dev_mode with relx was the solution to this problem,
+but
+I can't seem to get it to work. I have an example here:
+
+https://github.com/grahamrhay/cowboy_devmode
+
+If I look in _rel, the lib folder for my app is a symlink, as expected. Yet
+when I change
+the web page, the rendered page is unchanged. I've tried a hard reload, and
+clearing
+the cache.
+
+And, in case that wasn't annoying enough, even restarting the server isn't
+enough!
+Nor is running make again. In fact, the only way I've found of getting it
+to update,
+is to turn off dev mode, and build the release.
+
+Am I missing something really obvious? As far as I can tell from perusing
+the code,
+the cowboy static handler just serves the file directly from the file
+system.
+
+(P.S. I am using vagrant, but I would expect that to cause errors rather
+than this, if
+the symlink wasn't working.)
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150923/fc8e4ef7/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000551.html b/_build/static/archives/extend/2015-September/000551.html new file mode 100644 index 00000000..158b147a --- /dev/null +++ b/_build/static/archives/extend/2015-September/000551.html @@ -0,0 +1,108 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Sep 24 16:35:52 CEST 2015 +

+
+ +
Running the release, stopping it, editing the file, running the release 
+again works here. I suspect something related to Vagrant.
+
+Also I suggest 'make run' rather than your start.sh.
+
+On 09/23/2015 07:45 PM, Graham Hay wrote:
+> I was fiddling with some js, and got tired of restarting the server. I
+> was under the
+> impression that using dev_mode with relx was the solution to this
+> problem, but
+> I can't seem to get it to work. I have an example here:
+>
+> https://github.com/grahamrhay/cowboy_devmode
+>
+> If I look in _rel, the lib folder for my app is a symlink, as expected.
+> Yet when I change
+> the web page, the rendered page is unchanged. I've tried a hard reload,
+> and clearing
+> the cache.
+>
+> And, in case that wasn't annoying enough, even restarting the server
+> isn't enough!
+> Nor is running make again. In fact, the only way I've found of getting
+> it to update,
+> is to turn off dev mode, and build the release.
+>
+> Am I missing something really obvious? As far as I can tell from
+> perusing the code,
+> the cowboy static handler just serves the file directly from the file
+> system.
+>
+> (P.S. I am using vagrant, but I would expect that to cause errors rather
+> than this, if
+> the symlink wasn't working.)
+>
+>
+> _______________________________________________
+> Extend mailing list
+> Extend at lists.ninenines.eu
+> https://lists.ninenines.eu/listinfo/extend
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000552.html b/_build/static/archives/extend/2015-September/000552.html new file mode 100644 index 00000000..11af1a2d --- /dev/null +++ b/_build/static/archives/extend/2015-September/000552.html @@ -0,0 +1,115 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Loïc Hoguin + essen at ninenines.eu +
+ Thu Sep 24 16:39:17 CEST 2015 +

+
+ +
Wait, I'm dumb. These steps also work:
+
+Running the release, opening the website and seeing ohai, editing the 
+file with some extra text, reloading, seeing the extra text.
+
+On 09/24/2015 04:35 PM, Loïc Hoguin wrote:
+> Running the release, stopping it, editing the file, running the release
+> again works here. I suspect something related to Vagrant.
+>
+> Also I suggest 'make run' rather than your start.sh.
+>
+> On 09/23/2015 07:45 PM, Graham Hay wrote:
+>> I was fiddling with some js, and got tired of restarting the server. I
+>> was under the
+>> impression that using dev_mode with relx was the solution to this
+>> problem, but
+>> I can't seem to get it to work. I have an example here:
+>>
+>> https://github.com/grahamrhay/cowboy_devmode
+>>
+>> If I look in _rel, the lib folder for my app is a symlink, as expected.
+>> Yet when I change
+>> the web page, the rendered page is unchanged. I've tried a hard reload,
+>> and clearing
+>> the cache.
+>>
+>> And, in case that wasn't annoying enough, even restarting the server
+>> isn't enough!
+>> Nor is running make again. In fact, the only way I've found of getting
+>> it to update,
+>> is to turn off dev mode, and build the release.
+>>
+>> Am I missing something really obvious? As far as I can tell from
+>> perusing the code,
+>> the cowboy static handler just serves the file directly from the file
+>> system.
+>>
+>> (P.S. I am using vagrant, but I would expect that to cause errors rather
+>> than this, if
+>> the symlink wasn't working.)
+>>
+>>
+>> _______________________________________________
+>> Extend mailing list
+>> Extend at lists.ninenines.eu
+>> https://lists.ninenines.eu/listinfo/extend
+>>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000553.html b/_build/static/archives/extend/2015-September/000553.html new file mode 100644 index 00000000..d3974e51 --- /dev/null +++ b/_build/static/archives/extend/2015-September/000553.html @@ -0,0 +1,129 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Graham Hay + grahamrhay at gmail.com +
+ Thu Sep 24 16:57:37 CEST 2015 +

+
+ +
Yeah, that's how I expected it to work. I'll see if I can identify how
+vagrant is causing me problems.
+
+Didn't know about "make run", thanks :)
+
+On 24 September 2015 at 15:39, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> Wait, I'm dumb. These steps also work:
+>
+> Running the release, opening the website and seeing ohai, editing the file
+> with some extra text, reloading, seeing the extra text.
+>
+>
+> On 09/24/2015 04:35 PM, Loïc Hoguin wrote:
+>
+>> Running the release, stopping it, editing the file, running the release
+>> again works here. I suspect something related to Vagrant.
+>>
+>> Also I suggest 'make run' rather than your start.sh.
+>>
+>> On 09/23/2015 07:45 PM, Graham Hay wrote:
+>>
+>>> I was fiddling with some js, and got tired of restarting the server. I
+>>> was under the
+>>> impression that using dev_mode with relx was the solution to this
+>>> problem, but
+>>> I can't seem to get it to work. I have an example here:
+>>>
+>>> https://github.com/grahamrhay/cowboy_devmode
+>>>
+>>> If I look in _rel, the lib folder for my app is a symlink, as expected.
+>>> Yet when I change
+>>> the web page, the rendered page is unchanged. I've tried a hard reload,
+>>> and clearing
+>>> the cache.
+>>>
+>>> And, in case that wasn't annoying enough, even restarting the server
+>>> isn't enough!
+>>> Nor is running make again. In fact, the only way I've found of getting
+>>> it to update,
+>>> is to turn off dev mode, and build the release.
+>>>
+>>> Am I missing something really obvious? As far as I can tell from
+>>> perusing the code,
+>>> the cowboy static handler just serves the file directly from the file
+>>> system.
+>>>
+>>> (P.S. I am using vagrant, but I would expect that to cause errors rather
+>>> than this, if
+>>> the symlink wasn't working.)
+>>>
+>>>
+>>> _______________________________________________
+>>> Extend mailing list
+>>> Extend at lists.ninenines.eu
+>>> https://lists.ninenines.eu/listinfo/extend
+>>>
+>>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150924/6a9add86/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000554.html b/_build/static/archives/extend/2015-September/000554.html new file mode 100644 index 00000000..9284c104 --- /dev/null +++ b/_build/static/archives/extend/2015-September/000554.html @@ -0,0 +1,137 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Graham Hay + grahamrhay at gmail.com +
+ Wed Sep 30 18:57:49 CEST 2015 +

+
+ +
https://www.virtualbox.org/ticket/9069
+
+Opened 4 years ago :( Maybe I should give VMware some money.
+
+On 24 September 2015 at 15:57, Graham Hay <grahamrhay at gmail.com> wrote:
+
+> Yeah, that's how I expected it to work. I'll see if I can identify how
+> vagrant is causing me problems.
+>
+> Didn't know about "make run", thanks :)
+>
+> On 24 September 2015 at 15:39, Loïc Hoguin <essen at ninenines.eu> wrote:
+>
+>> Wait, I'm dumb. These steps also work:
+>>
+>> Running the release, opening the website and seeing ohai, editing the
+>> file with some extra text, reloading, seeing the extra text.
+>>
+>>
+>> On 09/24/2015 04:35 PM, Loïc Hoguin wrote:
+>>
+>>> Running the release, stopping it, editing the file, running the release
+>>> again works here. I suspect something related to Vagrant.
+>>>
+>>> Also I suggest 'make run' rather than your start.sh.
+>>>
+>>> On 09/23/2015 07:45 PM, Graham Hay wrote:
+>>>
+>>>> I was fiddling with some js, and got tired of restarting the server. I
+>>>> was under the
+>>>> impression that using dev_mode with relx was the solution to this
+>>>> problem, but
+>>>> I can't seem to get it to work. I have an example here:
+>>>>
+>>>> https://github.com/grahamrhay/cowboy_devmode
+>>>>
+>>>> If I look in _rel, the lib folder for my app is a symlink, as expected.
+>>>> Yet when I change
+>>>> the web page, the rendered page is unchanged. I've tried a hard reload,
+>>>> and clearing
+>>>> the cache.
+>>>>
+>>>> And, in case that wasn't annoying enough, even restarting the server
+>>>> isn't enough!
+>>>> Nor is running make again. In fact, the only way I've found of getting
+>>>> it to update,
+>>>> is to turn off dev mode, and build the release.
+>>>>
+>>>> Am I missing something really obvious? As far as I can tell from
+>>>> perusing the code,
+>>>> the cowboy static handler just serves the file directly from the file
+>>>> system.
+>>>>
+>>>> (P.S. I am using vagrant, but I would expect that to cause errors rather
+>>>> than this, if
+>>>> the symlink wasn't working.)
+>>>>
+>>>>
+>>>> _______________________________________________
+>>>> Extend mailing list
+>>>> Extend at lists.ninenines.eu
+>>>> https://lists.ninenines.eu/listinfo/extend
+>>>>
+>>>>
+>>>
+>> --
+>> Loïc Hoguin
+>> http://ninenines.eu
+>> Author of The Erlanger Playbook,
+>> A book about software development using Erlang
+>>
+>
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150930/ee98f926/attachment.html>
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000555.html b/_build/static/archives/extend/2015-September/000555.html new file mode 100644 index 00000000..e8108fe5 --- /dev/null +++ b/_build/static/archives/extend/2015-September/000555.html @@ -0,0 +1,157 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Loïc Hoguin + essen at ninenines.eu +
+ Wed Sep 30 19:03:11 CEST 2015 +

+
+ +
It's not the first time I see this bug. Can you open a ticket on the 
+Cowboy project so it gets documented in some kind of "gotchas" section?
+
+On 09/30/2015 06:57 PM, Graham Hay wrote:
+> https://www.virtualbox.org/ticket/9069
+>
+> Opened 4 years ago :( Maybe I should give VMware some money.
+>
+> On 24 September 2015 at 15:57, Graham Hay <grahamrhay at gmail.com
+> <mailto:grahamrhay at gmail.com>> wrote:
+>
+>     Yeah, that's how I expected it to work. I'll see if I can identify
+>     how vagrant is causing me problems.
+>
+>     Didn't know about "make run", thanks :)
+>
+>     On 24 September 2015 at 15:39, Loïc Hoguin <essen at ninenines.eu
+>     <mailto:essen at ninenines.eu>> wrote:
+>
+>         Wait, I'm dumb. These steps also work:
+>
+>         Running the release, opening the website and seeing ohai,
+>         editing the file with some extra text, reloading, seeing the
+>         extra text.
+>
+>
+>         On 09/24/2015 04:35 PM, Loïc Hoguin wrote:
+>
+>             Running the release, stopping it, editing the file, running
+>             the release
+>             again works here. I suspect something related to Vagrant.
+>
+>             Also I suggest 'make run' rather than your start.sh.
+>
+>             On 09/23/2015 07:45 PM, Graham Hay wrote:
+>
+>                 I was fiddling with some js, and got tired of restarting
+>                 the server. I
+>                 was under the
+>                 impression that using dev_mode with relx was the
+>                 solution to this
+>                 problem, but
+>                 I can't seem to get it to work. I have an example here:
+>
+>                 https://github.com/grahamrhay/cowboy_devmode
+>
+>                 If I look in _rel, the lib folder for my app is a
+>                 symlink, as expected.
+>                 Yet when I change
+>                 the web page, the rendered page is unchanged. I've tried
+>                 a hard reload,
+>                 and clearing
+>                 the cache.
+>
+>                 And, in case that wasn't annoying enough, even
+>                 restarting the server
+>                 isn't enough!
+>                 Nor is running make again. In fact, the only way I've
+>                 found of getting
+>                 it to update,
+>                 is to turn off dev mode, and build the release.
+>
+>                 Am I missing something really obvious? As far as I can
+>                 tell from
+>                 perusing the code,
+>                 the cowboy static handler just serves the file directly
+>                 from the file
+>                 system.
+>
+>                 (P.S. I am using vagrant, but I would expect that to
+>                 cause errors rather
+>                 than this, if
+>                 the symlink wasn't working.)
+>
+>
+>                 _______________________________________________
+>                 Extend mailing list
+>                 Extend at lists.ninenines.eu <mailto:Extend at lists.ninenines.eu>
+>                 https://lists.ninenines.eu/listinfo/extend
+>
+>
+>
+>         --
+>         Loïc Hoguin
+>         http://ninenines.eu
+>         Author of The Erlanger Playbook,
+>         A book about software development using Erlang
+>
+>
+>
+
+-- 
+Loïc Hoguin
+http://ninenines.eu
+Author of The Erlanger Playbook,
+A book about software development using Erlang
+
+ + + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/000556.html b/_build/static/archives/extend/2015-September/000556.html new file mode 100644 index 00000000..fe4f8d6a --- /dev/null +++ b/_build/static/archives/extend/2015-September/000556.html @@ -0,0 +1,166 @@ + + + + [99s-extend] Cowboy, relx, and dev mode, oh my! + + + + + + + + + + +

[99s-extend] Cowboy, relx, and dev mode, oh my!

+ Graham Hay + grahamrhay at gmail.com +
+ Wed Sep 30 19:22:58 CEST 2015 +

+
+ +
Done.
+
+https://github.com/ninenines/cowboy/issues/897
+
+On 30 September 2015 at 18:03, Loïc Hoguin <essen at ninenines.eu> wrote:
+
+> It's not the first time I see this bug. Can you open a ticket on the
+> Cowboy project so it gets documented in some kind of "gotchas" section?
+>
+> On 09/30/2015 06:57 PM, Graham Hay wrote:
+>
+>> https://www.virtualbox.org/ticket/9069
+>>
+>> Opened 4 years ago :( Maybe I should give VMware some money.
+>>
+>> On 24 September 2015 at 15:57, Graham Hay <grahamrhay at gmail.com
+>> <mailto:grahamrhay at gmail.com>> wrote:
+>>
+>>     Yeah, that's how I expected it to work. I'll see if I can identify
+>>     how vagrant is causing me problems.
+>>
+>>     Didn't know about "make run", thanks :)
+>>
+>>     On 24 September 2015 at 15:39, Loïc Hoguin <essen at ninenines.eu
+>>     <mailto:essen at ninenines.eu>> wrote:
+>>
+>>         Wait, I'm dumb. These steps also work:
+>>
+>>         Running the release, opening the website and seeing ohai,
+>>         editing the file with some extra text, reloading, seeing the
+>>         extra text.
+>>
+>>
+>>         On 09/24/2015 04:35 PM, Loïc Hoguin wrote:
+>>
+>>             Running the release, stopping it, editing the file, running
+>>             the release
+>>             again works here. I suspect something related to Vagrant.
+>>
+>>             Also I suggest 'make run' rather than your start.sh.
+>>
+>>             On 09/23/2015 07:45 PM, Graham Hay wrote:
+>>
+>>                 I was fiddling with some js, and got tired of restarting
+>>                 the server. I
+>>                 was under the
+>>                 impression that using dev_mode with relx was the
+>>                 solution to this
+>>                 problem, but
+>>                 I can't seem to get it to work. I have an example here:
+>>
+>>                 https://github.com/grahamrhay/cowboy_devmode
+>>
+>>                 If I look in _rel, the lib folder for my app is a
+>>                 symlink, as expected.
+>>                 Yet when I change
+>>                 the web page, the rendered page is unchanged. I've tried
+>>                 a hard reload,
+>>                 and clearing
+>>                 the cache.
+>>
+>>                 And, in case that wasn't annoying enough, even
+>>                 restarting the server
+>>                 isn't enough!
+>>                 Nor is running make again. In fact, the only way I've
+>>                 found of getting
+>>                 it to update,
+>>                 is to turn off dev mode, and build the release.
+>>
+>>                 Am I missing something really obvious? As far as I can
+>>                 tell from
+>>                 perusing the code,
+>>                 the cowboy static handler just serves the file directly
+>>                 from the file
+>>                 system.
+>>
+>>                 (P.S. I am using vagrant, but I would expect that to
+>>                 cause errors rather
+>>                 than this, if
+>>                 the symlink wasn't working.)
+>>
+>>
+>>                 _______________________________________________
+>>                 Extend mailing list
+>>                 Extend at lists.ninenines.eu <mailto:
+>> Extend at lists.ninenines.eu>
+>>                 https://lists.ninenines.eu/listinfo/extend
+>>
+>>
+>>
+>>         --
+>>         Loïc Hoguin
+>>         http://ninenines.eu
+>>         Author of The Erlanger Playbook,
+>>         A book about software development using Erlang
+>>
+>>
+>>
+>>
+> --
+> Loïc Hoguin
+> http://ninenines.eu
+> Author of The Erlanger Playbook,
+> A book about software development using Erlang
+>
+-------------- next part --------------
+An HTML attachment was scrubbed...
+URL: <http://lists.ninenines.eu/archives/extend/attachments/20150930/7f5e7422/attachment-0001.html>
+
+ + +
+

+ +
+More information about the Extend +mailing list
+ diff --git a/_build/static/archives/extend/2015-September/author.html b/_build/static/archives/extend/2015-September/author.html new file mode 100644 index 00000000..25d8e9b2 --- /dev/null +++ b/_build/static/archives/extend/2015-September/author.html @@ -0,0 +1,82 @@ + + + + The Extend September 2015 Archive by author + + + + + +

September 2015 Archives by author

+ +

Starting: Wed Sep 23 19:45:01 CEST 2015
+ Ending: Wed Sep 30 19:22:58 CEST 2015
+ Messages: 7

+

+

+ Last message date: + Wed Sep 30 19:22:58 CEST 2015
+ Archived on: Wed Sep 30 19:22:39 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-September/date.html b/_build/static/archives/extend/2015-September/date.html new file mode 100644 index 00000000..8bfd7995 --- /dev/null +++ b/_build/static/archives/extend/2015-September/date.html @@ -0,0 +1,82 @@ + + + + The Extend September 2015 Archive by date + + + + + +

September 2015 Archives by date

+ +

Starting: Wed Sep 23 19:45:01 CEST 2015
+ Ending: Wed Sep 30 19:22:58 CEST 2015
+ Messages: 7

+

+

+ Last message date: + Wed Sep 30 19:22:58 CEST 2015
+ Archived on: Wed Sep 30 19:22:39 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-September/index.html b/_build/static/archives/extend/2015-September/index.html new file mode 120000 index 00000000..db4b46f7 --- /dev/null +++ b/_build/static/archives/extend/2015-September/index.html @@ -0,0 +1 @@ +thread.html \ No newline at end of file diff --git a/_build/static/archives/extend/2015-September/subject.html b/_build/static/archives/extend/2015-September/subject.html new file mode 100644 index 00000000..b0ce2f23 --- /dev/null +++ b/_build/static/archives/extend/2015-September/subject.html @@ -0,0 +1,82 @@ + + + + The Extend September 2015 Archive by subject + + + + + +

September 2015 Archives by subject

+ +

Starting: Wed Sep 23 19:45:01 CEST 2015
+ Ending: Wed Sep 30 19:22:58 CEST 2015
+ Messages: 7

+

+

+ Last message date: + Wed Sep 30 19:22:58 CEST 2015
+ Archived on: Wed Sep 30 19:22:39 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/2015-September/thread.html b/_build/static/archives/extend/2015-September/thread.html new file mode 100644 index 00000000..d868b766 --- /dev/null +++ b/_build/static/archives/extend/2015-September/thread.html @@ -0,0 +1,95 @@ + + + + The Extend September 2015 Archive by thread + + + + + +

September 2015 Archives by thread

+ +

Starting: Wed Sep 23 19:45:01 CEST 2015
+ Ending: Wed Sep 30 19:22:58 CEST 2015
+ Messages: 7

+

+

+ Last message date: + Wed Sep 30 19:22:58 CEST 2015
+ Archived on: Wed Sep 30 19:22:39 CEST 2015 +

+

+

+

+ This archive was generated by + Pipermail 0.09 (Mailman edition). + + + diff --git a/_build/static/archives/extend/attachments/20121030/3de26c28/attachment.html b/_build/static/archives/extend/attachments/20121030/3de26c28/attachment.html new file mode 100644 index 00000000..7246475a --- /dev/null +++ b/_build/static/archives/extend/attachments/20121030/3de26c28/attachment.html @@ -0,0 +1,9 @@ + +<div>Hi everyone, newb questions here:</div><div><br></div><div>Is the reason why the type specification for the init callback lists various "<span class="p" style="margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:16px;white-space:pre">{</span><span class="n" style="margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:16px;white-space:pre">loop</span><span class="p" style="margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:16px;white-space:pre">,..." </span><font face="arial, helvetica, sans-serif"><span class="p" style="margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-size:12px;line-height:16px;white-space:pre">tuples, because a single module can implement cowboy_loop_handler and cowboy_http_handler?</span></font></div>
+<div><font face="arial, helvetica, sans-serif"><span class="p" style="margin:0px;padding:0px;border:0px;color:rgb(51,51,51);font-size:12px;line-height:16px;white-space:pre">And this way, a dializier warning will not be triggered?</span><span style="color:rgb(51,51,51);font-size:12px;line-height:16px;white-space:pre;background-color:rgb(255,255,204)"> </span></font></div>
+<a href="https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39">https://github.com/extend/cowboy/blob/master/src/cowboy_http_handler.erl#L39</a><div><br></div><div>Because looking at the handler code,<a href="https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473">https://github.com/extend/cowboy/blob/master/src/cowboy_protocol.erl#L473</a>if the {loop, * is returned from init, then the<font face="arial, helvetica, sans-serif"><span class="nf" style="font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px;color:rgb(153,0,0);font-weight:bold">handle</span><span class="p" style="color:rgb(51,51,51);font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px">(</span><span class="nv" style="font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px;color:rgb(0,128,128)">Req</span><span class="p" style="color:rgb(51,51,51);font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px">,</span><span style="background-color:rgb(248,248,248);color:rgb(51,51,51);font-size:13px;line-height:19px"> </span><span class="nv" style="font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px;color:rgb(0,128,128)">State</span><span class="p" style="color:rgb(51,51,51);font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px">) will not be processed.</span></font></div>
+<div><span class="p" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px"><br></span></div><div><span class="p" style="color:rgb(51,51,51);font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px"><font face="arial, helvetica, sans-serif">Also, is it safe to say that Handler:init is like "before" in lot's of web frameworks. I can place validation\authentication logic there.</font></span></div>
+<div><span class="p" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:13px;line-height:19px;margin:0px;padding:0px;border:0px"><br></span></div><div>Sincerely,</div><div>
+<br></div><div>-rambocoder</div>
+ + diff --git a/_build/static/archives/extend/attachments/20121216/2d0b0da5/attachment.html b/_build/static/archives/extend/attachments/20121216/2d0b0da5/attachment.html new file mode 100644 index 00000000..982e5a1e --- /dev/null +++ b/_build/static/archives/extend/attachments/20121216/2d0b0da5/attachment.html @@ -0,0 +1,25 @@ + +See you there!<div><br></div><div>Jeremy (banachtarski)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 16, 2012 at 10:24 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
+<br>
+I have started the #ninenines IRC Channel on <a href="http://irc.freenode.net" target="_blank">irc.freenode.net</a> for anyone looking for quick help or willing to participate in Cowboy development or any other related project (Ranch, Bullet, Sheriff and upcoming projects).<br>
+
+<br>
+Discussions will be centered about these projects and related subjects.<br>
+<br>
+Repositories will soon be updated with information about this IRC channel.<br>
+<br>
+Feel free to come and hang out.<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20121220/631f7f13/attachment.html b/_build/static/archives/extend/attachments/20121220/631f7f13/attachment.html new file mode 100644 index 00000000..78784c07 --- /dev/null +++ b/_build/static/archives/extend/attachments/20121220/631f7f13/attachment.html @@ -0,0 +1,6 @@ + +Does anybody know either from benchmarks or real world data what is the average memory footprint of each concurrent HTTPS connection to cowboy?<div><br></div><div>SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache Bench I test with reuses the session id or it does not.</div>
+<div><br></div><div>BTW, what makes an erlang api "documented" vs "undocumented". For example ssl:session_info/1 function here ( <a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411">https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411</a> ) has a spec and a short doc, but session_info is not described<a href="http://www.erlang.org/doc/man/ssl.html">http://www.erlang.org/doc/man/ssl.html</a> .ssl:session_info/1 is a useful function to be able to track if the load generator is reusing the SSL session_id or it is generating new one, because that would make all the difference during measurement due to Erlang caching SSL sessions by default.</div>
+<div><br></div><div>Sincerely,</div><div><br></div><div>rambocoder</div>
+ + diff --git a/_build/static/archives/extend/attachments/20121221/8bfb2f11/attachment.html b/_build/static/archives/extend/attachments/20121221/8bfb2f11/attachment.html new file mode 100644 index 00000000..9650a876 --- /dev/null +++ b/_build/static/archives/extend/attachments/20121221/8bfb2f11/attachment.html @@ -0,0 +1,44 @@ + +In my preliminary testing, I used Jmeter this morning since it's an easy GUI load testing app and this is what I am seeing:<div><br></div><div>With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true], when I establish 1K concurrent connections via HTTPS, each connection takes up about 68K of memory.<br>
+<div><br></div><div>Unfortunately, after about 1050-1200 connections, on my test server the Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers, while up to that point the scheduler's load was oscillating up and down. Using the Observer, there is only 1 ssl_connection_sup  in the ssl application, having to deal with 1000+ gen_fsm workers, so that might be the bottleneck. Since the ulimit on my server is 50000 I don't think I am hitting any type of file handler's limit.</div>
+<div><br></div><div>Loïc and the group, am I missing some setting that is causing the scheduler to go to 100% CPU and the run que in observer to be 99?</div><div><br></div><div><table cellpadding="0" class="cf an5" id=":zc" style="border-collapse:collapse;outline:none;overflow:hidden;table-layout:fixed;width:202px;color:rgb(34,34,34);font-family:arial,sans-serif;text-align:start;background-color:rgb(255,255,255)">
+<tbody><tr><td class="anQ" style="margin:0px;overflow:hidden;text-overflow:ellipsis;vertical-align:top">Sincerely,<br><br>rambocoder</td></tr></tbody></table></div><div><br><br><div class="gmail_quote">On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 12/21/2012 04:34 AM, rambocoder wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Does anybody know either from benchmarks or real world data what is the<br>
+average memory footprint of each concurrent HTTPS connection to cowboy?<br>
+</blockquote>
+<br></div>
+I don't have anything, sorry. I'm guessing it consumes a lot more than TCP though.<div class="im"><br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+SSL app in Erlang reuses SSL session-ids so I am not sure if the Apache<br>
+Bench I test with reuses the session id or it does not.<br>
+</blockquote>
+<br></div>
+I wouldn't know, but I wouldn't trust Apache Bench doing the right thing. Any other benchmark tool usually works better in my experience.<div class="im"><br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+BTW, what makes an erlang api "documented" vs "undocumented". For<br>
+example ssl:session_info/1 function here (<br>
+<a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411" target="_blank">https://github.com/erlang/otp/<u></u>blob/maint/lib/ssl/src/ssl.<u></u>erl#L411</a> ) has<br>
+a spec and a short doc, but session_info is not described<br>
+<a href="http://www.erlang.org/doc/man/ssl.html" target="_blank">http://www.erlang.org/doc/man/<u></u>ssl.html</a> .ssl:session_info/1 is a useful<br>
+function to be able to track if the load generator is reusing the SSL<br>
+session_id or it is generating new one, because that would make all the<br>
+difference during measurement due to Erlang caching SSL sessions by default.<br>
+</blockquote>
+<br></div>
+The documentation is separate (they're not using edoc). It's perhaps not deemed useful enough for documenting it. I wouldn't worry about using it for measurements though.<br>
+<br>
+Try asking Ingela on the ML about it, perhaps they just forgot to document it.<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+</font></span></blockquote></div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20121221/945f636e/attachment.html b/_build/static/archives/extend/attachments/20121221/945f636e/attachment.html new file mode 100644 index 00000000..e10a9807 --- /dev/null +++ b/_build/static/archives/extend/attachments/20121221/945f636e/attachment.html @@ -0,0 +1,108 @@ + +Long story short, I solved the problem by adding {max_connections, 50000} to cowboy:start_https because it default to 1024 at <a href="https://github.com/extend/ranch/blob/master/src/ranch_listener_sup.erl#L30">https://github.com/extend/ranch/blob/master/src/ranch_listener_sup.erl#L30</a><div>
+<br></div><div>However, before I figured out that setting, I did run eprof and these are the function calls it was spending most of it's time on<br><div><div><br></div><div><br></div><div><div>FUNCTION                                    CALLS      %   TIME  [uS / CALLS]</div>
+<div>--------                                    -----    ---   ----  [----------]</div></div><div>dict:get_slot/2                               174   1.73   1658  [      9.53]</div><div><div>dict:on_bucket/3                              171   1.77   1701  [      9.95]</div>
+<div>erlang:setelement/3                           684   3.23   3098  [      4.53]</div><div>dict:store_bkt_val/3                          600   5.24   5028  [      8.38]</div><div><br></div><div>Then I ran etop and it showed that ranch_acceptor:maybe_wait had the most reductions were, so I looked at the code in that <a href="https://github.com/extend/ranch/blob/master/src/ranch_acceptor.erl#L72">https://github.com/extend/ranch/blob/master/src/ranch_acceptor.erl#L72</a> and realized that like a newb I did not set the maximum connections for the listener :)</div>
+<div><br></div><div>Problem solved. Looks like I won't need to put HAProxy in front of Cowboy after all.</div><div><br></div><div>Thank you,</div><div><br></div><div>rambocoder</div><br><div class="gmail_quote">On Fri, Dec 21, 2012 at 11:51 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Can you try enabling eprof to see where the VM spends its time?<div class="im"><br>
+<br>
+On 12/21/2012 05:49 PM, rambocoder wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+In my preliminary testing, I used Jmeter this morning since it's an<br>
+easy GUI load testing app and this is what I am seeing:<br>
+<br>
+With R15B03-01 [smp:4:4] [async-threads:4] [hipe] [kernel-poll:true],<br>
+when I establish 1K concurrent connections via HTTPS, each connection<br>
+takes up about 68K of memory.<br>
+<br>
+Unfortunately, after about 1050-1200 connections, on my test server the<br>
+Erlang scheduler jumps to 100% CPU utilization on all 4 schedulers,<br>
+while up to that point the scheduler's load was oscillating up and down.<br>
+Using the Observer, there is only 1 ssl_connection_sup  in the ssl<br>
+application, having to deal with 1000+ gen_fsm workers, so that might be<br>
+the bottleneck. Since the ulimit on my server is 50000 I don't think I<br>
+am hitting any type of file handler's limit.<br>
+<br>
+Loïc and the group, am I missing some setting that is causing the<br>
+scheduler to go to 100% CPU and the run que in observer to be 99?<br>
+<br>
+Sincerely,<br>
+<br>
+rambocoder<br>
+<br>
+<br>
+<br>
+On Fri, Dec 21, 2012 at 6:45 AM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="im">
+<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
+<br>
+    On 12/21/2012 04:34 AM, rambocoder wrote:<br>
+<br>
+        Does anybody know either from benchmarks or real world data what<br>
+        is the<br>
+        average memory footprint of each concurrent HTTPS connection to<br>
+        cowboy?<br>
+<br>
+<br>
+    I don't have anything, sorry. I'm guessing it consumes a lot more<br>
+    than TCP though.<br>
+<br>
+<br>
+        SSL app in Erlang reuses SSL session-ids so I am not sure if the<br>
+        Apache<br>
+        Bench I test with reuses the session id or it does not.<br>
+<br>
+<br>
+    I wouldn't know, but I wouldn't trust Apache Bench doing the right<br>
+    thing. Any other benchmark tool usually works better in my experience.<br>
+<br>
+<br>
+        BTW, what makes an erlang api "documented" vs "undocumented". For<br>
+        example ssl:session_info/1 function here (<br></div>
+        <a href="https://github.com/erlang/otp/__blob/maint/lib/ssl/src/ssl.__erl#L411" target="_blank">https://github.com/erlang/otp/<u></u>__blob/maint/lib/ssl/src/ssl._<u></u>_erl#L411</a><div class="im"><br>
+        <<a href="https://github.com/erlang/otp/blob/maint/lib/ssl/src/ssl.erl#L411" target="_blank">https://github.com/erlang/<u></u>otp/blob/maint/lib/ssl/src/<u></u>ssl.erl#L411</a>><br>
+        ) has<br>
+        a spec and a short doc, but session_info is not described<br></div>
+        <a href="http://www.erlang.org/doc/man/__ssl.html" target="_blank">http://www.erlang.org/doc/man/<u></u>__ssl.html</a><div class="im"><br>
+        <<a href="http://www.erlang.org/doc/man/ssl.html" target="_blank">http://www.erlang.org/doc/<u></u>man/ssl.html</a>> .ssl:session_info/1 is<br>
+        a useful<br>
+        function to be able to track if the load generator is reusing<br>
+        the SSL<br>
+        session_id or it is generating new one, because that would make<br>
+        all the<br>
+        difference during measurement due to Erlang caching SSL sessions<br>
+        by default.<br>
+<br>
+<br>
+    The documentation is separate (they're not using edoc). It's perhaps<br>
+    not deemed useful enough for documenting it. I wouldn't worry about<br>
+    using it for measurements though.<br>
+<br>
+    Try asking Ingela on the ML about it, perhaps they just forgot to<br>
+    document it.<br>
+<br>
+    --<br>
+    Loďc Hoguin<br>
+    Erlang Cowboy<br>
+    Nine Nines<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+<br>
+<br></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loïc Hoguin</font></span><div class="HOEnZb"><div class="h5"><br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+</div></div></blockquote></div><br></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130103/bae06e70/attachment.html b/_build/static/archives/extend/attachments/20130103/bae06e70/attachment.html new file mode 100644 index 00000000..d8306a06 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130103/bae06e70/attachment.html @@ -0,0 +1,54 @@ + +Loic, it would be great to hear a bit, what problems have you met with.<div><br></div><div>What issues with stability can be in acceptor pool?</div><div><br></div><div>Also I have question about updating protocol options: have you done something with the problem that after updating protocol options existing workers are running with old config?<span></span><br>
+<br>On Tuesday, December 25, 2012, Loïc Hoguin  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ho ho ho!<br>
+<br>
+I have just tagged version 0.6.0 of the Ranch project!<br>
+<br>
+Ranch is a socket acceptor pool for TCP protocols.<br>
+<br>
+  <a href="https://github.com/extend/ranch" target="_blank">https://github.com/extend/<u></u>ranch</a><br>
+<br>
+Ranch is used by the next version of Cowboy, 0.8.0, set to be released early February, but also in Basho's Riak multi-data center replication amongst others.<br>
+<br>
+All tickets have been resolved. A significant contribution was made by Andrew Majorov to improve the fault tolerance capabilities of the application, making sure it always restarts properly when things go wrong. This has been made possible thanks to the amazing project from Daniel Luna, chaos_monkey (<a href="https://github.com/dluna/chaos_monkey" target="_blank">https://github.com/dluna/<u></u>chaos_monkey</a>).<br>
+
+<br>
+The guide has also been improved and completed.<br>
+<br>
+  <a href="http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/<u></u>ranch/HEAD/guide/introduction</a><br>
+<br>
+If the guide isn't enough, drop by our new IRC channel dedicated to Cowboy, Ranch and all our other projects! #ninenines on Freenode.<br>
+<br>
+Following is the list of change since last time:<br>
+<br>
+ *  Improve fault tolerance thanks to chaos_monkey testing<br>
+ *  Add 'nodelay' option to transports<br>
+ *  Add 'verify' option to ranch_ssl transport<br>
+ *  Add 'socket' option to pass an already open socket to the listener<br>
+ *  Add Transport:sendfile/2 function (uses a fallback if unavailable)<br>
+ *  Allow IP tuples in Transport:connect/3<br>
+ *  Add ranch:set_max_connections/2 to update the value live<br>
+ *  Add ranch:get_max_connections/1 to retrieve it<br>
+<br>
+We are always looking for feedback, especially now that there is no ticket left open on this project. If you are using Ranch and have questions or needs that it doesn't cover, please send them to us.<br>
+<br>
+Commercial support will be available starting from January, ping me if you are interested. Details will be announced at a later time on the <a href="http://ninenines.eu" target="_blank">ninenines.eu</a> mailing list.<br>
+
+<br>
+I want to thank all contributors for helping this project by opening tickets, sending patches and offering feedback. I am as always very grateful for any and all contributions. I wouldn't have made it this far without the tremendous help I receive everyday.<br>
+
+<br>
+Thanks to all and have a nice holiday!<br>
+<br>
+-- <br>
+Loïc Hoguin<br>
+Erlang Santa<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a>erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</blockquote></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130103/d9dbc1a5/attachment.html b/_build/static/archives/extend/attachments/20130103/d9dbc1a5/attachment.html new file mode 100644 index 00000000..7a05b607 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130103/d9dbc1a5/attachment.html @@ -0,0 +1,157 @@ + +<div dir="ltr">ok<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 5:51 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Existing acceptors were using the old options for the next connection and then switched to the new options. But that has been fixed a long time ago. Ranch doesn't have that issue.<div class="im">
+<br>
+<br>
+On 01/03/2013 02:32 PM, Max Lapshin wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+I mean situation that after cowboy:update_options existing acceptors are<br>
+still working with old routes.<br>
+Currently it is useless API, so I have to stop cowboy and start it back.<br>
+<br>
+<br>
+On Thu, Jan 3, 2013 at 4:46 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="im">
+<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
+<br>
+    Haven't had any stability issue. What we did here is ensure that<br>
+    when any process gets killed for any reason, especially reasons we<br>
+    can't foresee, Ranch continues to work as expected.<br>
+<br>
+    Ranch not updating protocol options for existing connections isn't a<br>
+    problem, it won't be "fixed". Ranch can't guess how connection<br>
+    processes are implemented. It's up to you to allow this if you need<br>
+    it. The upgrade updates the options for all acceptors and all future<br>
+    connections, that's it.<br>
+<br>
+<br>
+    On 01/03/2013 10:30 AM, Max Lapshin wrote:<br>
+<br>
+        Loic, it would be great to hear a bit, what problems have you<br>
+        met with.<br>
+<br>
+        What issues with stability can be in acceptor pool?<br>
+<br>
+        Also I have question about updating protocol options: have you done<br>
+        something with the problem that after updating protocol options<br>
+        existing<br>
+        workers are running with old config?<br>
+<br>
+        On Tuesday, December 25, 2012, Loïc Hoguin wrote:<br>
+<br>
+             Ho ho ho!<br>
+<br>
+             I have just tagged version 0.6.0 of the Ranch project!<br>
+<br>
+             Ranch is a socket acceptor pool for TCP protocols.<br>
+<br></div>
+        <a href="https://github.com/extend/____ranch" target="_blank">https://github.com/extend/____<u></u>ranch</a><br>
+        <<a href="https://github.com/extend/__ranch" target="_blank">https://github.com/extend/__<u></u>ranch</a>><div class="im"><br>
+        <<a href="https://github.com/extend/__ranch" target="_blank">https://github.com/extend/__<u></u>ranch</a><br>
+        <<a href="https://github.com/extend/ranch" target="_blank">https://github.com/extend/<u></u>ranch</a>>><br>
+<br>
+<br>
+             Ranch is used by the next version of Cowboy, 0.8.0, set to be<br>
+             released early February, but also in Basho's Riak<br>
+        multi-data center<br>
+             replication amongst others.<br>
+<br>
+             All tickets have been resolved. A significant contribution<br>
+        was made<br>
+             by Andrew Majorov to improve the fault tolerance<br>
+        capabilities of the<br>
+             application, making sure it always restarts properly when<br>
+        things go<br>
+             wrong. This has been made possible thanks to the amazing<br>
+        project<br>
+             from Daniel Luna, chaos_monkey<br></div>
+             (<a href="https://github.com/dluna/____chaos_monkey" target="_blank">https://github.com/dluna/____<u></u>chaos_monkey</a><br>
+        <<a href="https://github.com/dluna/__chaos_monkey" target="_blank">https://github.com/dluna/__<u></u>chaos_monkey</a>><div class="im"><br>
+             <<a href="https://github.com/dluna/__chaos_monkey" target="_blank">https://github.com/dluna/__<u></u>chaos_monkey</a><br>
+        <<a href="https://github.com/dluna/chaos_monkey" target="_blank">https://github.com/dluna/<u></u>chaos_monkey</a>>>).<br>
+<br>
+<br>
+             The guide has also been improved and completed.<br>
+<br></div>
+        <a href="http://ninenines.eu/docs/en/____ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/__<u></u>__ranch/HEAD/guide/<u></u>introduction</a><br>
+        <<a href="http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/_<u></u>_ranch/HEAD/guide/introduction</a><u></u>><div><div class="h5"><br>
+<br>
+<br>
+        <<a href="http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/_<u></u>_ranch/HEAD/guide/introduction</a><br>
+        <<a href="http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/<u></u>ranch/HEAD/guide/introduction</a>><u></u>><br>
+<br>
+             If the guide isn't enough, drop by our new IRC channel<br>
+        dedicated to<br>
+             Cowboy, Ranch and all our other projects! #ninenines on<br>
+        Freenode.<br>
+<br>
+             Following is the list of change since last time:<br>
+<br>
+               *  Improve fault tolerance thanks to chaos_monkey testing<br>
+               *  Add 'nodelay' option to transports<br>
+               *  Add 'verify' option to ranch_ssl transport<br>
+               *  Add 'socket' option to pass an already open socket to<br>
+        the listener<br>
+               *  Add Transport:sendfile/2 function (uses a fallback if<br>
+        unavailable)<br>
+               *  Allow IP tuples in Transport:connect/3<br>
+               *  Add ranch:set_max_connections/2 to update the value live<br>
+               *  Add ranch:get_max_connections/1 to retrieve it<br>
+<br>
+             We are always looking for feedback, especially now that<br>
+        there is no<br>
+             ticket left open on this project. If you are using Ranch<br>
+        and have<br>
+             questions or needs that it doesn't cover, please send them<br>
+        to us.<br>
+<br>
+             Commercial support will be available starting from January,<br>
+        ping me<br>
+             if you are interested. Details will be announced at a later<br>
+        time on<br>
+             the <a href="http://ninenines.eu" target="_blank">ninenines.eu</a> <<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>><br>
+        <<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>> mailing list.<br>
+<br>
+<br>
+             I want to thank all contributors for helping this project<br>
+        by opening<br>
+             tickets, sending patches and offering feedback. I am as<br>
+        always very<br>
+             grateful for any and all contributions. I wouldn't have<br>
+        made it this<br>
+             far without the tremendous help I receive everyday.<br>
+<br>
+             Thanks to all and have a nice holiday!<br>
+<br>
+             --<br>
+             Loïc Hoguin<br>
+             Erlang Santa<br>
+             Nine Nines<br>
+        <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br></div></div>
+             ______________________________<u></u>_____________________<br>
+             erlang-questions mailing list<br>
+        <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a> <mailto:<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@<u></u>erlang.org</a>><br>
+        <a href="http://erlang.org/mailman/____listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/____<u></u>listinfo/erlang-questions</a><br>
+        <<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a>><div class="im"><br>
+             <<a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
+        <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>>><br>
+<br>
+<br>
+<br>
+    --<br>
+    Loïc Hoguin<br>
+    Erlang Cowboy<br>
+    Nine Nines<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+</div></blockquote><div class="HOEnZb"><div class="h5">
+<br>
+<br>
+-- <br>
+Loïc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130103/f6c7fd25/attachment.html b/_build/static/archives/extend/attachments/20130103/f6c7fd25/attachment.html new file mode 100644 index 00000000..e86b276c --- /dev/null +++ b/_build/static/archives/extend/attachments/20130103/f6c7fd25/attachment.html @@ -0,0 +1,97 @@ + +<div dir="ltr"><div>I mean situation that after cowboy:update_options existing acceptors are still working with old routes.<br></div>Currently it is useless API, so I have to stop cowboy and start it back.<br></div><div class="gmail_extra">
+<br><br><div class="gmail_quote">On Thu, Jan 3, 2013 at 4:46 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Haven't had any stability issue. What we did here is ensure that when any process gets killed for any reason, especially reasons we can't foresee, Ranch continues to work as expected.<br>
+<br>
+Ranch not updating protocol options for existing connections isn't a problem, it won't be "fixed". Ranch can't guess how connection processes are implemented. It's up to you to allow this if you need it. The upgrade updates the options for all acceptors and all future connections, that's it.<div class="im">
+<br>
+<br>
+On 01/03/2013 10:30 AM, Max Lapshin wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+Loic, it would be great to hear a bit, what problems have you met with.<br>
+<br>
+What issues with stability can be in acceptor pool?<br>
+<br>
+Also I have question about updating protocol options: have you done<br>
+something with the problem that after updating protocol options existing<br>
+workers are running with old config?<br>
+<br>
+On Tuesday, December 25, 2012, Loïc Hoguin wrote:<br>
+<br>
+    Ho ho ho!<br>
+<br>
+    I have just tagged version 0.6.0 of the Ranch project!<br>
+<br>
+    Ranch is a socket acceptor pool for TCP protocols.<br>
+<br></div>
+    <a href="https://github.com/extend/__ranch" target="_blank">https://github.com/extend/__<u></u>ranch</a> <<a href="https://github.com/extend/ranch" target="_blank">https://github.com/extend/<u></u>ranch</a>><div class="im">
+<br>
+<br>
+    Ranch is used by the next version of Cowboy, 0.8.0, set to be<br>
+    released early February, but also in Basho's Riak multi-data center<br>
+    replication amongst others.<br>
+<br>
+    All tickets have been resolved. A significant contribution was made<br>
+    by Andrew Majorov to improve the fault tolerance capabilities of the<br>
+    application, making sure it always restarts properly when things go<br>
+    wrong. This has been made possible thanks to the amazing project<br>
+    from Daniel Luna, chaos_monkey<br></div>
+    (<a href="https://github.com/dluna/__chaos_monkey" target="_blank">https://github.com/dluna/__<u></u>chaos_monkey</a><br>
+    <<a href="https://github.com/dluna/chaos_monkey" target="_blank">https://github.com/dluna/<u></u>chaos_monkey</a>>).<div class="im"><br>
+<br>
+    The guide has also been improved and completed.<br>
+<br></div>
+    <a href="http://ninenines.eu/docs/en/__ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/__<u></u>ranch/HEAD/guide/introduction</a><div class="im"><br>
+    <<a href="http://ninenines.eu/docs/en/ranch/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/<u></u>ranch/HEAD/guide/introduction</a>><br>
+<br>
+    If the guide isn't enough, drop by our new IRC channel dedicated to<br>
+    Cowboy, Ranch and all our other projects! #ninenines on Freenode.<br>
+<br>
+    Following is the list of change since last time:<br>
+<br>
+      *  Improve fault tolerance thanks to chaos_monkey testing<br>
+      *  Add 'nodelay' option to transports<br>
+      *  Add 'verify' option to ranch_ssl transport<br>
+      *  Add 'socket' option to pass an already open socket to the listener<br>
+      *  Add Transport:sendfile/2 function (uses a fallback if unavailable)<br>
+      *  Allow IP tuples in Transport:connect/3<br>
+      *  Add ranch:set_max_connections/2 to update the value live<br>
+      *  Add ranch:get_max_connections/1 to retrieve it<br>
+<br>
+    We are always looking for feedback, especially now that there is no<br>
+    ticket left open on this project. If you are using Ranch and have<br>
+    questions or needs that it doesn't cover, please send them to us.<br>
+<br>
+    Commercial support will be available starting from January, ping me<br>
+    if you are interested. Details will be announced at a later time on<br></div>
+    the <a href="http://ninenines.eu" target="_blank">ninenines.eu</a> <<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>> mailing list.<div class="im"><br>
+<br>
+    I want to thank all contributors for helping this project by opening<br>
+    tickets, sending patches and offering feedback. I am as always very<br>
+    grateful for any and all contributions. I wouldn't have made it this<br>
+    far without the tremendous help I receive everyday.<br>
+<br>
+    Thanks to all and have a nice holiday!<br>
+<br>
+    --<br>
+    Loïc Hoguin<br>
+    Erlang Santa<br>
+    Nine Nines<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br></div>
+    ______________________________<u></u>___________________<br>
+    erlang-questions mailing list<br>
+    <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+    <a href="http://erlang.org/mailman/__listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/__<u></u>listinfo/erlang-questions</a><br>
+    <<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a>><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loïc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130117/19bfde40/attachment.html b/_build/static/archives/extend/attachments/20130117/19bfde40/attachment.html new file mode 100644 index 00000000..7bed6877 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130117/19bfde40/attachment.html @@ -0,0 +1,20 @@ + +<div dir="ltr">Thanks<font face="arial, sans-serif"><span style="white-space:nowrap">Loc!</span></font></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 17, 2013 at 10:33 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Short, quick and semi-private announcement: Ranch 0.6.1 has been tagged.<br>
+<br>
+It includes a few guide updates, the addition of the raw option for specifying platform-specific socket options, and performance improvements when using the {max_connections, infinity} option.<br>
+<br>
+Enjoy!<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130125/7d0820aa/attachment.html b/_build/static/archives/extend/attachments/20130125/7d0820aa/attachment.html new file mode 100644 index 00000000..53a6c745 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130125/7d0820aa/attachment.html @@ -0,0 +1,35 @@ + +Hi Loic,<div><br></div><div>I'd like to send feedback very much. But right now Cowboy is just used as demo in my company --- BesTV (<a href="http://www.bestv.com.cn">www.bestv.com.cn</a>), which is the largest IPTV and intenetTV operator in China. Although I think Cowby is good, the production environment is still dominated by Java and mainstream HTTP servers. Because I'm from Ericsson, I hope to promote Erlang here but it's not so easy. I would send the data if Cowboy would be used in production and fully tested.</div>
+<div><br></div><div>Thank you!</div><div>Barco<br><br><div class="gmail_quote">On Fri, Jan 25, 2013 at 5:23 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
+<br>
+I'm looking into perhaps starting a project related to Cowboy and could use some feedback from users, particularly in the realm of numbers.<br>
+<br>
+If you use Cowboy and have it in production where:<br>
+<br>
+* Latency is vital<br>
+* Throughput is vital<br>
+* Concurrent number of connections is huge<br>
+* Load is huge (or would be with another solution)<br>
+<br>
+Then I'd like to hear from you!<br>
+<br>
+Please send me average numbers, statistics, graphs or anything where I can see how well it performs for you! In private if you prefer. Tell me if I can quote you or your company about it. Please answer even if we briefly discussed it in the past.<br>
+
+<br>
+(If you found that it didn't perform enough for your needs you should probably open a ticket, or, if you can't, send me a private email.)<br>
+<br>
+Looking forward to the feedback. Thanks!<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130204/3c258140/attachment.html b/_build/static/archives/extend/attachments/20130204/3c258140/attachment.html new file mode 100644 index 00000000..4bf7a15b --- /dev/null +++ b/_build/static/archives/extend/attachments/20130204/3c258140/attachment.html @@ -0,0 +1,20 @@ + +<div dir="ltr">It is rebar compatible<div><br></div><div><a href="https://github.com/extend/cowboy/blob/master/rebar.config">https://github.com/extend/cowboy/blob/master/rebar.config</a><br></div><div><br></div><div style>
+I use it with rebar all the time.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 24, 2013 at 2:41 PM, Grzegorz Junka <span dir="ltr"><<a href="mailto:list1@gjunka.com" target="_blank">list1@gjunka.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
+I understand the move away from Rebar but I'd like to see the project to be still Rebar-compatible. Would that be a problem? Mainly I am thinking about dependencies. The Cowboy Makefile assumes that Ranch is in its deps folder. If Cowboy is a part of a bigger application, and most often it will be in such a role rather than a standalone application, then all dependencies should be kept in one place. In that case it would be the main project's deps folder, not Cowboy's deps folder. Can the compilation process be split into compiling Cowboy dependencies separately from Cowboy itself?<br>
+
+<br>
+something like:<br>
+<br>
+all: compile-deps compile-cowboy<br>
+<br>
+Then if Cowboy is a dependency itself it may be just compiled without the dependency (as it will be compiled when the main project is compiled).<br>
+<br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130204/c34e6aa6/attachment.html b/_build/static/archives/extend/attachments/20130204/c34e6aa6/attachment.html new file mode 100644 index 00000000..723b1717 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130204/c34e6aa6/attachment.html @@ -0,0 +1,79 @@ + +<html>
+  <head>
+    <meta content="text/html; charset=ISO-8859-1"
+      http-equiv="Content-Type">
+  </head>
+  <body text="#000000" bgcolor="#FFFFFF">
+    <div class="moz-cite-prefix">
+      <pre><div class="line" id="LC32">deps/ranch:</div><div class="line" id="LC33">    @mkdir -p <span class="k">$(</span>DEPS_DIR<span class="k">)</span></div><div class="line" id="LC34">       git clone -n -- <a class="moz-txt-link-freetext" href="https://github.com/extend/ranch.git">https://github.com/extend/ranch.git</a> <span class="k">$(</span>DEPS_DIR<span class="k">)</span>/ranch</div><div class="line" id="LC35">       <span class="nb">cd</span> <span class="k">$(</span>DEPS_DIR<span class="k">)</span>/ranch ; git checkout -q <span class="k">$(</span>RANCH_VSN<span class="k">)</span></div></pre>
+      <br>
+      Am I to understand that the only way of having the dependencies in
+      another folder than cowboy/deps is to use Rebar (e.g. if compiling
+      using the makefile it will always assume that dependencies are in
+      local deps folder)?<br>
+      <br>
+      Would be good to have a target to compile cowboy without
+      dependencies.<br>
+      <br>
+      <br>
+      On 04/02/2013 20:10, Jeremy Ong wrote:<br>
+    </div>
+    <blockquote
+cite="mid:CAKD1GY7+fvMOR6PhOz=QGAi8r2T_Obf4gCjaH4hN_=J+hNyw4w@mail.gmail.com"
+      type="cite">
+      <div dir="ltr">It is rebar compatible
+        <div><br>
+        </div>
+        <div><a moz-do-not-send="true"
+            href="https://github.com/extend/cowboy/blob/master/rebar.config">https://github.com/extend/cowboy/blob/master/rebar.config</a><br>
+        </div>
+        <div><br>
+        </div>
+        <div style="">
+          I use it with rebar all the time.</div>
+      </div>
+      <div class="gmail_extra"><br>
+        <br>
+        <div class="gmail_quote">On Thu, Jan 24, 2013 at 2:41 PM,
+          Grzegorz Junka <span dir="ltr"><<a moz-do-not-send="true"
+              href="mailto:list1@gjunka.com" target="_blank">list1@gjunka.com</a>></span>
+          wrote:<br>
+          <blockquote class="gmail_quote" style="margin:0 0 0
+            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
+            I understand the move away from Rebar but I'd like to see
+            the project to be still Rebar-compatible. Would that be a
+            problem? Mainly I am thinking about dependencies. The Cowboy
+            Makefile assumes that Ranch is in its deps folder. If Cowboy
+            is a part of a bigger application, and most often it will be
+            in such a role rather than a standalone application, then
+            all dependencies should be kept in one place. In that case
+            it would be the main project's deps folder, not Cowboy's
+            deps folder. Can the compilation process be split into
+            compiling Cowboy dependencies separately from Cowboy itself?<br>
+            <br>
+            something like:<br>
+            <br>
+            all: compile-deps compile-cowboy<br>
+            <br>
+            Then if Cowboy is a dependency itself it may be just
+            compiled without the dependency (as it will be compiled when
+            the main project is compiled).<br>
+            <br>
+            _______________________________________________<br>
+            Extend mailing list<br>
+            <a moz-do-not-send="true"
+              href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+            <a moz-do-not-send="true"
+              href="http://lists.ninenines.eu:81/listinfo/extend"
+              target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+          </blockquote>
+        </div>
+        <br>
+      </div>
+    </blockquote>
+    <br>
+  </body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130210/1b9560c2/attachment.html b/_build/static/archives/extend/attachments/20130210/1b9560c2/attachment.html new file mode 100644 index 00000000..3050d08f --- /dev/null +++ b/_build/static/archives/extend/attachments/20130210/1b9560c2/attachment.html @@ -0,0 +1,6 @@ + +<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi,<div><br></div><div> I'm playing around with a middleware and request/responsehooks. A couple of questions that have surfaced:</div><div>* Say I map a module to "/my/path[...]" and then curl "/my/path/even/more/stuff". Is there a way to retrieve the "rest" of the matched path, i.e. like cowboy_req:path_info/1 but just the rest, not the total path. The result I want is: [<<"even">>, <<"more">>, <<"stuff">>].</div><div>* I've been trying to use a responsehook to ensure that a default content-type is set if none is specified. Been trying with cowboy_req:reply, coboy_req:set_resp_headers, etc. It doesn't seem to work that well. What's the preferred way?<br><div apple-content-edited="true">
+<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Regards,</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">-Bip Thelin</div></span></div></span></div></span>
+</div>
+<br></div></body></html> + diff --git a/_build/static/archives/extend/attachments/20130212/09008370/attachment.html b/_build/static/archives/extend/attachments/20130212/09008370/attachment.html new file mode 100644 index 00000000..c0fae195 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130212/09008370/attachment.html @@ -0,0 +1,48 @@ + +<div dir="ltr">Congrats!</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 9:36 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello there!<br>
+<br>
+Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, REST and Websocket server.<br>
+<br>
+ <a href="https://github.com/extend/cowboy/" target="_blank">https://github.com/extend/<u></u>cowboy/</a><br>
+<br>
+The number of contributors who helped make this release considerably increased. Cowboy is available thanks to the code contributions from 50 users, double from the last release where 25 contributed.<br>
+<br>
+The number of users has also greatly increased. Cowboy is being used in ad bidding, set-top boxes, live TV events, content streaming services, and many more exciting areas.<br>
+<br>
+This new version has many highlights. You can take a look at the changelog for detailed information about the many changes.<br>
+<br>
+ <a href="https://github.com/extend/cowboy/blob/master/CHANGELOG.md" target="_blank">https://github.com/extend/<u></u>cowboy/blob/master/CHANGELOG.<u></u>md</a><br>
+<br>
+Cowboy scalability has been greatly improved in this version. This has been observed many times in production, including in the AdGear Tracker project (<a href="http://ferd.ca/rtb-where-erlang-blooms.html" target="_blank">http://ferd.ca/rtb-where-<u></u>erlang-blooms.html</a>) where updated nodes were able to handle 2 times more requests compared to older nodes. This improvement cannot be observed in "hello world" types of benchmarks. An article will soon be published to explain the reasons for this.<br>
+
+<br>
+Cowboy now features a brand new user guide. It is still a work in progress, so please open a ticket on Github if something is missing or incorrect.<br>
+<br>
+ <a href="http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/guide/introduction</a><br>
+<br>
+Remaining work before 1.0 include REST improvements and SPDY support. The rest of the API should now be very close to stable.<br>
+<br>
+I am looking for a good writer who would like to co-author a Cowboy book. The book will be accessible to people who don't know Erlang but will also contain everything there is to know about Cowboy, making it suitable for both beginners and experts. Contact me if you are interested.<br>
+
+<br>
+I now take donations in addition to commercial support options, to allow individual users to help the project stay alive and kicking.<br>
+<br>
+ <a href="http://ninenines.eu/support" target="_blank">http://ninenines.eu/support</a><br>
+<br>
+Hope you enjoy it. As always, please send me as much feedback as possible to help me improve things even more, preferrably through Github tickets if it's related to code or documentation.<br>
+<br>
+Thanks for reading.<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130212/dc0291b4/attachment.html b/_build/static/archives/extend/attachments/20130212/dc0291b4/attachment.html new file mode 100644 index 00000000..7bdbf15a --- /dev/null +++ b/_build/static/archives/extend/attachments/20130212/dc0291b4/attachment.html @@ -0,0 +1,4 @@ + +<div dir="ltr">Great, Loic.<br><br>As I've told already, it would be great to listen to your experience about issues that you meet on high loads: smooth scaling, predictionable behaviour of server, etc.<br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130213/41b12a6d/attachment.html b/_build/static/archives/extend/attachments/20130213/41b12a6d/attachment.html new file mode 100644 index 00000000..aa578a68 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130213/41b12a6d/attachment.html @@ -0,0 +1,50 @@ + +<p>Great news! </p>
+<p>Congrats! </p>
+<div class="gmail_quote">On Feb 12, 2013 11:36 AM, "Loc Hoguin" <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hello there!<br>
+<br>
+Cowboy 0.8 has been released. Cowboy is a small, fast and modular HTTP, REST and Websocket server.<br>
+<br>
+ <a href="https://github.com/extend/cowboy/" target="_blank">https://github.com/extend/<u></u>cowboy/</a><br>
+<br>
+The number of contributors who helped make this release considerably increased. Cowboy is available thanks to the code contributions from 50 users, double from the last release where 25 contributed.<br>
+<br>
+The number of users has also greatly increased. Cowboy is being used in ad bidding, set-top boxes, live TV events, content streaming services, and many more exciting areas.<br>
+<br>
+This new version has many highlights. You can take a look at the changelog for detailed information about the many changes.<br>
+<br>
+ <a href="https://github.com/extend/cowboy/blob/master/CHANGELOG.md" target="_blank">https://github.com/extend/<u></u>cowboy/blob/master/CHANGELOG.<u></u>md</a><br>
+<br>
+Cowboy scalability has been greatly improved in this version. This has been observed many times in production, including in the AdGear Tracker project (<a href="http://ferd.ca/rtb-where-erlang-blooms.html" target="_blank">http://ferd.ca/rtb-where-<u></u>erlang-blooms.html</a>) where updated nodes were able to handle 2 times more requests compared to older nodes. This improvement cannot be observed in "hello world" types of benchmarks. An article will soon be published to explain the reasons for this.<br>
+
+<br>
+Cowboy now features a brand new user guide. It is still a work in progress, so please open a ticket on Github if something is missing or incorrect.<br>
+<br>
+ <a href="http://ninenines.eu/docs/en/cowboy/HEAD/guide/introduction" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/guide/introduction</a><br>
+<br>
+Remaining work before 1.0 include REST improvements and SPDY support. The rest of the API should now be very close to stable.<br>
+<br>
+I am looking for a good writer who would like to co-author a Cowboy book. The book will be accessible to people who don't know Erlang but will also contain everything there is to know about Cowboy, making it suitable for both beginners and experts. Contact me if you are interested.<br>
+
+<br>
+I now take donations in addition to commercial support options, to allow individual users to help the project stay alive and kicking.<br>
+<br>
+ <a href="http://ninenines.eu/support" target="_blank">http://ninenines.eu/support</a><br>
+<br>
+Hope you enjoy it. As always, please send me as much feedback as possible to help me improve things even more, preferrably through Github tickets if it's related to code or documentation.<br>
+<br>
+Thanks for reading.<br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</blockquote></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130213/a992c0b6/attachment.html b/_build/static/archives/extend/attachments/20130213/a992c0b6/attachment.html new file mode 100644 index 00000000..efa8eb31 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130213/a992c0b6/attachment.html @@ -0,0 +1,25 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
+<div><br>
+</div>
+<div>  In 6.1, and still in 8.0, there is some logic that surprised me, and I wanted to see if it was intentional, or if I'm missing something.</div>
+<div><br>
+</div>
+<div>  If I set up a POST such that it's a create, I get back a 303, rather than a 201, on successful create. This came as a bit of a surprise; I know from Webmachine, if it's a new resource being created, a POST will return a 201 (N11 to P11 in Webmachine's
+ v3 diagram). </div>
+<div><br>
+</div>
+<div>  Is this intentional? The logic seems to be post_is_create/2 -> create_path/2 -> put_resource/3 -> choose_content_type/5 -> next/3 -> respond(_, _, 303). It may be that this is a better response, rather than a 201 with the location header, but it came
+ as a surprise given web machine's behavior.</div>
+<div><br>
+</div>
+<div>  For background, I'm attempting to migrate some web machine code to Cowboy, which is serving a RESTful API to a Javascript client. The client is making CORS calls. Receiving a 303 and a Location header seemed to mean that the call was redirected before
+ the client side code ever saw it (not sure what the browser was doing; I was expecting another request, but I wasn't quite lucid enough to check for that last night when working on it); a 201 allows me to examine the location. </div>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130221/fc119c69/attachment.html b/_build/static/archives/extend/attachments/20130221/fc119c69/attachment.html new file mode 100644 index 00000000..0a29dbf0 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130221/fc119c69/attachment.html @@ -0,0 +1,14 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
+<div><br>
+</div>
+<div>  I have a case where I am creating a resource through a POST. There are a number of places where the create can fail in a known manner, and we need to alert the user to the specifics of why. Is there a way to throw an arbitrary 500, with message, from
+ within the REST handler? I can obviously just erlang:error(whatever), but the message content is ignored, and there is no way to pass back an updated response when doing that.</div>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130317/2ee0bc92/attachment.html b/_build/static/archives/extend/attachments/20130317/2ee0bc92/attachment.html new file mode 100644 index 00000000..916afb32 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130317/2ee0bc92/attachment.html @@ -0,0 +1,54 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=windows-1251">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
+<div>  Cowboy aims to use binaries, not strings, and unless there's a change in the head branch I don't have, the returned tuple has only two values, the value and the request. So it should look like something like - </div>
+<div><br>
+</div>
+<div>  {Value, Req2} = cowboy_req:header(<<"user-agent">>, Req)</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<span id="OLK_SRC_BODY_SECTION">
+<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
+<span style="font-weight:bold">From: </span>  <<a href="mailto:kozlov-ter@yandex.ru">kozlov-ter@yandex.ru</a>><br>
+<span style="font-weight:bold">Date: </span>Sunday, March 17, 2013 9:22 AM<br>
+<span style="font-weight:bold">To: </span>"<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>" <<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>><br>
+<span style="font-weight:bold">Subject: </span>[99s-extend] cowboy header<br>
+</div>
+<div><br>
+</div>
+<div>
+<div>
+<div>Hello tell me how I can get for example http header "user-agent"?</div>
+<div>I do so:</div>
+<div> </div>
+<div>handle(Req, State) -></div>
+<div> </div>
+<div>{ok, FwdIP, Req5} = cowboy_req:header("user-agent, Req)</div>
+<div> </div>
+<div>but in this place I get the error</div>
+<div> </div>
+<div> </div>
+<div> </div>
+<div>--</div>
+<div>Vjacheslav Kozlov</div>
+<div>Engineer of AEMS</div>
+<div>Ltd. "EER-Novomichurinsk"</div>
+<div>--</div>
+<div><a href="http://www.ter-energo.ru">http://www.ter-energo.ru</a></div>
+<div>+79109095144 09:00-18:00 (GMT+04:00)</div>
+</div>
+</div>
+</span>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130317/2f20f449/attachment.html b/_build/static/archives/extend/attachments/20130317/2f20f449/attachment.html new file mode 100644 index 00000000..4ad610e9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130317/2f20f449/attachment.html @@ -0,0 +1,5 @@ + +<div>Hello tell me how I can get for example http header "user-agent"?</div><div>I do so:</div><div></div><div>handle(Req, State) -></div><div></div><div>{ok, FwdIP, Req5} = cowboy_req:header("user-agent, Req)</div><div></div><div>but in this place I get the error</div><div></div><div></div><div></div><div>--</div><div>Vjacheslav Kozlov</div><div>Engineer of AEMS</div><div>Ltd. "EER-Novomichurinsk"</div><div>--</div><div>http://www.ter-energo.ru</div><div>+79109095144 09:00-18:00 (GMT+04:00)</div>
+
+ + diff --git a/_build/static/archives/extend/attachments/20130413/f1b70800/attachment.html b/_build/static/archives/extend/attachments/20130413/f1b70800/attachment.html new file mode 100644 index 00000000..26903184 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130413/f1b70800/attachment.html @@ -0,0 +1,13 @@ + +<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 8:37 PM, Brown, Kevin <span dir="ltr"><<a href="mailto:Kevin.Brown@turner.com" target="_blank">Kevin.Brown@turner.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
+Cowfolk,<br>
+<br>
+I am doing something like this to create an #http_req suitable for unit<br>
+testing my resource callbacks:<br></blockquote><br><br></div><div class="gmail_quote">I use the library meck(<a href="https://github.com/eproxus/meck">https://github.com/eproxus/meck</a>) to test stuff doing something like this:<br>
+<br>some_test() -><br> meck:expect(cowboy_req, binding, 2, {<<"app_key">>, req} )<br> ?assertEqual({ok, req, empty},<br>   websocket_handler:websocket_init(transport, req, opts)),<br>
+ ?assert(meck:validate(cowboy_req)).<br><br></div><div class="gmail_quote">I use simple atoms as input and mock the cowboy_req functions to return atoms that would represent the correct or the wrong answer. <br><br></div>
+<div class="gmail_quote">The real implementation or how cowboy represent stuff is not important here, just the output pattern like {Binding, Req}.<br><br></div><div class="gmail_quote">That's it<br clear="all"></div><br>
+-- <br><br>Eduardo<br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130415/03f35a62/attachment.html b/_build/static/archives/extend/attachments/20130415/03f35a62/attachment.html new file mode 100644 index 00000000..e39c9a22 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130415/03f35a62/attachment.html @@ -0,0 +1,8 @@ + +<div dir="ltr">Hello group,<div><br></div><div style>I am trying to put together a CSRF middleware<a href="https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693">https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693</a>and if the body of the request contains "_csrf" token, I check to make sure it matches the csrf token in the session.</div>
+<div style><br></div><div style>Currently I am doing it in middleware using cowboy_req:body_qs/1 however when in the handler I need to read another body parameter, such as in the rest_pastebin example:</div><div style><br>
+</div><div style><div><span class="" style="white-space:pre">       </span>{ok, BodyQs, Req3} = cowboy_req:body_qs(Req),</div><div><span class="" style="white-space:pre">      </span>Paste = proplists:get_value(<<"paste">>, BodyQs),<br>
+</div><div><br></div><div>cowboy_req:body_qs/1 returns [] due to the body of the request being already read{body_state,done}<br></div><div><br></div><div style>Is it pointless to have the type of CSRF middleware that I am writing and just do the CSRF in the handler's callback, where I can deal with all the body_qs at once?</div>
+<div style><br></div><div style>Thank you,</div><div style><br></div><div style>rambocoder</div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130415/59aaeef2/attachment.html b/_build/static/archives/extend/attachments/20130415/59aaeef2/attachment.html new file mode 100644 index 00000000..f25d30e9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130415/59aaeef2/attachment.html @@ -0,0 +1,56 @@ + +<div dir="ltr">Loic,<div><br></div><div style>After giving the CSRF middleware some thought and reading <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL">https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL</a> I came to conclusion that it is best to just not create the middleware and instead deal with CSRF on as needed basis. </div>
+<div style><br></div><div style>I know that node's Connect middleware <a href="http://www.senchalabs.org/connect/csrf.html#defaultValue">http://www.senchalabs.org/connect/csrf.html#defaultValue</a> for example allows for the csrf token to be passed as a query string parameter, however, the OWASP article made me think that it is not the most secure approach.</div>
+<div style><br></div><div style>For example, AngularJS <a href="http://docs.angularjs.org/api/ng.$http">http://docs.angularjs.org/api/ng.$http</a> has a section on how their AJAX component behaves to do CSRF out of the box, and they are talking about the server sending a cookie <span style="color:rgb(51,51,51);font-family:monospace;font-size:12.800000190734863px;line-height:18px">XSRF-TOKEN </span>that is not HttpOnly. That makes me realize that csrf is a process more than just slapping some middleware into the pipeline.</div>
+<div style><br></div><div style>Btw, I noticed that when the result of the middleware execute function is:</div><div style>{error, StatusCode, Req}<br></div><div style>if I set the reply on the request via cowboy_req:reply before returning the {error.. , the status code of that reply will be used.</div>
+<div style><br></div><div style>Such as:</div><div style><div>{ok, Req3} = cowboy_req:reply(403, [], "Invalid CSRF Token.", Req2),<span class="" style="white-space:pre">                 </span></div><div>{error, 500, Req3}; % 500 is ignored, 403 is returned</div>
+<div><br></div><div style>Is that by design?</div><div style><br></div><div style>Sincerely,</div><div style><br></div><div style>rambocoder</div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
+On Mon, Apr 15, 2013 at 4:47 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Why not just put the token in the URL instead? if it's CSRF then it's probably used only once and only for POST and the like, so not cached or anything.<div><div class="h5"><br>
+<br>
+On 04/15/2013 10:45 PM, rambocoder wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hello group,<br>
+<br>
+I am trying to put together a CSRF middleware<br>
+<a href="https://github.com/rambocoder/stable/commit/b26980d292ac42aadfe9921a961436e28cdbb693" target="_blank">https://github.com/rambocoder/<u></u>stable/commit/<u></u>b26980d292ac42aadfe9921a961436<u></u>e28cdbb693</a> and<br>
+
+if the body of the request contains "_csrf" token, I check to make sure<br>
+it matches the csrf token in the session.<br>
+<br>
+Currently I am doing it in middleware using cowboy_req:body_qs/1 however<br>
+when in the handler I need to read another body parameter, such as in<br>
+the rest_pastebin example:<br>
+<br>
+{ok, BodyQs, Req3} = cowboy_req:body_qs(Req),<br>
+Paste = proplists:get_value(<<"paste"><u></u>>, BodyQs),<br>
+<br>
+cowboy_req:body_qs/1 returns [] due to the body of the request being<br>
+already read {body_state,done}<br>
+<br>
+Is it pointless to have the type of CSRF middleware that I am writing<br>
+and just do the CSRF in the handler's callback, where I can deal with<br>
+all the body_qs at once?<br>
+<br>
+Thank you,<br>
+<br>
+rambocoder<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130419/383515dd/attachment.html b/_build/static/archives/extend/attachments/20130419/383515dd/attachment.html new file mode 100644 index 00000000..05571216 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130419/383515dd/attachment.html @@ -0,0 +1,213 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
+<div>  When querying to the VM from a browser, is Chrome complaining that it's a cross domain request in the console? Or something else? </div>
+<div><br>
+</div>
+<div>  Is the OPTIONS request firing and failing, or is it the POST that is failing (in the network tab)? </div>
+<div><br>
+</div>
+<div>  If it's working in a cross origin context for you locally across different domains (I.e., the browser is sending the CORS headers on the request, and you're seeing the right headers on the response, and the browser is handling them properly, such that
+ you can retrieve the response from your Javascript), then it seems unlikely to be a CORS issue, but maybe a config or proxy or code issue in your handler. </div>
+<div><br>
+</div>
+<div><br>
+</div>
+<span id="OLK_SRC_BODY_SECTION">
+<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
+<span style="font-weight:bold">From: </span>Lee Sylvester <<a href="mailto:lee.sylvester@gmail.com">lee.sylvester@gmail.com</a>><br>
+<span style="font-weight:bold">Date: </span>Friday, April 19, 2013 10:47 AM<br>
+<span style="font-weight:bold">To: </span>"<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>" <<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>><br>
+<span style="font-weight:bold">Subject: </span>[99s-extend] Cowboy CORS<br>
+</div>
+<div><br>
+</div>
+<div>
+<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">
+<div>Hi guys,</div>
+<div><br>
+</div>
+<div>So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (<a href="http://test.localhost.com">test.localhost.com</a> and
+<a href="http://cowboy.localhost.com">cowboy.localhost.com</a>).  However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy.  Here's the OPTIONS response from Chrome's console:</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div>
+<ol class="outline-disclosure" tabindex="0" style="box-sizing: border-box; font-size: 11px; list-style-type: none; -webkit-padding-start: 12px; margin: 0px; outline: none; font-family: 'Lucida Grande', sans-serif; background-color: rgb(255, 255, 255); ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Request URL:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+<a href="http://www.example.com/">http://www.example.com/</a></div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Request Method:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+OPTIONS</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Status Code:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+200 OK</div>
+</li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">
+Request Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view source</span>
+<ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Accept:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+*/*</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Accept-Charset:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+ISO-8859-1,utf-8;q=0.7,*;q=0.3</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Accept-Encoding:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+gzip,deflate,sdch</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Accept-Language:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+en-US,en;q=0.8</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Access-Control-Request-Headers:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+origin, method, content-type</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Access-Control-Request-Method:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+POST</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Connection:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+keep-alive</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Host:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+<a href="http://www.example.com">www.example.com</a></div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Origin:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+<a href="http://test.localhost.com:8889">http://test.localhost.com:8889</a></div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Referer:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+<a href="http://test.localhost.com:8889/">http://test.localhost.com:8889/</a></div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+User-Agent:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31</div>
+</li></ol>
+</li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">
+Response Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view source</span>
+<ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Access-Control-Allow-Headers:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+Content-Type, X-Requested-With, Origin, Method</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Access-Control-Allow-Methods:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+GET, POST, OPTIONS</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Access-Control-Allow-Origin:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+*</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+connection:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+keep-alive</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+content-length:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+0</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+date:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+Fri, 19 Apr 2013 14:40:00 GMT</div>
+</li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+server:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+Cowboy</div>
+</li></ol>
+</li></ol>
+<div><br>
+</div>
+</div>
+<div>And then this is the POST response:</div>
+<div><br>
+</div>
+<div>
+<ol class="outline-disclosure" tabindex="0" style="box-sizing: border-box; font-size: 11px; list-style-type: none; -webkit-padding-start: 12px; margin: 0px; outline: none; font-family: 'Lucida Grande', sans-serif; background-color: rgb(255, 255, 255); ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;">
+<div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">
+Request URL:</div>
+<div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">
+<a href="http://www.example.com/">http://www.example.com/</a></div>
+</li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">
+Request Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view parsed</span>
+<ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<span class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">POST
+<a href="http://www.example.com/">http://www.example.com/</a> HTTP/1.1 Origin: <a href="http://test.localhost.com:8889">
+http://test.localhost.com:8889</a> Referer: <a href="http://test.localhost.com:8889/">
+http://test.localhost.com:8889/</a> method: POST <a href="http://www.example.com/">
+http://www.example.com/</a> HTTP/1.1 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31 content-type: application/x-www-form-urlencoded</span></li></ol>
+</li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">
+Form Data<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view parsed</span>
+<ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; ">
+<li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;">
+<span class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"<a href="http://www.example.com">www.example.com</a>","Application":"test_app","Ident":"lee"}</span></li></ol>
+</li></ol>
+<div><br>
+</div>
+</div>
+<div>I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working.  Can anyone spot what I might be doing wrong?</div>
+<div><br>
+</div>
+<div>The cowboy_req:set_resp_header is happening in the handle So</div>
+<div><br>
+</div>
+<div>
+<div>handle(Req, State) -></div>
+<div><span class="Apple-tab-span" style="white-space:pre"></span>Reply = case cowboy_req:method(Req) of</div>
+<div><span class="Apple-tab-span" style="white-space:pre"></span>{<<"POST">>, Req2} -></div>
+<div><span class="Apple-tab-span" style="white-space:pre"></span>Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2),</div>
+</div>
+<div>[snip]</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div>Thanks,</div>
+<div>Lee</div>
+<div><br>
+</div>
+</div>
+</div>
+</span>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130419/bf0e8ef9/attachment.html b/_build/static/archives/extend/attachments/20130419/bf0e8ef9/attachment.html new file mode 100644 index 00000000..8b3834c9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130419/bf0e8ef9/attachment.html @@ -0,0 +1,8 @@ + +<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Hi guys,</div><div><br></div><div>So, I thought I had this resolved, as I managed to get it working locally, but across different local domains (<a href="http://test.localhost.com">test.localhost.com</a> and <a href="http://cowboy.localhost.com">cowboy.localhost.com</a>).  However, now I've deployed my app to a VM, I simply can't get CORS working in Cowboy.  Here's the OPTIONS response from Chrome's console:</div><div><br></div><div><br></div><div><ol class="outline-disclosure" tabindex="0" style="box-sizing: border-box; font-size: 11px; list-style-type: none; -webkit-padding-start: 12px; margin: 0px; outline: none; font-family: 'Lucida Grande', sans-serif; background-color: rgb(255, 255, 255); "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Request URL:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; "><a href="http://www.example.com/">http://www.example.com/</a></div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Request Method:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">OPTIONS</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Status Code:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">200 OK</div></li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">Request Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view source</span></li><ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Accept:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">*/*</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Accept-Charset:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">ISO-8859-1,utf-8;q=0.7,*;q=0.3</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Accept-Encoding:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">gzip,deflate,sdch</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Accept-Language:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">en-US,en;q=0.8</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Access-Control-Request-Headers:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">origin, method, content-type</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Access-Control-Request-Method:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">POST</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Connection:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">keep-alive</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Host:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; "><a href="http://www.example.com">www.example.com</a></div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Origin:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; "><a href="http://test.localhost.com:8889">http://test.localhost.com:8889</a></div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Referer:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; "><a href="http://test.localhost.com:8889/">http://test.localhost.com:8889/</a></div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">User-Agent:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31</div></li></ol><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">Response Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view source</span></li><ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Access-Control-Allow-Headers:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">Content-Type, X-Requested-With, Origin, Method</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Access-Control-Allow-Methods:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">GET, POST, OPTIONS</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Access-Control-Allow-Origin:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">*</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">connection:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">keep-alive</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">content-length:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">0</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">date:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">Fri, 19 Apr 2013 14:40:00 GMT</div></li><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">server:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">Cowboy</div></li></ol></ol><div><br></div></div><div>And then this is the POST response:</div><div><br></div><div><ol class="outline-disclosure" tabindex="0" style="box-sizing: border-box; font-size: 11px; list-style-type: none; -webkit-padding-start: 12px; margin: 0px; outline: none; font-family: 'Lucida Grande', sans-serif; background-color: rgb(255, 255, 255); "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word;"><div class="header-name" style="box-sizing: border-box; color: rgb(84, 84, 84); display: inline-block; margin-right: 0.5em; font-weight: bold; vertical-align: top; white-space: pre-wrap;">Request URL:</div><div class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; "><a href="http://www.example.com/">http://www.example.com/</a></div></li><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">Request Headers<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view parsed</span></li><ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><span class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">POST <a href="http://www.example.com/">http://www.example.com/</a> HTTP/1.1
+Origin: <a href="http://test.localhost.com:8889">http://test.localhost.com:8889</a>
+Referer: <a href="http://test.localhost.com:8889/">http://test.localhost.com:8889/</a>
+method: POST <a href="http://www.example.com/">http://www.example.com/</a> HTTP/1.1
+User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
+content-type: application/x-www-form-urlencoded</span></li></ol><li title="" class="parent expanded" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -12px; word-wrap: break-word; -webkit-user-select: none; font-weight: bold;">Form Data<span class="header-toggle" style="box-sizing: border-box; display: inline; margin-left: 30px; font-weight: normal; color: rgb(115, 115, 115);">view parsed</span></li><ol class="children expanded" style="box-sizing: border-box; position: relative; margin: 0px; cursor: default; min-width: 100%; padding: 2px 6px !important; list-style-type: none; -webkit-padding-start: 12px; "><li title="" style="box-sizing: border-box; padding: 0px 0px 0px 14px; margin-top: 1px; margin-left: -2px; word-wrap: break-word; white-space: nowrap;"><span class="header-value source-code" style="box-sizing: border-box; font-family: Menlo, monospace; white-space: pre-wrap; display: inline; margin-right: 100px; word-break: break-all; margin-top: 1px; ">data={"Type":"auth_request","Authentication":"public","Authorization":null,"Domain":"<a href="http://www.example.com">www.example.com</a>","Application":"test_app","Ident":"lee"}</span></li></ol></ol><div><br></div></div><div>I am setting {<<"Access-Control-Allow-Origin">>, <<"*">>} in the headers param of cowboy_req:reply and the cowboy_req:set_resp_header, but neither seems to be working.  Can anyone spot what I might be doing wrong?</div><div><br></div><div>The cowboy_req:set_resp_header is happening in the handle So</div><div><br></div><div><div>handle(Req, State) -></div><div><span class="Apple-tab-span" style="white-space:pre">      </span>Reply = case cowboy_req:method(Req) of</div><div><span class="Apple-tab-span" style="white-space:pre">               </span>{<<"POST">>, Req2} -></div><div><span class="Apple-tab-span" style="white-space:pre">                       </span>Req3 = cowboy_req:set_resp_header(<<"Access-Control-Allow-Origin">>, <<"*">>, Req2),</div></div><div>[snip]</div><div><br></div><div><br></div><div>Thanks,</div><div>Lee</div><div><br></div></body></html> + diff --git a/_build/static/archives/extend/attachments/20130425/35ee7614/attachment.html b/_build/static/archives/extend/attachments/20130425/35ee7614/attachment.html new file mode 100644 index 00000000..0f133e02 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130425/35ee7614/attachment.html @@ -0,0 +1,4 @@ + +<div dir="ltr"><div>You know, the OTP's code_change so heavy, sometimes, you just want to debug, or change a little, does not want to rewrite the rel appup file.<br></div>Any help is appreciated, thanks.</div>
+ + diff --git a/_build/static/archives/extend/attachments/20130426/09f3ed34/attachment.html b/_build/static/archives/extend/attachments/20130426/09f3ed34/attachment.html new file mode 100644 index 00000000..0e62d4c9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130426/09f3ed34/attachment.html @@ -0,0 +1,20 @@ + +<div dir="ltr"><div>Thanks very much !<br></div>Maybe we can use the code:load_file() function I had just found it .<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/4/25 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/25/2013 05:46 AM, yongboy wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+You know, the OTP's code_change so heavy, sometimes, you just want to<br>
+debug, or change a little, does not want to rewrite the rel appup file.<br>
+Any help is appreciated, thanks.<br>
+</blockquote>
+<br></div></div>
+At this time there is no code_change mechanism in Cowboy. Reloading a module works, modifying the protocol options with ranch:set_protocol_options can be used, but it doesn't change the running processes.<span class="HOEnZb"><font color="#888888"><br>
+
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130426/9d234e27/attachment.html b/_build/static/archives/extend/attachments/20130426/9d234e27/attachment.html new file mode 100644 index 00000000..cbe576b0 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130426/9d234e27/attachment.html @@ -0,0 +1,12 @@ + +<div dir="ltr"><div><div>I have tested one long-hold webapp, when 512000 user connected, the app used <br></div>6801M memory, 6801M*1024K / 512000 = 13.6K/Connection.<br><br></div><div>Does anyone give me some advice on how to reduce the memory usage per one connection, thanks very much !<br>
+</div><div><br></div>Here is the code snippet:<br><br>start(_Type, _Args) -><br> Dispatch = cowboy_router:compile([<br> {'_', [{'_', htmlfile_handler, []}]}<br> ]),<br> cowboy:start_http(my_http_listener, 100,<br>
+ [{port, 8000}, {max_connections, infinity}],<br> [{env, [{dispatch, Dispatch}]}]<br> ),<br> count_server:start(),<br> htmlfilesimple_sup:start_link().<br><br>......<br><br>-module(htmlfile_handler).<br>
+-behaviour(cowboy_loop_handler).<br>-export([init/3, info/3, terminate/3]).<br>-define(HEARBEAT_TIMEOUT, 20*1000).<br>-record(status, {count=0}).<br><br>init(_Any, Req, State) -><br> NowCount = count_server:welcome(),<br>
+ io:format("online user ~p :))~n", [NowCount]),<br><br> output_first(Req),<br> Req2 = cowboy_req:compact(Req),<br> {loop, Req2, State, hibernate}.<br><br>%% POST/Short Request<br>info(_Any, Req, State) -><br>
+ {loop, Req, State, hibernate}.<br><br>output_first(Req) -><br> {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>, <<"text/html; charset=utf-8">>},<br>
+ {<<"Connection">>, <<"keep-alive">>}], Req),<br> cowboy_req:chunk(<<"<html><body><script>var _ = function (msg) { parent.s._(msg, document); };</script> ">>,<br>
+ Reply),<br> cowboy_req:chunk(gen_output("1::"), Reply).<br><br>gen_output(String) -><br> DescList = io_lib:format("<script>_('~s');</script>", [String]),<br>
+ list_to_binary(DescList).<br><br>terminate(Reason, _Req, _State) -><br> NowCount = count_server:bye(),<br> io:format("offline user ~p :(( ~n", [NowCount]).<br><br><br><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130426/b1e8ae7a/attachment.html b/_build/static/archives/extend/attachments/20130426/b1e8ae7a/attachment.html new file mode 100644 index 00000000..74c43a61 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130426/b1e8ae7a/attachment.html @@ -0,0 +1,27 @@ + +Is 13.6K/connection considered a lot? Once you start doing SSL, each connection will be about 80K, IMHO the most important factor for huge ammount of COMET users is latency, which Cowboy and Erlang do great.<div><br></div>
+<div>-rambocoder<br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 2:11 AM, yongboy <span dir="ltr"><<a href="mailto:yongboy@gmail.com" target="_blank">yongboy@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div dir="ltr"><div><div>I have tested one long-hold webapp, when 512000 user connected, the app used <br></div>6801M memory, 6801M*1024K / 512000 = 13.6K/Connection.<br><br></div><div>Does anyone give me some advice on how to reduce the memory usage per one connection, thanks very much !<br>
+
+</div><div><br></div>Here is the code snippet:<br><br>start(_Type, _Args) -><br> Dispatch = cowboy_router:compile([<br> {'_', [{'_', htmlfile_handler, []}]}<br> ]),<br> cowboy:start_http(my_http_listener, 100,<br>
+
+ [{port, 8000}, {max_connections, infinity}],<br> [{env, [{dispatch, Dispatch}]}]<br> ),<br> count_server:start(),<br> htmlfilesimple_sup:start_link().<br><br>......<br><br>-module(htmlfile_handler).<br>
+
+-behaviour(cowboy_loop_handler).<br>-export([init/3, info/3, terminate/3]).<br>-define(HEARBEAT_TIMEOUT, 20*1000).<br>-record(status, {count=0}).<br><br>init(_Any, Req, State) -><br> NowCount = count_server:welcome(),<br>
+
+ io:format("online user ~p :))~n", [NowCount]),<br><br> output_first(Req),<br> Req2 = cowboy_req:compact(Req),<br> {loop, Req2, State, hibernate}.<br><br>%% POST/Short Request<br>info(_Any, Req, State) -><br>
+
+ {loop, Req, State, hibernate}.<br><br>output_first(Req) -><br> {ok, Reply} = cowboy_req:chunked_reply(200, [{<<"Content-Type">>, <<"text/html; charset=utf-8">>},<br>
+
+ {<<"Connection">>, <<"keep-alive">>}], Req),<br> cowboy_req:chunk(<<"<html><body><script>var _ = function (msg) { parent.s._(msg, document); };</script> ">>,<br>
+
+ Reply),<br> cowboy_req:chunk(gen_output("1::"), Reply).<br><br>gen_output(String) -><br> DescList = io_lib:format("<script>_('~s');</script>", [String]),<br>
+
+ list_to_binary(DescList).<br><br>terminate(Reason, _Req, _State) -><br> NowCount = count_server:bye(),<br> io:format("offline user ~p :(( ~n", [NowCount]).<br><br><br><br></div>
+<br>_______________________________________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+<br></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130430/c86f8fdb/attachment.html b/_build/static/archives/extend/attachments/20130430/c86f8fdb/attachment.html new file mode 100644 index 00000000..792f4a4d --- /dev/null +++ b/_build/static/archives/extend/attachments/20130430/c86f8fdb/attachment.html @@ -0,0 +1,8 @@ + +<div dir="ltr">Hi,<br>I'm new to the community and am exploring cowboy for a project.<div><br></div><div>Can anyone offer guidance/links on how to use cowboy's websocket support with WAMP (<a href="http://wamp.ws/">http://wamp.ws/</a>)?</div>
+<div>The cowboy docs mention<a href="https://github.com/extend/bullet?source=cr">bullet</a>as a convenient client/server lib (with an AJAX fallback) which is great, but I'd like to use WAMP's RPC and PubSub so I'm unsure how to proceed.<br clear="all">
+<div><br></div><div style>Any tips would be appreciated!</div><div style><br></div><div style>Thanks in advance</div>-- <br><div dir="ltr">Gregory | <a href="http://twitter.com/gdesouza" target="_blank">@gdesouza</a> | <a href="http://blog.gdesouza.me" target="_blank">http://blog.gdesouza.me</a></div>
+
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130512/65929751/attachment.html b/_build/static/archives/extend/attachments/20130512/65929751/attachment.html new file mode 100644 index 00000000..645b5681 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130512/65929751/attachment.html @@ -0,0 +1,44 @@ + +<div dir="ltr">Ok, thx, I missed that one :)</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/5/12 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It sets a set-cookie header directly. You can retrieve all response headers by calling something like cowboy_req:get(resp_headers, Req).<div>
+
+<div class="h5"><br>
+<br>
+On 05/12/2013 01:42 PM, Enrique Paz wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hi,<br>
+<br>
+I have a piece of code that receives a cowboy_req:http_req() object and<br>
+depending on some Context sets 1 or more cookies<br>
+using cowboy_req:set_resp_cookie/4.<br>
+<br>
+add_cookies(Req, Context) -> ReqWithCookiesSet<br>
+<br>
+I want to write a unit test for it, checking that the right cookies are<br>
+set for the right Context.  How can I do that? I miss something like<br>
+cowboy_req:get_resp_cookie/2 or so.<br>
+<br>
+Thx in advance for your help.<br>
+<br>
+--<br>
+Enrique<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>quique
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20130512/dd43116e/attachment.html b/_build/static/archives/extend/attachments/20130512/dd43116e/attachment.html new file mode 100644 index 00000000..8f34c4e0 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130512/dd43116e/attachment.html @@ -0,0 +1,9 @@ + +<div dir="ltr">Hi,<div><br></div><div>I have a piece of code that receives a cowboy_req:http_req() object and depending on some Context sets 1 or more cookies usingcowboy_req:set_resp_cookie/4.</div><div><br></div><div style>
+
+add_cookies(Req, Context) -> ReqWithCookiesSet</div><div><br></div><div>I want to write a unit test for it, checking that the right cookies are set for the right Context. How can I do that? I miss something like cowboy_req:get_resp_cookie/2 or so.</div>
+
+<div style><br></div><div style>Thx in advance for your help.</div><div><div><br></div>-- <br>Enrique
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130517/629071b8/attachment.html b/_build/static/archives/extend/attachments/20130517/629071b8/attachment.html new file mode 100644 index 00000000..5eb70a36 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130517/629071b8/attachment.html @@ -0,0 +1,19 @@ + +<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Hi all,</span><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">I am learning cowboy by building a small application with rest interface.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+I have a hello_world rest handler and I want to implement POST method that returns </div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">json as response to a client. Therefor I implemented callbacks allowed_methods,</div>
+<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">content_types_accepted and hello_json. The docu says user callbacks can</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+return {Value, Req, State} and also can return {halt, Req, State}. It is not really clear</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">what that Value should be. So I tried {ok, Req, State} and {true, Req, State} and with</div>
+<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">both values I have</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><div>=ERROR REPORT==== 11-May-2013::16:06:40 ===</div><div>Error in process <0.6649.0> with exit value: {function_clause,[{cowboy_req,reply,[303,....</div>
+</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+and client gets right response. If I use {halt, Req, State} the client gets right response too</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">and there is no errors. So, Is it right way to write a POST callback and what Values can</div>
+<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">be used for user callbacks? I write my code below.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">amike,</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+Vitali</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
+<div>allowed_methods(Req, State) -></div><div><span style="white-space:pre-wrap">  </span>{[<<"POST">>, <<"DELETE">>], Req, State}.</div><div><br></div><div>content_types_accepted(Req, State) -></div>
+<div><span style="white-space:pre-wrap">  </span>{[</div><div><span style="white-space:pre-wrap">       </span> {{<<"application">>, <<"x-www-form-urlencoded">>, []}, hello_json}</div>
+<div><span style="white-space:pre-wrap">  </span>],Req, State}.</div><div><br></div><div>hello_json(Req, State) -></div><div><span style="white-space:pre-wrap">     </span>{ok, Req2} = cowboy_req:reply(200, [{<<"content-type">>, <<"application/json">>} ], <<"{\"rest\": \"Hello World!\"}">>, Req),</div>
+<div><span style="white-space:pre-wrap">  </span>{halt, Req2, State}.</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130519/db7f08ab/attachment.html b/_build/static/archives/extend/attachments/20130519/db7f08ab/attachment.html new file mode 100644 index 00000000..e4c7ef10 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130519/db7f08ab/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">I want to write a cowboy middleware that works only on non-websocket requests. How can I achieve this? Is there any way that I ask the Request if this is a websocket request?<br><br>Thank you<br clear="all">
+<div><br>-- <br><div dir="ltr">Eduardo<br></div>
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130520/3cc045e8/attachment.html b/_build/static/archives/extend/attachments/20130520/3cc045e8/attachment.html new file mode 100644 index 00000000..bbb81bf6 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130520/3cc045e8/attachment.html @@ -0,0 +1,9 @@ + +<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel <span dir="ltr"><<a href="mailto:edgurgel@gmail.com" target="_blank">edgurgel@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I want to write a cowboy middleware that works only on non-websocket requests. How can I achieve this? Is there any way that I ask the Request if this is a websocket request?<br>
+<br></div></blockquote><div><br></div><div style>Thinking about my question, I see that the middleware (if it's behind the cowboy_handler) can't figure if the connection will be upgraded or not.</div><div style><br>
+</div><div style>Still, it would be cool if I could select which routes will be applied to my middleware.</div><div style><br></div><div style>Am I making any sense? :)</div></div><div><br></div>-- <br><div dir="ltr">Eduardo<br>
+</div>
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130520/5134ba32/attachment.html b/_build/static/archives/extend/attachments/20130520/5134ba32/attachment.html new file mode 100644 index 00000000..93278610 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130520/5134ba32/attachment.html @@ -0,0 +1,29 @@ + +<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 20, 2013 at 10:25 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 05/20/2013 01:53 PM, Eduardo Gurgel wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+<br>
+<br>
+<br>
+On Sun, May 19, 2013 at 10:01 PM, Eduardo Gurgel <<a href="mailto:edgurgel@gmail.com" target="_blank">edgurgel@gmail.com</a><br></div><div class="im">
+<mailto:<a href="mailto:edgurgel@gmail.com" target="_blank">edgurgel@gmail.com</a>>> wrote:<br>
+<br>
+  I want to write a cowboy middleware that works only on non-websocket<br>
+  requests. How can I achieve this? Is there any way that I ask the<br>
+  Request if this is a websocket request?<br>
+<br>
+<br>
+Thinking about my question, I see that the middleware (if it's behind<br>
+the cowboy_handler) can't figure if the connection will be upgraded or not.<br>
+<br>
+Still, it would be cool if I could select which routes will be applied<br>
+to my middleware.<br>
+</div></blockquote>
+<br>
+You have the Req which can help you do things based on host or path, and you also have the environment, which contains the name of the handler that's gonna be used if you execute your middleware after cowboy_router.<span class="HOEnZb"><font color="#888888"><br>
+
+<br></font></span></blockquote><div><br></div><div style>Perfect! The environment can help me :)</div><div><br></div><div><br></div><div style>Thank you, again!</div></div><div><br></div>-- <br><div dir="ltr">Eduardo<br>
+</div>
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130605/568478c8/attachment.html b/_build/static/archives/extend/attachments/20130605/568478c8/attachment.html new file mode 100644 index 00000000..d5a5f32c --- /dev/null +++ b/_build/static/archives/extend/attachments/20130605/568478c8/attachment.html @@ -0,0 +1,9 @@ + +<div dir="ltr">Hi,<div><br></div><div>I'm trying to implement REST handler which communicates to custom gen_servers.</div><div><br></div><div>Get gen_server from supervisor and link to current handler process:</div><div>
+<br></div><div><div>rest_init(Req, _Opts) -></div><div>...</div><div><div> process_flag(trap_exit, true),</div></div><div> {ok, Pid} = pbshare_logic_sup:start_registration(),<br></div><div> link(Pid),</div></div><div>
+...</div><div><br></div><div><div>make_get(Req, State) -></div></div><div>....</div><div>make error here !!!</div><div>....</div><div><br></div><div><br></div><div>And gen_server code:</div><div><div>start_link() -></div>
+<div> gen_server:start_link(?MODULE, [], []).</div><div><br></div><div>init(Args) -></div><div> process_flag(trap_exit, true),<br></div><div> {ok, []}.</div></div><div><br></div><div><div>handle_info({'EXIT', FromPid, Reason}, State) -></div>
+<div> lager:info("Exit Logic from ~p Reason: ~p~n", [FromPid, Reason]),</div><div> {noreply, State};</div></div><div><br></div><div>So I expect to receive EXIT signal from REST handler to my gen_server when error occurs in cowboy.</div>
+<div>But I don't receive it. Am I doing something wrong?<br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130718/79e075b8/attachment.html b/_build/static/archives/extend/attachments/20130718/79e075b8/attachment.html new file mode 100644 index 00000000..a9b30f22 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130718/79e075b8/attachment.html @@ -0,0 +1,21 @@ + +
+                <div>
+                    <span style="font-size: 12px;">That would be perfect!  Do you want me to make the change and issue a pull request?</span>
+                </div>
+                <div><div><br></div><div>-- </div><div>Dr Adrian Roe</div><div>Director<br></div><div><br></div></div>
+                 
+                <p style="color: #A0A0A8;">On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:</p>
+                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
+                    <span><div><div><div>I don't think the problem is that the handler is reused, we don't reuse </div><div>them if there's an error. However we do catch errors to print them in </div><div>the logs, and then the process stops normally. If you link without </div><div>trap_exit you receive a normal exit signal which is ignored and doesn't </div><div>kill your process. I suppose we should throw an exit signal when we got </div><div>an error, after logging everything, instead of stopping normally.</div><div><br></div><div>On 07/18/2013 12:31 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>My issue is the other way round.  My handler crashes - and terminate</div><div>gets called, but the linked process is NOT stopped (unless I stop it in</div><div>terminate having stashed any processes I need to stop in the process</div><div>dictionary - this is what I'm currently doing, but yuck!)</div><div><br></div><div>.  My question is whether it wouldn't be better to no re-use the handler</div><div>process that has crashed and replace it so that handler's can use the</div><div>canonical erlang way of stopping related processes rather than having to</div><div>do it by hand.</div><div><br></div><div>Obviously if the handler does not crash there's no need to kill the</div><div>process, so the current efficiency saving works in the "normal" case/</div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div>On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:</div><div><br></div><blockquote type="cite"><div><div>I don't know what happens but there's two things I know:</div><div><br></div><div>* Handlers don't trap_exit, so if the linked process crashes, they</div><div>crash too</div><div>* If the handler crashes, we close the connection and stop the</div><div>handler; if not this is a bug</div><div><br></div><div>After your log message the handler should stop unless there's a bug</div><div>somewhere.</div><div><br></div><div>On 07/18/2013 12:15 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>We have been using spawn_linked workers to handle tasks that live for</div><div>the lifetime of a single HTTP request</div><div><br></div><div>Although in the cowboy guide it is clear that Cowboy can use "One</div><div>Process of Many Requests" I am surprised that this is the case even if</div><div>the handler crashes. For example, our use case is to copy a large file</div><div>to the server over HTTP where a worker process relays the file contents</div><div>to long term storage. The worker process is spawn_linked from the HTTP</div><div>handler and (for our use case) should die if the handler stops.</div><div><br></div><div>If the client stops the upload (for example by browsing away, or losing</div><div>connectivity) we correctly receive an error (see sample Lager trace</div><div>below), but what we are seeing is that spawn_linked processes are NOT</div><div>being killed.</div><div><br></div><div>Is this intended behaviour - I accept it makes sense to reuse the</div><div>processes but should this continue to be the case even if the previous</div><div>use of the process crashed? If it is intended behaviour I think the</div><div>docs should highlight this as we've been leaking processes for some time</div><div>now, but I've always seen it as erlang's job to look after related</div><div>process trees in the event of error. Our current workaround is to hold</div><div>a list of linked processes in process storage and then kill them in the</div><div>terminate handler which is ugly in the extreme!! We don't know the PIDS</div><div>of the linked processes until it is too late to return State to Cowboy</div><div>(i.e. we are already in our handle code)...</div><div><br></div><div>Kind regards</div><div><br></div><div>Adrian</div><div><br></div><div>16:09:32.347 [info] Trailer upload failed with reason</div><div>{case_clause,{error,closed}}</div><div>16:09:32.348 [error] ** Cowboy handler upload_trailer_resource</div><div>terminating in handle/2</div><div>for the reason error:{case_clause,{error,closed}}</div><div>** Handler state was {state,undefined,0,undefined,undefined,undefined}</div><div>** Request was</div><div>[{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef</div><div>ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>">>},{<<"user-agent">>,<<"M</div><div>ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,</div><div>like Gecko) Chrome/28.0.1500.71</div><div>Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce</div><div>pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;</div><div>id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde</div><div>fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]</div><div>** Stacktrace:</div><div>[{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}</div><div>,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo</div><div>ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]</div><div><br></div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>Extend mailing list</div><div>Extend@lists.ninenines.eu <<a href="mailto:Extend@lists.ninenines.eu">mailto:Extend@lists.ninenines.eu</a>></div><div><a href="http://lists.ninenines.eu:81/listinfo/extend">http://lists.ninenines.eu:81/listinfo/extend</a></div></div></blockquote><div><br></div><div><br></div><div>--</div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></div></span>
+                 
+                 
+                 
+                 
+                </blockquote>
+                 
+                <div>
+                    <br>
+                </div>
+             + diff --git a/_build/static/archives/extend/attachments/20130718/a3961a6f/attachment.html b/_build/static/archives/extend/attachments/20130718/a3961a6f/attachment.html new file mode 100644 index 00000000..ed6b2dc1 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130718/a3961a6f/attachment.html @@ -0,0 +1,21 @@ + +
+                <div>
+                    <span style="font-size: 12px;">I suspect it's just a case of adding a throw to error_terminate in cowboy_protocol, maybe with threading the reason back (though I don't really care what's thrown), but also fear there may be unintended consequences as all I've done is skim your code briefly!  If you are able to look at it then great - if not I'll muddle through.  I'm travelling so it would be mid next week at the earliest anyway.</span>
+                </div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Cheers</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Adrian</span></div>
+                <div><div><br></div><div>-- </div><div>Dr Adrian Roe</div><div>Director<br></div><div><br></div></div>
+                 
+                <p style="color: #A0A0A8;">On Thursday, 18 July 2013 at 11:38, Loïc Hoguin wrote:</p>
+                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
+                    <span><div><div><div>If you got time sure, I won't have much time until Monday. Have fun!</div><div><br></div><div>On 07/18/2013 12:37 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>That would be perfect!  Do you want me to make the change and issue a</div><div>pull request?</div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div>On Thursday, 18 July 2013 at 11:36, Loïc Hoguin wrote:</div><div><br></div><blockquote type="cite"><div><div>I don't think the problem is that the handler is reused, we don't reuse</div><div>them if there's an error. However we do catch errors to print them in</div><div>the logs, and then the process stops normally. If you link without</div><div>trap_exit you receive a normal exit signal which is ignored and doesn't</div><div>kill your process. I suppose we should throw an exit signal when we got</div><div>an error, after logging everything, instead of stopping normally.</div><div><br></div><div>On 07/18/2013 12:31 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>My issue is the other way round. My handler crashes - and terminate</div><div>gets called, but the linked process is NOT stopped (unless I stop it in</div><div>terminate having stashed any processes I need to stop in the process</div><div>dictionary - this is what I'm currently doing, but yuck!)</div><div><br></div><div>. My question is whether it wouldn't be better to no re-use the handler</div><div>process that has crashed and replace it so that handler's can use the</div><div>canonical erlang way of stopping related processes rather than having to</div><div>do it by hand.</div><div><br></div><div>Obviously if the handler does not crash there's no need to kill the</div><div>process, so the current efficiency saving works in the "normal" case/</div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div>On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:</div><div><br></div><blockquote type="cite"><div><div>I don't know what happens but there's two things I know:</div><div><br></div><div>* Handlers don't trap_exit, so if the linked process crashes, they</div><div>crash too</div><div>* If the handler crashes, we close the connection and stop the</div><div>handler; if not this is a bug</div><div><br></div><div>After your log message the handler should stop unless there's a bug</div><div>somewhere.</div><div><br></div><div>On 07/18/2013 12:15 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>We have been using spawn_linked workers to handle tasks that live for</div><div>the lifetime of a single HTTP request</div><div><br></div><div>Although in the cowboy guide it is clear that Cowboy can use "One</div><div>Process of Many Requests" I am surprised that this is the case even if</div><div>the handler crashes. For example, our use case is to copy a large file</div><div>to the server over HTTP where a worker process relays the file contents</div><div>to long term storage. The worker process is spawn_linked from the HTTP</div><div>handler and (for our use case) should die if the handler stops.</div><div><br></div><div>If the client stops the upload (for example by browsing away, or losing</div><div>connectivity) we correctly receive an error (see sample Lager trace</div><div>below), but what we are seeing is that spawn_linked processes are NOT</div><div>being killed.</div><div><br></div><div>Is this intended behaviour - I accept it makes sense to reuse the</div><div>processes but should this continue to be the case even if the previous</div><div>use of the process crashed? If it is intended behaviour I think the</div><div>docs should highlight this as we've been leaking processes for some</div><div>time</div><div>now, but I've always seen it as erlang's job to look after related</div><div>process trees in the event of error. Our current workaround is to hold</div><div>a list of linked processes in process storage and then kill them in the</div><div>terminate handler which is ugly in the extreme!! We don't know the PIDS</div><div>of the linked processes until it is too late to return State to Cowboy</div><div>(i.e. we are already in our handle code)...</div><div><br></div><div>Kind regards</div><div><br></div><div>Adrian</div><div><br></div><div>16:09:32.347 [info] Trailer upload failed with reason</div><div>{case_clause,{error,closed}}</div><div>16:09:32.348 [error] ** Cowboy handler upload_trailer_resource</div><div>terminating in handle/2</div><div>for the reason error:{case_clause,{error,closed}}</div><div>** Handler state was {state,undefined,0,undefined,undefined,undefined}</div><div>** Request was</div><div>[{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef</div><div>ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>">>},{<<"user-agent">>,<<"M</div><div>ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36</div><div>(KHTML,</div><div>like Gecko) Chrome/28.0.1500.71</div><div>Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce</div><div>pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;</div><div>id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde</div><div>fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]</div><div>** Stacktrace:</div><div>[{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}</div><div>,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo</div><div>ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]</div><div><br></div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>Extend mailing list</div><div>Extend@lists.ninenines.eu <<a href="mailto:Extend@lists.ninenines.eu">mailto:Extend@lists.ninenines.eu</a>></div><div><a href="http://lists.ninenines.eu:81/listinfo/extend">http://lists.ninenines.eu:81/listinfo/extend</a></div></div></blockquote><div><br></div><div><br></div><div>--</div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>--</div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></div></span>
+                 
+                 
+                 
+                 
+                </blockquote>
+                 
+                <div>
+                    <br>
+                </div>
+             + diff --git a/_build/static/archives/extend/attachments/20130718/c50bef17/attachment.html b/_build/static/archives/extend/attachments/20130718/c50bef17/attachment.html new file mode 100644 index 00000000..cf4bec2f --- /dev/null +++ b/_build/static/archives/extend/attachments/20130718/c50bef17/attachment.html @@ -0,0 +1,21 @@ + +
+                <div>
+                    <span style="font-size: 12px;">My issue is the other way round.  My handler crashes - and terminate gets called, but the linked process is NOT stopped (unless I stop it in terminate having stashed any processes I need to stop in the process dictionary - this is what I'm currently doing, but yuck!)</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">.  My question is whether it wouldn't be better to no re-use the handler process that has crashed and replace it so that handler's can use the canonical erlang way of stopping related processes rather than having to do it by hand.  </span>
+                </div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Obviously if the handler does not crash there's no need to kill the process, so the current efficiency saving works in the "normal" case/</span></div>
+                <div><div><br></div><div>-- </div><div>Dr Adrian Roe</div><div>Director<br></div><div><br></div></div>
+                 
+                <p style="color: #A0A0A8;">On Thursday, 18 July 2013 at 11:20, Loïc Hoguin wrote:</p>
+                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
+                    <span><div><div><div>I don't know what happens but there's two things I know:</div><div><br></div><div>  *  Handlers don't trap_exit, so if the linked process crashes, they </div><div>crash too</div><div>  *  If the handler crashes, we close the connection and stop the </div><div>handler; if not this is a bug</div><div><br></div><div>After your log message the handler should stop unless there's a bug </div><div>somewhere.</div><div><br></div><div>On 07/18/2013 12:15 PM, Adrian Roe wrote:</div><blockquote type="cite"><div><div>We have been using spawn_linked workers to handle tasks that live for</div><div>the lifetime of a single HTTP request</div><div><br></div><div>Although in the cowboy guide it is clear that Cowboy can use "One</div><div>Process of Many Requests" I am surprised that this is the case even if</div><div>the handler crashes.  For example, our use case is to copy a large file</div><div>to the server over HTTP where a worker process relays the file contents</div><div>to long term storage.  The worker process is spawn_linked from the HTTP</div><div>handler and (for our use case) should die if the handler stops.</div><div><br></div><div>If the client stops the upload (for example by browsing away, or losing</div><div>connectivity) we correctly receive an error (see sample Lager trace</div><div>below), but what we are seeing is that spawn_linked processes are NOT</div><div>being killed.</div><div><br></div><div>Is this intended behaviour - I accept it makes sense to reuse the</div><div>processes but should this continue to be the case even if the previous</div><div>use of the process crashed?  If it is intended behaviour I think the</div><div>docs should highlight this as we've been leaking processes for some time</div><div>now, but I've always seen it as erlang's job to look after related</div><div>process trees in the event of error.  Our current workaround is to hold</div><div>a list of linked processes in process storage and then kill them in the</div><div>terminate handler which is ugly in the extreme!!  We don't know the PIDS</div><div>of the linked processes until it is too late to return State to Cowboy</div><div>(i.e. we are already in our handle code)...</div><div><br></div><div>Kind regards</div><div><br></div><div>Adrian</div><div><br></div><div>16:09:32.347 [info] Trailer upload failed with reason</div><div>{case_clause,{error,closed}}</div><div>16:09:32.348 [error] ** Cowboy handler upload_trailer_resource</div><div>terminating in handle/2</div><div>    for the reason error:{case_clause,{error,closed}}</div><div>** Handler state was {state,undefined,0,undefined,undefined,undefined}</div><div>** Request was</div><div>[{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef</div><div>ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>">>},{<<"user-agent">>,<<"M</div><div>ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML,</div><div>like Gecko) Chrome/28.0.1500.71</div><div>Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"<a href="http://54.225.117.108:8000">http://54.225.117.108:8000</a>/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce</div><div>pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5;</div><div>id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde</div><div>fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]</div><div>** Stacktrace:</div><div>[{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}</div><div>,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo</div><div>ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]</div><div><br></div><div><br></div><div>--</div><div>Dr Adrian Roe</div><div>Director</div><div><br></div><div><br></div><div><br></div><div>_______________________________________________</div><div>Extend mailing list</div><div><a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a></div><div><a href="http://lists.ninenines.eu:81/listinfo/extend">http://lists.ninenines.eu:81/listinfo/extend</a></div></div></blockquote><div><br></div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></div></span>
+                 
+                 
+                 
+                 
+                </blockquote>
+                 
+                <div>
+                    <br>
+                </div>
+             + diff --git a/_build/static/archives/extend/attachments/20130718/d65f1aaf/attachment.html b/_build/static/archives/extend/attachments/20130718/d65f1aaf/attachment.html new file mode 100644 index 00000000..d6b4ddfa --- /dev/null +++ b/_build/static/archives/extend/attachments/20130718/d65f1aaf/attachment.html @@ -0,0 +1,8 @@ + +
+                <div>
+                    <div><span style="font-size: 12px;">We have been using spawn_linked workers to handle tasks that live for the lifetime of a single HTTP request</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Although in the cowboy guide it is clear that Cowboy can use "One Process of Many Requests" I am surprised that this is the case even if the handler crashes.  For example, our use case is to copy a large file to the server over HTTP where a worker process relays the file contents to long term storage.  The worker process is spawn_linked from the HTTP handler and (for our use case) should die if the handler stops.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">If the client stops the upload (for example by browsing away, or losing connectivity) we correctly receive an error (see sample Lager trace below), but what we are seeing is that spawn_linked processes are NOT being killed.</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Is this intended behaviour - I accept it makes sense to reuse the processes but should this continue to be the case even if the previous use of the process crashed?  If it is intended behaviour I think the docs should highlight this as we've been leaking processes for some time now, but I've always seen it as erlang's job to look after related process trees in the event of error.  Our current workaround is to hold a list of linked processes in process storage and then kill them in the terminate handler which is ugly in the extreme!!  We don't know the PIDS of the linked processes until it is too late to return State to Cowboy (i.e. we are already in our handle code)...</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Kind regards</span></div><div><span style="font-size: 12px;"><br></span></div><div><span style="font-size: 12px;">Adrian</span></div><div><br></div><div>16:09:32.347 [info] Trailer upload failed with reason {case_clause,{error,closed}}</div><div>16:09:32.348 [error] ** Cowboy handler upload_trailer_resource terminating in handle/2</div><div>   for the reason error:{case_clause,{error,closed}}</div><div>** Handler state was {state,undefined,0,undefined,undefined,undefined}</div><div>** Request was [{socket,#Port<0.11230>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1987.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{84,92,32,116},64136}},{host,<<"54.225.117.108">>},{host_info,undefined},{port,8000},{path,<<"/upload_trailer">>},{path_info,undef</div><div>ined},{qs,<<"name=linux-7.4.21.zip&size=54015414">>},{qs_vals,undefined},{bindings,[]},{headers,[{<<"host">>,<<"54.225.117.108:8000">>},{<<"connection">>,<<"keep-alive">>},{<<"content-length">>,<<"54015414">>},{<<"origin">>,<<"http://54.225.117.108:8000">>},{<<"user-agent">>,<<"M</div><div>ozilla/5.0 (Macintosh; Intel Mac OS X 10_8_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36">>},{<<"content-type">>,<<>>},{<<"accept">>,<<"*/*">>},{<<"referer">>,<<"http://54.225.117.108:8000/">>},{<<"accept-encoding">>,<<"gzip,deflate,sdch">>},{<<"acce</div><div>pt-language">>,<<"en-US,en;q=0.8">>},{<<"cookie">>,<<"__jwpusr=cbc133d7-1b49-443c-8a13-364660cc93e5; id3as_manager=f4803c004d71dde3b64394f6e6f44faa54970e93">>}]},{p_headers,[{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[]},{body_state,waiting},{multipart,unde</div><div>fined},{buffer,<<>>},{resp_compress,true},{resp_state,waiting},{resp_headers,[]},{resp_body,<<>>},{onresponse,undefined}]</div><div>** Stacktrace: [{i_cowboy,stream_body,0,[{file,"src/i_cowboy.erl"},{line,76}]},{upload_trailer_resource,stream_upload_file,4,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,247}]},{upload_trailer_resource,upload_file,1,[{file,"src/endpoints/upload_trailer_resource.erl"}</div><div>,{line,237}]},{upload_trailer_resource,head_or_post,1,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,202}]},{upload_trailer_resource,sequence,2,[{file,"src/endpoints/upload_trailer_resource.erl"},{line,106}]},{upload_trailer_resource,process_request,1,[{file,"src/endpo</div><div>ints/upload_trailer_resource.erl"},{line,212}]},{i_cowboy,do,3,[{file,"src/i_cowboy.erl"},{line,29}]},{cowboy_handler,handler_handle,4,[{file,"src/cowboy_handler.erl"},{line,119}]}]</div><div><br></div>
+                </div>
+                <div><div><br></div><div>-- </div><div>Dr Adrian Roe</div><div>Director<br></div><div><br></div></div>
+             + diff --git a/_build/static/archives/extend/attachments/20130723/3e51c337/attachment.html b/_build/static/archives/extend/attachments/20130723/3e51c337/attachment.html new file mode 100644 index 00000000..d60fe073 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130723/3e51c337/attachment.html @@ -0,0 +1,6 @@ + +What's the best way to skip is_authorized callback for OPTIONS methods? For all my rest handlers?<div><br></div><div>Thanks in advance for any help you are able to provide.<br clear="all"><div><br></div>-- <br><div dir="ltr">
+Eduardo<br></div>
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20130802/4f7baee0/attachment.html b/_build/static/archives/extend/attachments/20130802/4f7baee0/attachment.html new file mode 100644 index 00000000..b37ab6d1 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130802/4f7baee0/attachment.html @@ -0,0 +1,12 @@ + +Forgot to reply to all<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Eduardo Gurgel</b> <span dir="ltr"><<a href="mailto:edgurgel@gmail.com">edgurgel@gmail.com</a>></span><br>
+Date: Fri, Aug 2, 2013 at 4:57 PM<br>Subject: Re: [99s-extend] Mailing lists<br>To: Jeremy Ong <<a href="mailto:jeremy@quarkgames.com">jeremy@quarkgames.com</a>><br><br><br><br><br><div class="gmail_quote"><div class="im">
+On Fri, Aug 2, 2013 at 4:33 PM, Jeremy Ong <span dir="ltr"><<a href="mailto:jeremy@quarkgames.com" target="_blank">jeremy@quarkgames.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+Florent, I suggest you actually contribute something before telling<br>
+the project maintainer how to run things and flaming people who *have*<br>
+contributed.<br></blockquote><div><br></div></div><div>Agreed.</div><div></div><div>Too much pointing finger on this thread...</div></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div dir="ltr">Eduardo<br>
+</div>
+</font></span></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Eduardo<br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130805/9fd5783b/attachment.html b/_build/static/archives/extend/attachments/20130805/9fd5783b/attachment.html new file mode 100644 index 00000000..81109940 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130805/9fd5783b/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">></span><span style="font-family:arial,sans-serif;font-size:13px">You can think it's not a problem, but I</span><span style="font-family:arial,sans-serif;font-size:13px">think it is. Is that a flame ?</span><span style="font-family:arial,sans-serif;font-size:13px"><br>
+This is a flame:<br>> Haha, what a joke. It's a pity you don't understand that.<br></span><br>I for one, prefer Postgres. Not everything can be mapped to kv and that's the only thing Riak is good for. It's not fit for a general purpose database.<br>
+To me, NoSQL is about specialization. Each db excels at one type of operation (and then there's mongo, but that's for another time), while RDBMSs offer general purpose solutions. I begin my projects with an RDBMS (usually Postgres) and when a particular piece of data is the bottleneck, I move it to the appropriate NoSQL db.</div>
+ + diff --git a/_build/static/archives/extend/attachments/20130816/1c70f542/attachment.html b/_build/static/archives/extend/attachments/20130816/1c70f542/attachment.html new file mode 100644 index 00000000..a3f4959d --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/1c70f542/attachment.html @@ -0,0 +1,22 @@ + +<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":fq" style="overflow:hidden">I would like to make an official announcement of <a href="http://erlang.mk" target="_blank">erlang.mk</a> now that all the features I wanted are in.</div>
+
+</blockquote></div><br>I have been using <a href="http://erlang.mk">erlang.mk</a> for a while now, and recently I converted etorrent to use it as a test of the viability in larger projects. Typical gotchas:</div><div class="gmail_extra">
+
+<br></div><div class="gmail_extra">* Projects has no Makefile. <a href="http://erlang.mk">erlang.mk</a> needs one. So add one!</div><div class="gmail_extra">* No `modules` section in the .app file. <a href="http://erlang.mk">erlang.mk</a> needs one to replace it. Not adding this makes relx behave badly.</div>
+
+<div class="gmail_extra">* If you use relx, it is more strict in what it accepts.</div><div class="gmail_extra">* Relx can't yet overlay sys.config :/</div><div class="gmail_extra"><br></div><div class="gmail_extra">
+Apart from that, <a href="http://erlang.mk">erlang.mk</a> is a bliss to work with. In one project I am working with:</div>
+<div class="gmail_extra"><br></div><div class="gmail_extra">Core i5 2.4Ghz approx 2010 Macbook Pro, encrypted disk (this hurts performance like mad):</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cold build:</div>
+
+<div class="gmail_extra"><br></div><div class="gmail_extra">Rebar: 40 secs</div><div class="gmail_extra"><a href="http://elrang.mk">elrang.mk</a>: 42 secs</div><div class="gmail_extra"><br></div><div class="gmail_extra">
+Build where each file is compiled in advance:</div>
+<div class="gmail_extra"><br></div><div class="gmail_extra">Rebar: 20 secs</div><div class="gmail_extra"><a href="http://erlang.mk">erlang.mk</a>: 0.4 secs</div><div class="gmail_extra"><br></div><div class="gmail_extra">
+
+For my development cycle, this is important enough to spend time rewriting projects to use <a href="http://erlang.mk">erlang.mk</a>. Also note that rebar.config and <a href="http://erlang.mk">erlang.mk</a> can co-exist, so you don't need to abandon rebar for <a href="http://erlang.mk">erlang.mk</a>, which is important.</div>
+
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20130816/1cd82d09/attachment.html b/_build/static/archives/extend/attachments/20130816/1cd82d09/attachment.html new file mode 100644 index 00000000..3d637f54 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/1cd82d09/attachment.html @@ -0,0 +1,21 @@ + +
+                <div>
+                    Was guessing that was the answer - I'll give it a go...
+                </div>
+                <div><div><br></div><div>-- </div><div>Steve Strong</div><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
+                 
+                <p style="color: #A0A0A8;">On Friday, 16 August 2013 at 16:42, Loïc Hoguin wrote:</p>
+                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
+                    <span><div><div><div>Well I'm sure if you create a base Makefile (without erlang.mk) that </div><div>exports DEPS_DIR and then call $(MAKE) on all folders in /apps (which </div><div>would themselves contain Makefiles that use erlang.mk), it would work </div><div>just fine. You can still keep only one erlang.mk in your repos and use </div><div>include ../../erlang.mk instead for example.</div><div><br></div><div>But know that this folder structure is a rebar thing and not standard </div><div>(just like /deps you'll say, but that one is insanely useful regardless </div><div>of the project structure otherwise).</div><div><br></div><div>On 08/16/2013 02:27 PM, Steve Strong wrote:</div><blockquote type="cite"><div><div>Looks good - I like simple!  Quick question, does it support multiple</div><div>applications, for example a project laid out as:</div><div><br></div><div>/proj</div><div>/deps</div><div>/stuff</div><div><br></div><div>/apps</div><div>/app1</div><div>/app2</div><div><br></div><div>Most of our stuff is in that form, with shared dependencies between the</div><div>various apps.  Rebar is quite happy with that format, but I can't see</div><div>how to persuade erlang.mk to handle that.</div><div><br></div><div>Cheers,</div><div><br></div><div>Steve</div><div><br></div><div>--</div><div>Steve Strong</div><div>Sent with Sparrow <<a href="http://www.sparrowmailapp.com/?sig">http://www.sparrowmailapp.com/?sig</a>></div><div><br></div><div>On Thursday, 15 August 2013 at 16:19, Loïc Hoguin wrote:</div><div><br></div><blockquote type="cite"><div><div>Hello friendly people,</div><div><br></div><div>I would like to make an official announcement of erlang.mk now that all</div><div>the features I wanted are in.</div><div><br></div><div>erlang.mk is a rebar replacement. It was initially created for allowing</div><div>a faster development process than rebar and for better compatibility</div><div>with Linux build tools. It should work on Linux and OSX with GNU Make</div><div>installed.</div><div><br></div><div>Projects using erlang.mk are still compatible with rebar. Dependencies</div><div>fetched by rebar are stored in the same deps/ directory, and projects</div><div>using erlang.mk can still be used as rebar dependencies, with or without</div><div>a rebar.config file.</div><div><br></div><div>erlang.mk also features a simple package index. Try `make pkg-list` to</div><div>list all packages currently available. All the packages listed are</div><div>compatible with erlang.mk with no tweaking required.</div><div><br></div><div>Makefiles written with erlang.mk are *VERY* simple, here are two examples:</div><div><br></div><div>* <a href="https://github.com/extend/farwest/blob/master/Makefile">https://github.com/extend/farwest/blob/master/Makefile</a></div><div>* <a href="https://github.com/extend/cowboy/blob/master/Makefile">https://github.com/extend/cowboy/blob/master/Makefile</a></div><div><br></div><div>I wrote about erlang.mk and relx recently on the Nine Nines blog.</div><div>erlang.mk is the perfect companion to relx.</div><div><br></div><div>* <a href="http://ninenines.eu/articles/erlang.mk-and-relx">http://ninenines.eu/articles/erlang.mk-and-relx</a></div><div><br></div><div>Here are examples of projects that are using and compatible with</div><div>erlang.mk:</div><div><br></div><div>* <a href="https://github.com/jlouis/etorrent">https://github.com/jlouis/etorrent</a></div><div>* <a href="https://github.com/extend/cowboy">https://github.com/extend/cowboy</a></div><div>* <a href="https://github.com/extend/farwest">https://github.com/extend/farwest</a></div><div><br></div><div>You can find erlang.mk at the following URL:</div><div><br></div><div>* <a href="https://github.com/extend/erlang.mk">https://github.com/extend/erlang.mk</a></div><div><br></div><div>Contributions to the package index are of course welcome! The only</div><div>requirement is that the package is to be compatible with erlang.mk</div><div>itself. Just send a PR to the erlang.mk project updating the</div><div>packages.v1.txt!</div><div><br></div><div>Enjoy!</div><div><br></div><div>--</div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div>erlang-questions@erlang.org <<a href="mailto:erlang-questions@erlang.org">mailto:erlang-questions@erlang.org</a>></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></blockquote></div></blockquote><div><br></div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div></div></div></span>
+                 
+                 
+                 
+                 
+                </blockquote>
+                 
+                <div>
+                    <br>
+                </div>
+             + diff --git a/_build/static/archives/extend/attachments/20130816/4e596577/attachment.html b/_build/static/archives/extend/attachments/20130816/4e596577/attachment.html new file mode 100644 index 00000000..1577f65e --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/4e596577/attachment.html @@ -0,0 +1,218 @@ + +<html>
+  <head>
+    <meta content="text/html; charset=ISO-8859-1"
+      http-equiv="Content-Type">
+  </head>
+  <body text="#000000" bgcolor="#FFFFFF">
+    <div class="moz-cite-prefix">Why not use Erlang for downloading?
+      Surely if erlang.mk is a tool for Erlang then it will be very
+      likely installed. For example this target downloads Rebar:<br>
+      <br>
+      <pre style="font-family: Consolas, 'Liberation Mono', Courier, monospace; font-size: 12px; margin-top: 0px; margin-bottom: 0px; color: rgb(51, 51, 51); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: 18px; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="line" id="LC5" style="padding-left: 10px;"># Erlang Rebar downloading, see:</div><div class="line" id="LC6" style="padding-left: 10px;"># <a class="moz-txt-link-freetext" href="https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y">https://groups.google.com/forum/?fromgroups=#!topic/erlang-programming/U0JJ3SeUv5Y</a></div><div class="line" id="LC7" style="padding-left: 10px;">rb_rebar_url=<a class="moz-txt-link-freetext" href="http://cloud.github.com/downloads/basho/rebar/rebar">http://cloud.github.com/downloads/basho/rebar/rebar</a></div><div cl
+ass="line" id="LC8" style="padding-left: 10px;">
+</div><div class="line" id="LC9" style="padding-left: 10px;">./rebar:</div><div class="line" id="LC10" style="padding-left: 10px;"> $(ERL) -noshell -s inets -s ssl \</div><div class="line" id="LC11" style="padding-left: 10px;">         -eval 'httpc:request(get, {"$(rb_rebar_url)", []}, [], [{stream, "./rebar"}])' \</div><div class="line" id="LC12" style="padding-left: 10px;">    -s init stop</div><div class="line" id="LC13" style="padding-left: 10px;">  chmod +x ./rebar</div><div class="line" id="LC14" style="padding-left: 10px;">
+</div><div class="line" id="LC15" style="padding-left: 10px;">REBAR=$(shell (type rebar 2>/dev/null || echo ./rebar) | tail -1 | awk '{ print $$NF }')</div></pre>
+      <br>
+      It could be used to download anything, not just REBAR.<br>
+      <br>
+      - Greg<br>
+      <br>
+      <br>
+      On 16/08/2013 15:34, Loïc Hoguin wrote:<br>
+    </div>
+    <blockquote cite="mid:520E3890.5020000@ninenines.eu" type="cite">On
+      08/16/2013 10:39 AM, Benoit Chesneau wrote:
+      <br>
+      <blockquote type="cite">The big problem with erlang.mk
+        <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> is requiring to have
+        <br>
+        gmake and more importantly wget installed imo.
+        <br>
+      </blockquote>
+      <br>
+      wget is only used for fetching the package index file. I'm sure if
+      it doesn't work somewhere it'll be patched eventually.
+      <br>
+      <br>
+      <blockquote type="cite">Which makes it quite annoying to
+        distribute on systems that have none of
+        <br>
+        them. It would be interrestin to have the support for curl for
+        example.
+        <br>
+        Also what are the makefile extensions that you really need to
+        require gmake?
+        <br>
+      </blockquote>
+      <br>
+      No idea. Patches are welcome for compatibility with different
+      OS/build tools (as long as it's not "rewrite the whole file" of
+      course, then you're better off just using gmake).
+      <br>
+      <br>
+      <blockquote type="cite">- benoit
+        <br>
+        <br>
+        <br>
+        On Thu, Aug 15, 2013 at 4:19 PM, Loïc Hoguin
+        <<a class="moz-txt-link-abbreviated" href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>
+        <br>
+        <a class="moz-txt-link-rfc2396E" href="mailto:essen@ninenines.eu"><mailto:essen@ninenines.eu></a>> wrote:
+        <br>
+        <br>
+            Hello friendly people,
+        <br>
+        <br>
+            I would like to make an official announcement of erlang.mk
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> now that all the features I wanted
+        are in.
+        <br>
+        <br>
+            erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> is a rebar replacement.
+        It was
+        <br>
+            initially created for allowing a faster development process
+        than
+        <br>
+            rebar and for better compatibility with Linux build tools.
+        It should
+        <br>
+            work on Linux and OSX with GNU Make installed.
+        <br>
+        <br>
+            Projects using erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> are still
+        compatible
+        <br>
+            with rebar. Dependencies fetched by rebar are stored in the
+        same
+        <br>
+            deps/ directory, and projects using erlang.mk
+        <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> can
+        <br>
+            still be used as rebar dependencies, with or without a
+        rebar.config
+        <br>
+            file.
+        <br>
+        <br>
+            erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> also features a simple
+        package index.
+        <br>
+            Try `make pkg-list` to list all packages currently
+        available. All
+        <br>
+            the packages listed are compatible with erlang.mk
+        <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a>
+        <br>
+            with no tweaking required.
+        <br>
+        <br>
+            Makefiles written with erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a>
+        are *VERY*
+        <br>
+            simple, here are two examples:
+        <br>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/extend/__farwest/blob/master/Makefile">https://github.com/extend/__farwest/blob/master/Makefile</a>
+        <br>
+           
+        <a class="moz-txt-link-rfc2396E" href="https://github.com/extend/farwest/blob/master/Makefile"><https://github.com/extend/farwest/blob/master/Makefile></a>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/extend/__cowboy/blob/master/Makefile">https://github.com/extend/__cowboy/blob/master/Makefile</a>
+        <br>
+           
+        <a class="moz-txt-link-rfc2396E" href="https://github.com/extend/cowboy/blob/master/Makefile"><https://github.com/extend/cowboy/blob/master/Makefile></a>
+        <br>
+        <br>
+            I wrote about erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> and relx
+        recently on the
+        <br>
+            Nine Nines blog. erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> is the
+        perfect
+        <br>
+            companion to relx.
+        <br>
+        <br>
+              * <a class="moz-txt-link-freetext" href="http://ninenines.eu/articles/__erlang.mk-and-relx">http://ninenines.eu/articles/__erlang.mk-and-relx</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="http://ninenines.eu/articles/erlang.mk-and-relx"><http://ninenines.eu/articles/erlang.mk-and-relx></a>
+        <br>
+        <br>
+            Here are examples of projects that are using and compatible
+        with
+        <br>
+            erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a>:
+        <br>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/jlouis/__etorrent">https://github.com/jlouis/__etorrent</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="https://github.com/jlouis/etorrent"><https://github.com/jlouis/etorrent></a>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/extend/__cowboy">https://github.com/extend/__cowboy</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="https://github.com/extend/cowboy"><https://github.com/extend/cowboy></a>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/extend/__farwest">https://github.com/extend/__farwest</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="https://github.com/extend/farwest"><https://github.com/extend/farwest></a>
+        <br>
+        <br>
+            You can find erlang.mk <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> at the
+        following URL:
+        <br>
+        <br>
+              * <a class="moz-txt-link-freetext" href="https://github.com/extend/__erlang.mk">https://github.com/extend/__erlang.mk</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="https://github.com/extend/erlang.mk"><https://github.com/extend/erlang.mk></a>
+        <br>
+        <br>
+            Contributions to the package index are of course welcome!
+        The only
+        <br>
+            requirement is that the package is to be compatible with
+        erlang.mk
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> itself. Just send a PR to the
+        erlang.mk
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="http://erlang.mk"><http://erlang.mk></a> project updating the
+        packages.v1.txt!
+        <br>
+        <br>
+            Enjoy!
+        <br>
+        <br>
+            --
+        <br>
+            Loïc Hoguin
+        <br>
+            Erlang Cowboy
+        <br>
+            Nine Nines
+        <br>
+            <a class="moz-txt-link-freetext" href="http://ninenines.eu">http://ninenines.eu</a>
+        <br>
+            _________________________________________________
+        <br>
+            erlang-questions mailing list
+        <br>
+            <a class="moz-txt-link-abbreviated" href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a>
+        <a class="moz-txt-link-rfc2396E" href="mailto:erlang-questions@erlang.org"><mailto:erlang-questions@erlang.org></a>
+        <br>
+            <a class="moz-txt-link-freetext" href="http://erlang.org/mailman/__listinfo/erlang-questions">http://erlang.org/mailman/__listinfo/erlang-questions</a>
+        <br>
+            <a class="moz-txt-link-rfc2396E" href="http://erlang.org/mailman/listinfo/erlang-questions"><http://erlang.org/mailman/listinfo/erlang-questions></a>
+        <br>
+        <br>
+        <br>
+      </blockquote>
+      <br>
+      <br>
+    </blockquote>
+    <br>
+  </body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130816/8f4a69b4/attachment.html b/_build/static/archives/extend/attachments/20130816/8f4a69b4/attachment.html new file mode 100644 index 00000000..e776ff95 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/8f4a69b4/attachment.html @@ -0,0 +1,77 @@ + +<div dir="ltr"><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">I believe</span></div><span class="" style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre"><span style="font-weight:normal">curl -L</span><span style="font-weight:normal"> </span><span class="">$(</span><span style="font-weight:normal">PKG_FILE_URL</span><span class="">)</span></span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre"> ></span><span class="" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;font-weight:bold;line-height:18px;white-space:pre">$(</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">PKG_FILE</span><span class="" style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;font-weight:bold;line-height:18px;white-space:pre">)<br>
+
+</span><div>is kinda drop-in replacement for</div><div><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">wget -O </span><span class="" style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">$(</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">PKG_FILE</span><span class="" style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">)</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre"> </span><span class="" style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">$(</span><span style="color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">PKG_FILE_URL</span><span class="" style="font-weight:bold;color:rgb(51,51,51);font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;line-height:18px;white-space:pre">)</span><br>
+
+</div><div>used in <a href="http://erlang.mk">erlang.mk</a>.</div><div><br></div><div>Should be tested</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 16, 2013 at 12:39 PM, Benoit Chesneau <span dir="ltr"><<a href="mailto:bchesneau@gmail.com" target="_blank">bchesneau@gmail.com</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The big problem with <a href="http://erlang.mk" target="_blank">erlang.mk</a> is requiring to have gmake and more importantly wget installed imo.<div>
+
+<br></div><div>Which makes it quite annoying to distribute on systems that have none of them. It would be interrestin to have the support for curl for example. Also what are the makefile extensions that you really need to require gmake?<span class="HOEnZb"><font color="#888888"><div>
+
+
+<br></div><div>- benoit</div></font></span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Thu, Aug 15, 2013 at 4:19 PM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+
+</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello friendly people,<br>
+<br>
+I would like to make an official announcement of <a href="http://erlang.mk" target="_blank">erlang.mk</a> now that all the features I wanted are in.<br>
+<br>
+<a href="http://erlang.mk" target="_blank">erlang.mk</a> is a rebar replacement. It was initially created for allowing a faster development process than rebar and for better compatibility with Linux build tools. It should work on Linux and OSX with GNU Make installed.<br>
+
+
+
+<br>
+Projects using <a href="http://erlang.mk" target="_blank">erlang.mk</a> are still compatible with rebar. Dependencies fetched by rebar are stored in the same deps/ directory, and projects using <a href="http://erlang.mk" target="_blank">erlang.mk</a> can still be used as rebar dependencies, with or without a rebar.config file.<br>
+
+
+
+<br>
+<a href="http://erlang.mk" target="_blank">erlang.mk</a> also features a simple package index. Try `make pkg-list` to list all packages currently available. All the packages listed are compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a> with no tweaking required.<br>
+
+
+
+<br>
+Makefiles written with <a href="http://erlang.mk" target="_blank">erlang.mk</a> are *VERY* simple, here are two examples:<br>
+<br>
+* <a href="https://github.com/extend/farwest/blob/master/Makefile" target="_blank">https://github.com/extend/<u></u>farwest/blob/master/Makefile</a><br>
+* <a href="https://github.com/extend/cowboy/blob/master/Makefile" target="_blank">https://github.com/extend/<u></u>cowboy/blob/master/Makefile</a><br>
+<br>
+I wrote about <a href="http://erlang.mk" target="_blank">erlang.mk</a> and relx recently on the Nine Nines blog. <a href="http://erlang.mk" target="_blank">erlang.mk</a> is the perfect companion to relx.<br>
+<br>
+* <a href="http://ninenines.eu/articles/erlang.mk-and-relx" target="_blank">http://ninenines.eu/articles/<u></u>erlang.mk-and-relx</a><br>
+<br>
+Here are examples of projects that are using and compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a>:<br>
+<br>
+* <a href="https://github.com/jlouis/etorrent" target="_blank">https://github.com/jlouis/<u></u>etorrent</a><br>
+* <a href="https://github.com/extend/cowboy" target="_blank">https://github.com/extend/<u></u>cowboy</a><br>
+* <a href="https://github.com/extend/farwest" target="_blank">https://github.com/extend/<u></u>farwest</a><br>
+<br>
+You can find <a href="http://erlang.mk" target="_blank">erlang.mk</a> at the following URL:<br>
+<br>
+* <a href="https://github.com/extend/erlang.mk" target="_blank">https://github.com/extend/<u></u>erlang.mk</a><br>
+<br>
+Contributions to the package index are of course welcome! The only requirement is that the package is to be compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a> itself. Just send a PR to the <a href="http://erlang.mk" target="_blank">erlang.mk</a> project updating the packages.v1.txt!<br>
+
+
+
+<br>
+Enjoy!<span><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</font></span></blockquote></div></div></div><br></div>
+<br>_______________________________________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
+<br></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130816/a886396a/attachment.html b/_build/static/archives/extend/attachments/20130816/a886396a/attachment.html new file mode 100644 index 00000000..276b6812 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/a886396a/attachment.html @@ -0,0 +1,21 @@ + +
+                <div>
+                    Looks good - I like simple!  Quick question, does it support multiple applications, for example a project laid out as:
+                </div><div><br></div><div>/proj</div><div><span class="Apple-tab-span" style="white-space:pre">     </span>/deps</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>/stuff</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">      </span>/apps</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>/app1</div><div><span class="Apple-tab-span" style="white-space:pre">                </span>/app2</div><div><br></div><div>Most of our stuff is in that form, with shared dependencies between the various apps.  Rebar is quite happy with that format, but I can't see how to persuade erlang.mk to handle that.</div><div><br></div><div>Cheers,</div><div><br></div><div>Steve</div>
+                <div><div><br></div><div>-- </div><div>Steve Strong</div><div>Sent with <a href="http://www.sparrowmailapp.com/?sig">Sparrow</a></div><div><br></div></div>
+                 
+                <p style="color: #A0A0A8;">On Thursday, 15 August 2013 at 16:19, Loïc Hoguin wrote:</p>
+                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
+                    <span><div><div><div>Hello friendly people,</div><div><br></div><div>I would like to make an official announcement of erlang.mk now that all </div><div>the features I wanted are in.</div><div><br></div><div>erlang.mk is a rebar replacement. It was initially created for allowing </div><div>a faster development process than rebar and for better compatibility </div><div>with Linux build tools. It should work on Linux and OSX with GNU Make </div><div>installed.</div><div><br></div><div>Projects using erlang.mk are still compatible with rebar. Dependencies </div><div>fetched by rebar are stored in the same deps/ directory, and projects </div><div>using erlang.mk can still be used as rebar dependencies, with or without </div><div>a rebar.config file.</div><div><br></div><div>erlang.mk also features a simple package index. Try `make pkg-list` to </div><div>list all packages currently available. All the packages listed are </div><div>compatible with erlang.mk with no tweaking required.</div><div><br></div><div>Makefiles written with erlang.mk are *VERY* simple, here are two examples:</div><div><br></div><div>  *  <a href="https://github.com/extend/farwest/blob/master/Makefile">https://github.com/extend/farwest/blob/master/Makefile</a></div><div>  *  <a href="https://github.com/extend/cowboy/blob/master/Makefile">https://github.com/extend/cowboy/blob/master/Makefile</a></div><div><br></div><div>I wrote about erlang.mk and relx recently on the Nine Nines blog. </div><div>erlang.mk is the perfect companion to relx.</div><div><br></div><div>  *  <a href="http://ninenines.eu/articles/erlang.mk-and-relx">http://ninenines.eu/articles/erlang.mk-and-relx</a></div><div><br></div><div>Here are examples of projects that are using and compatible with erlang.mk:</div><div><br></div><div>  *  <a href="https://github.com/jlouis/etorrent">https://github.com/jlouis/etorrent</a></div><div>  *  <a href="https://github.com/extend/cowboy">https://github.com/extend/cowboy</a></div><div>  *  <a href="https://github.com/extend/farwest">https://github.com/extend/farwest</a></div><div><br></div><div>You can find erlang.mk at the following URL:</div><div><br></div><div>  *  <a href="https://github.com/extend/erlang.mk">https://github.com/extend/erlang.mk</a></div><div><br></div><div>Contributions to the package index are of course welcome! The only </div><div>requirement is that the package is to be compatible with erlang.mk </div><div>itself. Just send a PR to the erlang.mk project updating the </div><div>packages.v1.txt!</div><div><br></div><div>Enjoy!</div><div><br></div><div>-- </div><div>Loïc Hoguin</div><div>Erlang Cowboy</div><div>Nine Nines</div><div><a href="http://ninenines.eu">http://ninenines.eu</a></div><div>_______________________________________________</div><div>erlang-questions mailing list</div><div><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a></div><div><a href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/listinfo/erlang-questions</a></div></div></div></span>
+                 
+                 
+                 
+                 
+                </blockquote>
+                 
+                <div>
+                    <br>
+                </div>
+             + diff --git a/_build/static/archives/extend/attachments/20130816/ff4591a1/attachment.html b/_build/static/archives/extend/attachments/20130816/ff4591a1/attachment.html new file mode 100644 index 00000000..d4518dcb --- /dev/null +++ b/_build/static/archives/extend/attachments/20130816/ff4591a1/attachment.html @@ -0,0 +1,52 @@ + +<div dir="ltr">The big problem with <a href="http://erlang.mk">erlang.mk</a> is requiring to have gmake and more importantly wget installed imo.<div><br></div><div>Which makes it quite annoying to distribute on systems that have none of them. It would be interrestin to have the support for curl for example. Also what are the makefile extensions that you really need to require gmake?<div>
+<br></div><div>- benoit</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 4:19 PM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello friendly people,<br>
+<br>
+I would like to make an official announcement of <a href="http://erlang.mk" target="_blank">erlang.mk</a> now that all the features I wanted are in.<br>
+<br>
+<a href="http://erlang.mk" target="_blank">erlang.mk</a> is a rebar replacement. It was initially created for allowing a faster development process than rebar and for better compatibility with Linux build tools. It should work on Linux and OSX with GNU Make installed.<br>
+
+<br>
+Projects using <a href="http://erlang.mk" target="_blank">erlang.mk</a> are still compatible with rebar. Dependencies fetched by rebar are stored in the same deps/ directory, and projects using <a href="http://erlang.mk" target="_blank">erlang.mk</a> can still be used as rebar dependencies, with or without a rebar.config file.<br>
+
+<br>
+<a href="http://erlang.mk" target="_blank">erlang.mk</a> also features a simple package index. Try `make pkg-list` to list all packages currently available. All the packages listed are compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a> with no tweaking required.<br>
+
+<br>
+Makefiles written with <a href="http://erlang.mk" target="_blank">erlang.mk</a> are *VERY* simple, here are two examples:<br>
+<br>
+* <a href="https://github.com/extend/farwest/blob/master/Makefile" target="_blank">https://github.com/extend/<u></u>farwest/blob/master/Makefile</a><br>
+* <a href="https://github.com/extend/cowboy/blob/master/Makefile" target="_blank">https://github.com/extend/<u></u>cowboy/blob/master/Makefile</a><br>
+<br>
+I wrote about <a href="http://erlang.mk" target="_blank">erlang.mk</a> and relx recently on the Nine Nines blog. <a href="http://erlang.mk" target="_blank">erlang.mk</a> is the perfect companion to relx.<br>
+<br>
+* <a href="http://ninenines.eu/articles/erlang.mk-and-relx" target="_blank">http://ninenines.eu/articles/<u></u>erlang.mk-and-relx</a><br>
+<br>
+Here are examples of projects that are using and compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a>:<br>
+<br>
+* <a href="https://github.com/jlouis/etorrent" target="_blank">https://github.com/jlouis/<u></u>etorrent</a><br>
+* <a href="https://github.com/extend/cowboy" target="_blank">https://github.com/extend/<u></u>cowboy</a><br>
+* <a href="https://github.com/extend/farwest" target="_blank">https://github.com/extend/<u></u>farwest</a><br>
+<br>
+You can find <a href="http://erlang.mk" target="_blank">erlang.mk</a> at the following URL:<br>
+<br>
+* <a href="https://github.com/extend/erlang.mk" target="_blank">https://github.com/extend/<u></u>erlang.mk</a><br>
+<br>
+Contributions to the package index are of course welcome! The only requirement is that the package is to be compatible with <a href="http://erlang.mk" target="_blank">erlang.mk</a> itself. Just send a PR to the <a href="http://erlang.mk" target="_blank">erlang.mk</a> project updating the packages.v1.txt!<br>
+
+<br>
+Enjoy!<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130820/b203ebe2/attachment.html b/_build/static/archives/extend/attachments/20130820/b203ebe2/attachment.html new file mode 100644 index 00000000..43c2369f --- /dev/null +++ b/_build/static/archives/extend/attachments/20130820/b203ebe2/attachment.html @@ -0,0 +1,32 @@ + +<div dir="ltr">This is exactly the sort of thing gen_event is for. I would make each server process register a handler at startup using gen_event:add_sup_handler() and then have the handle_event callback simply relay the event to the server processes. Yes, gproc can do this, but why incur its extra features and overhead?<div class="gmail_extra">
+<br><br><div class="gmail_quote">On Sat, Aug 17, 2013 at 3:10 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div class="im">On 08/17/2013 10:00 AM, Bin Wang wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hi,<br>
+<br>
+I'm new to ranch. In my application, I need to send some message to<br>
+all connections. So I'd like to know can I get all connections from<br>
+ranch, so I could use Transport:send to send them, or I must manage<br>
+all the created connections by myself? Or is there any other better<br>
+way?<br>
+</blockquote>
+<br></div>
+The best way to do that is on your end, using gproc properties. When the connection is accepted, register the process with the property and use the property to send messages to all processes. You don't need to unregister when the connection ends, gproc does that automatically.<br>
+
+<br>
+The hackish way to do that would be to call supervisor:which_children on the ranch_conns_sup supervisor of your listener, but that will slow down the accepting of new connections, so don't do this if you need high accept rates.<span class="HOEnZb"><font color="#888888"><br>
+
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a></font></span><div class="HOEnZb"><div class="h5"><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</div></div></blockquote></div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130915/c9a5340e/attachment.html b/_build/static/archives/extend/attachments/20130915/c9a5340e/attachment.html new file mode 100644 index 00000000..da26eac3 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130915/c9a5340e/attachment.html @@ -0,0 +1,10 @@ + +<div dir="ltr">Hi,<div><br></div><div>I've started work on a project using Clojure, but I was wondering whether (and secretly hoping that) Erlang would be a better fit, so I've been load testing a few web server frameworks. I'm particularly interested in how the server can handle a large number of concurrent WebSocket connections, and the test I've been running is similar to Eric Moritz's [1].</div>
+<div><br></div><div>I've setup a simple Cowboy 'echo' server running on an EC2 instance (m1.medium, as in Eric's test) which could comfortably handle 10k concurrent WebSocket requests (as in Eric's results), while echoing about 200 messages/second. The CPU usage of the VM at this point is about 99%, but the server continues to handle up to 40k concurrent connections with a consistent average response time (<30ms). Pushing the test beyond this number results in a spike in response times and lots of connection timeouts.</div>
+<div><br></div><div>40k connections seems pretty good, but when comparing this to the same test against a couple of Clojure/JVM-based frameworks (specifically Aleph/Netty and http-kit) I find I can get higher numbers of concurrent connections with slightly better average response times (100k connections, <10ms response time) using much less CPU (~20%). In fact, memory seems to be the limiting factor.</div>
+<div><br></div><div>So I have two questions:</div><div><br></div><div>1) Should I be concerned about the CPU usage in the Erlang/Cowboy test? I have limited experience with Erlang so far, but 100% CPU feels like a bad thing.</div>
+<div><br></div><div>2) Is there any way to increase the performance of the cowboy server? Are there any Erlang VM parameters I can change? The fact that the Clojure/JVM tests (on the same machine) have managed to get to 100k connections suggests that the limitation isn't being imposed by the operating system (I've applied changes various changes to sysctl and ulimit).</div>
+<div><br></div><div>(Perhaps an echo server isn't the best way to compare HTTP servers, but it feels like a good starting point.)</div><div><br></div><div>Thanks for any help.</div><div><br></div><div>[1]<a href="https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md">https://github.com/ericmoritz/wsdemo/blob/results-v1/results.md</a> - the GitHub repo actually contains code for an Aleph server, but results from this aren't included in the summary here.<br clear="all">
+<div><br></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130916/dedbf486/attachment.html b/_build/static/archives/extend/attachments/20130916/dedbf486/attachment.html new file mode 100644 index 00000000..74676d52 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130916/dedbf486/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">Hello,<div><br></div><div>this is somewhat similar to what someone else has asked: <a href="http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html">http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html</a></div>
+<div><br></div><div>I am new to cowboy, I have a process that runs alongside a cowboy server and this process needs to periodically send text to all http clients connected to the cowboy server. My goal is to have a streaming connection for each http client so that I could stream text to them from my process. how is this done?</div>
+<div><br></div><div>Thanks!</div><div>Konstantin</div><div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130916/f55d10f5/attachment.html b/_build/static/archives/extend/attachments/20130916/f55d10f5/attachment.html new file mode 100644 index 00000000..f2a6ab12 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130916/f55d10f5/attachment.html @@ -0,0 +1,29 @@ + +<div dir="ltr">thanks. Suppose my external process is registered and has a name, so I can discover it by name from my cowboy request handler. when my cowboy handler is invoked, can I just send the handler's process ID to the external process? the question is then how does the external process know that the http client has disconnected so that it can stop sending data to it.</div>
+<div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/16 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div class="HOEnZb"><div class="h5">On 09/16/2013 03:50 PM, akonsu wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hello,<br>
+<br>
+this is somewhat similar to what someone else has asked:<br>
+<a href="http://lists.ninenines.eu:81/archives/extend/2013-August/000224.html" target="_blank">http://lists.ninenines.eu:81/<u></u>archives/extend/2013-August/<u></u>000224.html</a><br>
+<br>
+I am new to cowboy, I have a process that runs alongside a cowboy server<br>
+and this process needs to periodically send text to all http clients<br>
+connected to the cowboy server. My goal is to have a streaming<br>
+connection for each http client so that I could stream text to them from<br>
+my process. how is this done?<br>
+</blockquote>
+<br></div></div>
+Same answer really. You need some kind of process registry, like gproc properties for example, that will store all Pids and allow you to send a message to all of them.<br>
+<br>
+On init, register the process, and then handle the incoming message when it arrives.<span class="HOEnZb"><font color="#888888"><br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130919/0a4bcb6c/attachment.html b/_build/static/archives/extend/attachments/20130919/0a4bcb6c/attachment.html new file mode 100644 index 00000000..74916ad3 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130919/0a4bcb6c/attachment.html @@ -0,0 +1,42 @@ + +<div dir="ltr">my http handler receives messages carrying json parts obtained from a twitter stream by a separate process. the twitter stream is the stream of all public tweets, (they call it "firehose") so there are a lot.</div>
+<div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/19 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+How much is a lot of messages?<br>
+<br>
+Hibernating is a bit more expensive on the CPU but better for saving memory. It's generally fine to use except when you have a really busy system. Do note that it also means your responses will be slightly slower (though that is generally not noticeable).<div>
+<div class="h5"><br>
+<br>
+On 09/19/2013 06:30 AM, akonsu wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hello,<br>
+<br>
+from the documentation:<br>
+<br>
+info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}| {loop,<br>
+Req, State, hibernate}<br>
+<br>
+<br>
+in case my handler receives a lot of messages, and they come very often,<br>
+does a response of the latter form {loop, Req, State, hibernate} save<br>
+anything? Can hibernating in this case actually hinder performance?<br>
+<br>
+thanks<br>
+Konstantin<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130919/9614ef5e/attachment.html b/_build/static/archives/extend/attachments/20130919/9614ef5e/attachment.html new file mode 100644 index 00000000..15f752b8 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130919/9614ef5e/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">Hello,<div><br></div><div>from the documentation:</div><div><br></div><div>info(Info, Req, State) -> {ok, Req, State} | {loop, Req, State}<span class="" style="white-space:pre">     </span>| {loop, Req, State, hibernate}<br>
+</div><div><br></div><div><br></div><div>in case my handler receives a lot of messages, and they come very often, does a response of the latter form {loop, Req, State, hibernate} save anything? Can hibernating in this case actually hinder performance?</div>
+<div><br></div><div>thanks</div><div>Konstantin</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130920/32352505/attachment.html b/_build/static/archives/extend/attachments/20130920/32352505/attachment.html new file mode 100644 index 00000000..d2c317ee --- /dev/null +++ b/_build/static/archives/extend/attachments/20130920/32352505/attachment.html @@ -0,0 +1,49 @@ + +<div dir="ltr">thanks!<div><br></div><div>how to implement timeout callback manually? if I had receive then I would just use timeout clause there, but with the handler I do not know...<br><div><br></div><div>I have doubts about validity of my question on the erlang list.  I later realised that there is no problem receiving messages in my handler from my upstream process, I can do it fast enough and shove everything to the response. my real problem is to determine if the http client is reading fast enough from the response...</div>
+</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/20 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Loop handlers close after a while regardless of what you send, it only checks what the client sends. The best way for you would be to disable that timeout and handle it manually.<br>
+<br>
+As for the second question, I'm still reading the thread on erlang-questions but I've seen some good ideas about timestamps so far.<div><div class="h5"><br>
+<br>
+On 09/20/2013 08:47 PM, akonsu wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hi,<br>
+<br>
+I am using loop handler and I stream from it:<br>
+<br>
+info({stream, Part}, Req, S) -><br>
+     ok = cowboy_req:chunk(Part, Req),<br>
+     {loop, Req, S, hibernate};<br>
+<br>
+I have two questions:<br>
+<br>
+1. on timeouts cowboy sends 204 No Content. In my case it is not the<br>
+right response because I may have already sent some data. Is there a way<br>
+to send a custom response?<br>
+<br>
+2. how to check if the client is too slow and is not reading the<br>
+response stream fast enough? If this happens, then I need to disconnect.<br>
+<br>
+I can live without 1. but I need to figure out 2. Please help.<br>
+<br>
+thank you!<br>
+Konstantin<br>
+<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130920/4c005881/attachment.html b/_build/static/archives/extend/attachments/20130920/4c005881/attachment.html new file mode 100644 index 00000000..ea5cc3a0 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130920/4c005881/attachment.html @@ -0,0 +1,85 @@ + +<div dir="ltr">Understand about chunks being synchronous. that helps me tremendously to understand how it works.<div><br></div><div>would you give me a sketchy example of how to use send_after in a loop handler? (sorry I am new to erlang)</div>
+<div><br></div><div>Konstantin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/20 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">chunk only returns when the client has received the chunk, so the timestamps solution should work.<br>
+<br>
+As for the timeout, you can simply use erlang:send_after or something like usual and the message will arrive in info/3.<div class="im"><br>
+<br>
+On 09/20/2013 08:54 PM, akonsu wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+thanks!<br>
+<br>
+how to implement timeout callback manually? if I had receive then I<br>
+would just use timeout clause there, but with the handler I do not know...<br>
+<br>
+I have doubts about validity of my question on the erlang list.  I later<br>
+realised that there is no problem receiving messages in my handler from<br>
+my upstream process, I can do it fast enough and shove everything to the<br>
+response. my real problem is to determine if the http client is reading<br>
+fast enough from the response...<br>
+<br>
+<br></div>
+2013/9/20 Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>><div class="im"><br>
+<br>
+    Loop handlers close after a while regardless of what you send, it<br>
+    only checks what the client sends. The best way for you would be to<br>
+    disable that timeout and handle it manually.<br>
+<br>
+    As for the second question, I'm still reading the thread on<br>
+    erlang-questions but I've seen some good ideas about timestamps so far.<br>
+<br>
+<br>
+    On 09/20/2013 08:47 PM, akonsu wrote:<br>
+<br>
+        Hi,<br>
+<br>
+        I am using loop handler and I stream from it:<br>
+<br>
+        info({stream, Part}, Req, S) -><br>
+              ok = cowboy_req:chunk(Part, Req),<br>
+              {loop, Req, S, hibernate};<br>
+<br>
+        I have two questions:<br>
+<br>
+        1. on timeouts cowboy sends 204 No Content. In my case it is not the<br>
+        right response because I may have already sent some data. Is<br>
+        there a way<br>
+        to send a custom response?<br>
+<br>
+        2. how to check if the client is too slow and is not reading the<br>
+        response stream fast enough? If this happens, then I need to<br>
+        disconnect.<br>
+<br>
+        I can live without 1. but I need to figure out 2. Please help.<br>
+<br>
+        thank you!<br>
+        Konstantin<br>
+<br>
+<br>
+<br></div>
+        ______________________________<u></u>___________________<br>
+        Extend mailing list<br>
+        <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a> <mailto:<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.<u></u>ninenines.eu</a>><br>
+        <a href="http://lists.ninenines.eu:81/__listinfo/extend" target="_blank">http://lists.ninenines.eu:81/_<u></u>_listinfo/extend</a><div class="im"><br>
+        <<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a>><br>
+<br>
+<br>
+<br>
+    --<br>
+    Loďc Hoguin<br>
+    Erlang Cowboy<br>
+    Nine Nines<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+</div></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loïc Hoguin</font></span><div class="HOEnZb"><div class="h5"><br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130920/6e3fa036/attachment.html b/_build/static/archives/extend/attachments/20130920/6e3fa036/attachment.html new file mode 100644 index 00000000..0864dc86 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130920/6e3fa036/attachment.html @@ -0,0 +1,7 @@ + +<div dir="ltr">Hi,<div><br></div><div>I am using loop handler and I stream from it:<div><div><br></div><div>info({stream, Part}, Req, S) -></div><div>    ok = cowboy_req:chunk(Part, Req),</div><div>    {loop, Req, S, hibernate};</div>
+</div><div><br></div><div>I have two questions:</div><div><br></div><div>1. on timeouts cowboy sends 204 No Content. In my case it is not the right response because I may have already sent some data. Is there a way to send a custom response?</div>
+<div><br></div><div>2. how to check if the client is too slow and is not reading the response stream fast enough? If this happens, then I need to disconnect.</div><div><br></div><div>I can live without 1. but I need to figure out 2. Please help.</div>
+<div><br></div><div>thank you!</div><div>Konstantin</div><div><br></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130922/6e925e9d/attachment.html b/_build/static/archives/extend/attachments/20130922/6e925e9d/attachment.html new file mode 100644 index 00000000..1c14246d --- /dev/null +++ b/_build/static/archives/extend/attachments/20130922/6e925e9d/attachment.html @@ -0,0 +1,12 @@ + +<div dir="ltr"><div><div><div><div><div><div><div><div>hi<br></div>Just starting out so I'm trying to run cowboy's helloworld<br></div>in cowboy/examples/hello_world, running make fails with:<br><br>===> Provider (rlx_prv_discover) failed with: {error,<br>
+ {rlx_app_discovery,<br> [{missing_beam_file,<br> hipe,<br>
+ <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br> {missing_beam_file,<br> hipe,<br>
+ <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br><br></div>there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br>
+</div>I've tried passing the correct dir to relx using --lib-dir but I still get the same error.<br><br></div>Any ideas what's going wrong?<br><br></div>erl: Erlang R16B02 (erts-5.10.3)<br></div>relx: 0.0.0+build.275.refca03701<br>
+</div>rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 22 September 2013 21:55, Matthew Hegarty <span dir="ltr"><<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>hi<br></div>Just starting out so I've got latest versions of apps.<br></div>in cowboy/examples/hello_world, running make fails with:<br>
+<br><br><br></div>
+</blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130922/77e355ff/attachment.html b/_build/static/archives/extend/attachments/20130922/77e355ff/attachment.html new file mode 100644 index 00000000..c252d5d7 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130922/77e355ff/attachment.html @@ -0,0 +1,4 @@ + +<div dir="ltr"><div><div>hi<br></div>Just starting out so I've got latest versions of apps.<br></div>in cowboy/examples/hello_world, running make fails with:<br><br><br><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130926/28d38e59/attachment.html b/_build/static/archives/extend/attachments/20130926/28d38e59/attachment.html new file mode 100644 index 00000000..aca6420f --- /dev/null +++ b/_build/static/archives/extend/attachments/20130926/28d38e59/attachment.html @@ -0,0 +1,186 @@ + +<!DOCTYPE html>
+<html>
+<head>
+<title></title>
+</head>
+<body><div>Did you enable hipe when you compiled? Does /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?<br></div>
+<div> </div>
+<div id="sig19305637"><div class="signature">-- <br></div>
+<div class="signature">  Tristan Sloughter<br></div>
+<div class="signature">  tristan.sloughter@gmail.com<br></div>
+<div class="signature"> </div>
+</div>
+<div> </div>
+<div> </div>
+<div>On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:<br></div>
+<blockquote type="cite"><div dir="ltr">hi<br></div>
+<div dir="ltr">I compiled Erlang from source (downloaded from <a href="http://erlang.org">erlang.org</a>)<br></div>
+<div><div> </div>
+<div> </div>
+<div><div>On 25 September 2013 17:25, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br></div>
+<div> </div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I ran into the same thing. I assume you installed Erlang from the Erlang<br></div>
+<div>
+Solutions repo?<br></div>
+<div> </div>
+<div>
+Install erlang-hipe package. Or remove<br></div>
+<div>
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.<br></div>
+<div> </div>
+<div>
+Their packages install a broken hipe app, missing lots of beams, for<br></div>
+<div>
+some reason. But if you install the hipe package it'll install what is<br></div>
+<div>
+missing. I told them about this but I haven't heard back.<br></div>
+<div> </div>
+<div>
+--<br></div>
+<div>
+  Tristan Sloughter<br></div>
+<div>
+  <a href="mailto:tsloughter@fastmail.fm">tsloughter@fastmail.fm</a><br></div>
+<div> </div>
+<div><div> </div>
+<div>
+On Wed, Sep 25, 2013, at 08:09 AM, Loc Hoguin wrote:<br></div>
+<div>
+> Why does it look for hipe at all to begin with?<br></div>
+<div>
+><br></div>
+<div>
+> I'll ping tristan about it.<br></div>
+<div>
+><br></div>
+<div>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:<br></div>
+<div>
+> > hi<br></div>
+<div>
+> > Just starting out so I'm trying to run cowboy's helloworld<br></div>
+<div>
+> > in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> > ===> Provider (rlx_prv_discover) failed with: {error,<br></div>
+<div>
+> >                                                        {rlx_app_discovery,<br></div>
+<div>
+> >                                                         [{missing_beam_file,<br></div>
+<div>
+> >                                                           hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br></div>
+<div>
+> >                                                          {missing_beam_file,<br></div>
+<div>
+> >                                                           hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br></div>
+<div>
+> ><br></div>
+<div>
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it<br></div>
+<div>
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br></div>
+<div>
+> > I've tried passing the correct dir to relx using --lib-dir but I still<br></div>
+<div>
+> > get the same error.<br></div>
+<div>
+> ><br></div>
+<div>
+> > Any ideas what's going wrong?<br></div>
+<div>
+> ><br></div>
+<div>
+> > erl: Erlang R16B02 (erts-5.10.3)<br></div>
+<div>
+> > relx: 0.0.0+build.275.refca03701<br></div>
+<div>
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > On 22 September 2013 21:55, Matthew Hegarty <<a href="mailto:mrhegarty@gmail.com">mrhegarty@gmail.com</a><br></div>
+<div>
+> > <mailto:<a href="mailto:mrhegarty@gmail.com">mrhegarty@gmail.com</a>>> wrote:<br></div>
+<div>
+> ><br></div>
+<div>
+> >     hi<br></div>
+<div>
+> >     Just starting out so I've got latest versions of apps.<br></div>
+<div>
+> >     in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > _______________________________________________<br></div>
+<div>
+> > Extend mailing list<br></div>
+<div>
+> > <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> > <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div>
+> ><br></div>
+<div>
+><br></div>
+<div>
+><br></div>
+<div>
+> --
+<br></div>
+</div>
+<div>> Loc Hoguin<br></div>
+<div> </div>
+<div>> Erlang Cowboy<br></div>
+<div>
+> Nine Nines<br></div>
+<div>
+> <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>
+<br></div>
+<div><div>> _______________________________________________<br></div>
+<div>
+> Extend mailing list<br></div>
+<div>
+> <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div> </div>
+<div> </div>
+<div>
+--
+<br></div>
+</div>
+<div><span><span style="color:rgb(136, 136, 136)" class="colour">  Tristan Sloughter</span></span><br></div>
+<div><span><span style="color:rgb(136, 136, 136)" class="colour">
+  <a href="mailto:tristan.sloughter@gmail.com">tristan.sloughter@gmail.com</a><br>
+</span></span></div>
+</blockquote></div>
+<div> </div>
+</div>
+</blockquote></body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130926/3a77fe04/attachment.html b/_build/static/archives/extend/attachments/20130926/3a77fe04/attachment.html new file mode 100644 index 00000000..05e6ddc9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130926/3a77fe04/attachment.html @@ -0,0 +1,189 @@ + +<div dir="ltr"><div><div><div><div>yes it exists. I believe hipe is enabled by default when I compile.<br></div><br></div>however there is no<br><br>/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam<br>/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam<br>
+<br></div>which is what relx is apparently looking for.<br></div>Do you know where does relx get these paths from?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 September 2013 20:04, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
+
+
+
+
+<div><div>Did you enable hipe when you compiled? Does /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888">
+<div></div>
+<div><div>-- <br></div>
+<div>  Tristan Sloughter<br></div>
+<div>  <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a><br></div>
+<div></div>
+</div></font></span><div><div class="h5">
+<div></div>
+<div></div>
+<div>On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:<br></div>
+<blockquote type="cite"><div dir="ltr">hi<br></div>
+<div dir="ltr">I compiled Erlang from source (downloaded from <a href="http://erlang.org" target="_blank">erlang.org</a>)<br></div>
+<div><div></div>
+<div></div>
+<div><div>On 25 September 2013 17:25, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br></div>
+<div></div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I ran into the same thing. I assume you installed Erlang from the Erlang<br></div>
+<div>
+Solutions repo?<br></div>
+<div></div>
+<div>
+Install erlang-hipe package. Or remove<br></div>
+<div>
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.<br></div>
+<div></div>
+<div>
+Their packages install a broken hipe app, missing lots of beams, for<br></div>
+<div>
+some reason. But if you install the hipe package it'll install what is<br></div>
+<div>
+missing. I told them about this but I haven't heard back.<br></div>
+<div></div>
+<div>
+--<br></div>
+<div>
+ Tristan Sloughter<br></div>
+<div>
+ <a href="mailto:tsloughter@fastmail.fm" target="_blank">tsloughter@fastmail.fm</a><br></div>
+<div></div>
+<div><div></div>
+<div>
+On Wed, Sep 25, 2013, at 08:09 AM, Loc Hoguin wrote:<br></div>
+<div>
+> Why does it look for hipe at all to begin with?<br></div>
+<div>
+><br></div>
+<div>
+> I'll ping tristan about it.<br></div>
+<div>
+><br></div>
+<div>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:<br></div>
+<div>
+> > hi<br></div>
+<div>
+> > Just starting out so I'm trying to run cowboy's helloworld<br></div>
+<div>
+> > in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> > ===> Provider (rlx_prv_discover) failed with: {error,<br></div>
+<div>
+> >                            {rlx_app_discovery,<br></div>
+<div>
+> >                             [{missing_beam_file,<br></div>
+<div>
+> >                              hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br></div>
+<div>
+> >                             {missing_beam_file,<br></div>
+<div>
+> >                              hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br></div>
+<div>
+> ><br></div>
+<div>
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it<br></div>
+<div>
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br></div>
+<div>
+> > I've tried passing the correct dir to relx using --lib-dir but I still<br></div>
+<div>
+> > get the same error.<br></div>
+<div>
+> ><br></div>
+<div>
+> > Any ideas what's going wrong?<br></div>
+<div>
+> ><br></div>
+<div>
+> > erl: Erlang R16B02 (erts-5.10.3)<br></div>
+<div>
+> > relx: 0.0.0+build.275.refca03701<br></div>
+<div>
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > On 22 September 2013 21:55, Matthew Hegarty <<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a><br></div>
+<div>
+> > <mailto:<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>>> wrote:<br></div>
+<div>
+> ><br></div>
+<div>
+> >   hi<br></div>
+<div>
+> >   Just starting out so I've got latest versions of apps.<br></div>
+<div>
+> >   in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > _______________________________________________<br></div>
+<div>
+> > Extend mailing list<br></div>
+<div>
+> > <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> > <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div>
+> ><br></div>
+<div>
+><br></div>
+<div>
+><br></div>
+<div>
+> --
+<br></div>
+</div>
+<div>> Loc Hoguin<br></div>
+<div></div>
+<div>> Erlang Cowboy<br></div>
+<div>
+> Nine Nines<br></div>
+<div>
+> <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>
+<br></div>
+<div><div>> _______________________________________________<br></div>
+<div>
+> Extend mailing list<br></div>
+<div>
+> <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div></div>
+<div></div>
+<div>
+--
+<br></div>
+</div>
+<div><span><span style="color:rgb(136,136,136)"> Tristan Sloughter</span></span><br></div>
+<div><span><span style="color:rgb(136,136,136)">
+ <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a><br>
+</span></span></div>
+</blockquote></div>
+<div></div>
+</div>
+</blockquote></div></div></div>
+
+</blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130926/d34b33e3/attachment.html b/_build/static/archives/extend/attachments/20130926/d34b33e3/attachment.html new file mode 100644 index 00000000..c0201fa9 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130926/d34b33e3/attachment.html @@ -0,0 +1,85 @@ + +<div dir="ltr">hi<br>I compiled Erlang from source (downloaded from <a href="http://erlang.org">erlang.org</a>)<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 25 September 2013 17:25, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I ran into the same thing. I assume you installed Erlang from the Erlang<br>
+Solutions repo?<br>
+<br>
+Install erlang-hipe package. Or remove<br>
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.<br>
+<br>
+Their packages install a broken hipe app, missing lots of beams, for<br>
+some reason. But if you install the hipe package it'll install what is<br>
+missing. I told them about this but I haven't heard back.<br>
+<br>
+--<br>
+ Tristan Sloughter<br>
+ <a href="mailto:tsloughter@fastmail.fm">tsloughter@fastmail.fm</a><br>
+<div><div class="h5"><br>
+On Wed, Sep 25, 2013, at 08:09 AM, Loc Hoguin wrote:<br>
+> Why does it look for hipe at all to begin with?<br>
+><br>
+> I'll ping tristan about it.<br>
+><br>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:<br>
+> > hi<br>
+> > Just starting out so I'm trying to run cowboy's helloworld<br>
+> > in cowboy/examples/hello_world, running make fails with:<br>
+> ><br>
+> > ===> Provider (rlx_prv_discover) failed with: {error,<br>
+> >                            {rlx_app_discovery,<br>
+> >                             [{missing_beam_file,<br>
+> >                              hipe,<br>
+> ><br>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br>
+> >                             {missing_beam_file,<br>
+> >                              hipe,<br>
+> ><br>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br>
+> ><br>
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it<br>
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br>
+> > I've tried passing the correct dir to relx using --lib-dir but I still<br>
+> > get the same error.<br>
+> ><br>
+> > Any ideas what's going wrong?<br>
+> ><br>
+> > erl: Erlang R16B02 (erts-5.10.3)<br>
+> > relx: 0.0.0+build.275.refca03701<br>
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br>
+> ><br>
+> ><br>
+> > On 22 September 2013 21:55, Matthew Hegarty <<a href="mailto:mrhegarty@gmail.com">mrhegarty@gmail.com</a><br>
+> > <mailto:<a href="mailto:mrhegarty@gmail.com">mrhegarty@gmail.com</a>>> wrote:<br>
+> ><br>
+> >   hi<br>
+> >   Just starting out so I've got latest versions of apps.<br>
+> >   in cowboy/examples/hello_world, running make fails with:<br>
+> ><br>
+> ><br>
+> ><br>
+> ><br>
+> ><br>
+> ><br>
+> > _______________________________________________<br>
+> > Extend mailing list<br>
+> > <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>
+> > <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+> ><br>
+><br>
+><br>
+> --<br>
+</div></div>> Loc Hoguin<br>
+<div class="im HOEnZb">> Erlang Cowboy<br>
+> Nine Nines<br>
+> <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
+> Extend mailing list<br>
+> <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+<br>
+<br>
+--<br>
+</div></div><span class="HOEnZb"><font color="#888888"> Tristan Sloughter<br>
+ <a href="mailto:tristan.sloughter@gmail.com">tristan.sloughter@gmail.com</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20130928/41b322fd/attachment.html b/_build/static/archives/extend/attachments/20130928/41b322fd/attachment.html new file mode 100644 index 00000000..d36eb019 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130928/41b322fd/attachment.html @@ -0,0 +1,253 @@ + +<!DOCTYPE html>
+<html>
+<head>
+<title></title>
+</head>
+<body><div>Yea, since I doubt the OTP team (or anyone) will fix the fact that it installs a broken hipe we've decided to just warn on broken apps during the discovery phase. So it'll only fail if the broken app is also suppose to be part of the release.<br></div>
+<div> </div>
+<div>Finishing up the relx patch right now.<br></div>
+<div> </div>
+<div id="sig19305637"><div class="signature">-- <br></div>
+<div class="signature">  Tristan Sloughter<br></div>
+<div class="signature">  tristan.sloughter@gmail.com<br></div>
+<div class="signature"> </div>
+</div>
+<div> </div>
+<div> </div>
+<div>On Sat, Sep 28, 2013, at 01:41 PM, Matthew Hegarty wrote:<br></div>
+<blockquote type="cite"><div dir="ltr"><div><div><div>Got it to work.  I apparently had a few versions of hipe in my Erlang lib dir:<br></div>
+<div> </div>
+<div>$ /usr/local/lib/erlang/lib $ ll -ld hipe*<br></div>
+<div>drwxr-xr-x  9 root root 4096 Feb 11  2013 hipe-3.10/<br></div>
+<div>drwxr-xr-x  9 root root 4096 Mar  1  2013 hipe-3.10.1/<br></div>
+<div>
+drwxr-xr-x 10 root root 4096 Jul  2 11:31 hipe-3.10.2/<br></div>
+<div>drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/<br></div>
+<div> </div>
+<div>They must have come from previous erlang installations (compilation from source).  The solution was to remove the older versions and leave only the latest one.  Maybe relx should be able to handle this?<br></div>
+<div> </div>
+</div>
+<div>thanks for the responses<br></div>
+</div>
+<div> </div>
+<div>Matt<br></div>
+</div>
+<div><div> </div>
+<div> </div>
+<div><div>On 26 September 2013 21:36, Matthew Hegarty <span dir="ltr"><<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>></span> wrote:<br></div>
+<div> </div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>yes it exists.  I believe hipe is enabled by default when I compile.<br></div>
+<div> </div>
+</div>
+<div>
+however there is no<br></div>
+<div> </div>
+<div> /usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam<br></div>
+<div> /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam<br></div>
+<div> </div>
+</div>
+<div>which is what relx is apparently looking for.<br></div>
+</div>
+<div>Do you know where does relx get these paths from?<br></div>
+</div>
+<div><div><div><div> </div>
+<div> </div>
+<div><div>On 26 September 2013 20:04, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br></div>
+<div> </div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
+
+
+
+
+<div><div>Did you enable hipe when you compiled? Does /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?<span><span style="color:rgb(136, 136, 136)" class="colour"></span></span><br></div>
+<span><span style="color:rgb(136, 136, 136)" class="colour"><div> </div>
+<div><div>-- <br></div>
+<div>  Tristan Sloughter<br></div>
+<div>  <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a><br></div>
+<div> </div>
+</div>
+</span></span><div><div><div> </div>
+<div> </div>
+<div>On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:<br></div>
+<blockquote type="cite"><div dir="ltr">hi<br></div>
+<div dir="ltr">I compiled Erlang from source (downloaded from <a href="http://erlang.org" target="_blank">erlang.org</a>)<br></div>
+<div><div> </div>
+<div> </div>
+<div><div>On 25 September 2013 17:25, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br></div>
+<div> </div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I ran into the same thing. I assume you installed Erlang from the Erlang<br></div>
+<div>
+Solutions repo?<br></div>
+<div> </div>
+<div>
+Install erlang-hipe package. Or remove<br></div>
+<div>
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.<br></div>
+<div> </div>
+<div>
+Their packages install a broken hipe app, missing lots of beams, for<br></div>
+<div>
+some reason. But if you install the hipe package it'll install what is<br></div>
+<div>
+missing. I told them about this but I haven't heard back.<br></div>
+<div> </div>
+<div>
+--<br></div>
+<div>
+  Tristan Sloughter<br></div>
+<div>
+  <a href="mailto:tsloughter@fastmail.fm" target="_blank">tsloughter@fastmail.fm</a><br></div>
+<div> </div>
+<div><div> </div>
+<div>
+On Wed, Sep 25, 2013, at 08:09 AM, Loc Hoguin wrote:<br></div>
+<div>
+> Why does it look for hipe at all to begin with?<br></div>
+<div>
+><br></div>
+<div>
+> I'll ping tristan about it.<br></div>
+<div>
+><br></div>
+<div>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:<br></div>
+<div>
+> > hi<br></div>
+<div>
+> > Just starting out so I'm trying to run cowboy's helloworld<br></div>
+<div>
+> > in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> > ===> Provider (rlx_prv_discover) failed with: {error,<br></div>
+<div>
+> >                                                        {rlx_app_discovery,<br></div>
+<div>
+> >                                                         [{missing_beam_file,<br></div>
+<div>
+> >                                                           hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br></div>
+<div>
+> >                                                          {missing_beam_file,<br></div>
+<div>
+> >                                                           hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br></div>
+<div>
+> ><br></div>
+<div>
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it<br></div>
+<div>
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br></div>
+<div>
+> > I've tried passing the correct dir to relx using --lib-dir but I still<br></div>
+<div>
+> > get the same error.<br></div>
+<div>
+> ><br></div>
+<div>
+> > Any ideas what's going wrong?<br></div>
+<div>
+> ><br></div>
+<div>
+> > erl: Erlang R16B02 (erts-5.10.3)<br></div>
+<div>
+> > relx: 0.0.0+build.275.refca03701<br></div>
+<div>
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > On 22 September 2013 21:55, Matthew Hegarty <<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a><br></div>
+<div>
+> > <mailto:<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>>> wrote:<br></div>
+<div>
+> ><br></div>
+<div>
+> >     hi<br></div>
+<div>
+> >     Just starting out so I've got latest versions of apps.<br></div>
+<div>
+> >     in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > _______________________________________________<br></div>
+<div>
+> > Extend mailing list<br></div>
+<div>
+> > <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> > <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div>
+> ><br></div>
+<div>
+><br></div>
+<div>
+><br></div>
+<div>
+> --
+<br></div>
+</div>
+<div>> Loc Hoguin<br></div>
+<div> </div>
+<div>> Erlang Cowboy<br></div>
+<div>
+> Nine Nines<br></div>
+<div>
+> <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>
+<br></div>
+<div><div>> _______________________________________________<br></div>
+<div>
+> Extend mailing list<br></div>
+<div>
+> <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div> </div>
+<div> </div>
+<div>
+--
+<br></div>
+</div>
+<div><span><span style="color:rgb(136, 136, 136)" class="colour">  Tristan Sloughter</span></span><br></div>
+<div><span><span style="color:rgb(136, 136, 136)" class="colour">
+  <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>
+</span></span><br></div>
+</blockquote></div>
+<div> </div>
+</div>
+</blockquote></div>
+</div>
+</div>
+</blockquote></div>
+<div> </div>
+</div>
+</div>
+</div>
+</blockquote></div>
+<div> </div>
+</div>
+</blockquote></body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20130928/b1333ac2/attachment.html b/_build/static/archives/extend/attachments/20130928/b1333ac2/attachment.html new file mode 100644 index 00000000..46e22802 --- /dev/null +++ b/_build/static/archives/extend/attachments/20130928/b1333ac2/attachment.html @@ -0,0 +1,195 @@ + +<div dir="ltr"><div><div><div>Got it to work. I apparently had a few versions of hipe in my Erlang lib dir:<br><br>$ /usr/local/lib/erlang/lib $ ll -ld hipe*<br>drwxr-xr-x 9 root root 4096 Feb 11 2013 hipe-3.10/<br>drwxr-xr-x 9 root root 4096 Mar 1 2013 hipe-3.10.1/<br>
+drwxr-xr-x 10 root root 4096 Jul 2 11:31 hipe-3.10.2/<br>drwxr-xr-x 10 root root 4096 Sep 21 17:36 hipe-3.10.2.1/<br><br></div>They must have come from previous erlang installations (compilation from source). The solution was to remove the older versions and leave only the latest one. Maybe relx should be able to handle this?<br>
+<br></div>thanks for the responses<br></div><br>Matt<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 September 2013 21:36, Matthew Hegarty <span dir="ltr"><<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>yes it exists. I believe hipe is enabled by default when I compile.<br></div><br></div>
+however there is no<br><br>/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam<br>/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam<br>
+<br></div>which is what relx is apparently looking for.<br></div>Do you know where does relx get these paths from?<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On 26 September 2013 20:04, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
+
+
+
+
+<div><div>Did you enable hipe when you compiled? Does /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam exist?<span><font color="#888888"><br></font></span></div><span><font color="#888888">
+<div></div>
+<div><div>-- <br></div>
+<div>  Tristan Sloughter<br></div>
+<div>  <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a><br></div>
+<div></div>
+</div></font></span><div><div>
+<div></div>
+<div></div>
+<div>On Thu, Sep 26, 2013, at 12:03 PM, Matthew Hegarty wrote:<br></div>
+<blockquote type="cite"><div dir="ltr">hi<br></div>
+<div dir="ltr">I compiled Erlang from source (downloaded from <a href="http://erlang.org" target="_blank">erlang.org</a>)<br></div>
+<div><div></div>
+<div></div>
+<div><div>On 25 September 2013 17:25, Tristan Sloughter <span dir="ltr"><<a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a>></span> wrote:<br></div>
+<div></div>
+<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>I ran into the same thing. I assume you installed Erlang from the Erlang<br></div>
+<div>
+Solutions repo?<br></div>
+<div></div>
+<div>
+Install erlang-hipe package. Or remove<br></div>
+<div>
+/usr/local/lib/erlang/lib/hipe-3.10.2.1 entirely.<br></div>
+<div></div>
+<div>
+Their packages install a broken hipe app, missing lots of beams, for<br></div>
+<div>
+some reason. But if you install the hipe package it'll install what is<br></div>
+<div>
+missing. I told them about this but I haven't heard back.<br></div>
+<div></div>
+<div>
+--<br></div>
+<div>
+ Tristan Sloughter<br></div>
+<div>
+ <a href="mailto:tsloughter@fastmail.fm" target="_blank">tsloughter@fastmail.fm</a><br></div>
+<div></div>
+<div><div></div>
+<div>
+On Wed, Sep 25, 2013, at 08:09 AM, Loc Hoguin wrote:<br></div>
+<div>
+> Why does it look for hipe at all to begin with?<br></div>
+<div>
+><br></div>
+<div>
+> I'll ping tristan about it.<br></div>
+<div>
+><br></div>
+<div>
+> On 09/22/2013 10:59 PM, Matthew Hegarty wrote:<br></div>
+<div>
+> > hi<br></div>
+<div>
+> > Just starting out so I'm trying to run cowboy's helloworld<br></div>
+<div>
+> > in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> > ===> Provider (rlx_prv_discover) failed with: {error,<br></div>
+<div>
+> >                            {rlx_app_discovery,<br></div>
+<div>
+> >                             [{missing_beam_file,<br></div>
+<div>
+> >                              hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10/ebin/hipe.beam">>},<br></div>
+<div>
+> >                             {missing_beam_file,<br></div>
+<div>
+> >                              hipe,<br></div>
+<div>
+> ><br></div>
+<div>
+> > <<"/usr/local/lib/erlang/lib/hipe-3.10.1/ebin/hipe.beam">>}]}}<br></div>
+<div>
+> ><br></div>
+<div>
+> > there is no hipe.beam in /usr/local/lib/erlang/lib/hipe-3.10.1/ebin/, it<br></div>
+<div>
+> > is in /usr/local/lib/erlang/lib/hipe-3.10.2.1/ebin/hipe.beam.<br></div>
+<div>
+> > I've tried passing the correct dir to relx using --lib-dir but I still<br></div>
+<div>
+> > get the same error.<br></div>
+<div>
+> ><br></div>
+<div>
+> > Any ideas what's going wrong?<br></div>
+<div>
+> ><br></div>
+<div>
+> > erl: Erlang R16B02 (erts-5.10.3)<br></div>
+<div>
+> > relx: 0.0.0+build.275.refca03701<br></div>
+<div>
+> > rebar: rebar 2.1.0-pre R16B02 20130922_191744 git 2.1.0-pre-46-g78fa8fc<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > On 22 September 2013 21:55, Matthew Hegarty <<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a><br></div>
+<div>
+> > <mailto:<a href="mailto:mrhegarty@gmail.com" target="_blank">mrhegarty@gmail.com</a>>> wrote:<br></div>
+<div>
+> ><br></div>
+<div>
+> >   hi<br></div>
+<div>
+> >   Just starting out so I've got latest versions of apps.<br></div>
+<div>
+> >   in cowboy/examples/hello_world, running make fails with:<br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> ><br></div>
+<div>
+> > _______________________________________________<br></div>
+<div>
+> > Extend mailing list<br></div>
+<div>
+> > <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> > <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div>
+> ><br></div>
+<div>
+><br></div>
+<div>
+><br></div>
+<div>
+> --
+<br></div>
+</div>
+<div>> Loc Hoguin<br></div>
+<div></div>
+<div>> Erlang Cowboy<br></div>
+<div>
+> Nine Nines<br></div>
+<div>
+> <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a>
+<br></div>
+<div><div>> _______________________________________________<br></div>
+<div>
+> Extend mailing list<br></div>
+<div>
+> <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br></div>
+<div>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br></div>
+<div></div>
+<div></div>
+<div>
+--
+<br></div>
+</div>
+<div><span><span style="color:rgb(136,136,136)"> Tristan Sloughter</span></span><br></div>
+<div><span><span style="color:rgb(136,136,136)">
+ <a href="mailto:tristan.sloughter@gmail.com" target="_blank">tristan.sloughter@gmail.com</a><br>
+</span></span></div>
+</blockquote></div>
+<div></div>
+</div>
+</blockquote></div></div></div>
+
+</blockquote></div><br></div>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131002/4463e3fa/attachment.html b/_build/static/archives/extend/attachments/20131002/4463e3fa/attachment.html new file mode 100644 index 00000000..c1ef7545 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131002/4463e3fa/attachment.html @@ -0,0 +1,5 @@ + +<div dir="ltr">Hi there,<div><br></div><div>How do I use the websocket infrastructure of cowboy to implement RPC?</div><div>It seems like I can talk to the client using websocket_info, but the response comes in on websocket_handle, all asynchronously.</div>
+<div><br></div><div>Kind regards,</div><div>Marcel</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131007/863e7358/attachment.html b/_build/static/archives/extend/attachments/20131007/863e7358/attachment.html new file mode 100644 index 00000000..cada84a3 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131007/863e7358/attachment.html @@ -0,0 +1,75 @@ + +<div dir="ltr">Thanks Loïc. I am actually running R16B on a macbook OS X 10.8. (I'm wondering if the Od could have any effect?)<div><br></div><div>Best,</div><div><br></div><div>Ryan</div></div><div class="gmail_extra">
+<br><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 10:13 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+I'm guessing you run an older Erlang which had that issue. Either upgrade Erlang or add asn1 to the list of apps to include in the release (and open a ticket for it please so it can be made to work with older versions).<div>
+<div class="h5"><br>
+<br>
+On 10/08/2013 05:55 AM, Ryan Brown wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+I was trying to compile and run the ssl_hello_world example in the<br>
+cowboy project and am getting the following error at start-up:<br>
+<br>
+<br>
+  =INFO REPORT==== 7-Oct-2013::21:38:01 ===<br>
+<br>
+<br>
+       application: ssl_hello_world<br>
+<br>
+<br>
+       exited: {bad_return,<br>
+<br>
+<br>
+                {{ssl_hello_world_app,start,[<u></u>normal,[]]},<br>
+<br>
+<br>
+                 {'EXIT',<br>
+<br>
+<br>
+                  {{badmatch,<br>
+<br>
+<br>
+                    {error,<br>
+<br>
+<br>
+                     {{shutdown,<br>
+<br>
+<br>
+                       {failed_to_start_child,ranch_<u></u>acceptors_sup,<br>
+<br>
+<br>
+                        {{case_clause,<br>
+<br>
+<br>
+                          {error,{"no such file or directory","asn1.app"}}},<br>
+<br>
+<br>
+<br>
+  [{ranch,require,1,[{file,"src/<u></u>ranch.erl"},{line,207}]},<br>
+<br>
+<br>
+I can start asn1 from the erl console so I am not sure what I am<br>
+missing. Any help is greatly appreciated.<br>
+<br>
+Best regards.<br>
+<br>
+--<br>
+-rb<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>-rb
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20131007/fdef2170/attachment.html b/_build/static/archives/extend/attachments/20131007/fdef2170/attachment.html new file mode 100644 index 00000000..36217c63 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131007/fdef2170/attachment.html @@ -0,0 +1,15 @@ + +<div dir="ltr">I was trying to compile and run the ssl_hello_world example in the cowboy project and am getting the following error at start-up:<div><br></div><div><h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">=INFO REPORT==== 7-Oct-2013::21:38:01 ===</font></h1>
+<h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">  application: ssl_hello_world</font></h1><h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">  exited: {bad_return,</font></h1>
+<h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">      {{ssl_hello_world_app,start,[normal,[]]},</font></h1><h1 class="" style="margin:0px">
+<font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">       {'EXIT',</font></h1><h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">       {{badmatch,</font></h1>
+<h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">        {error,</font></h1><h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">         {{shutdown,</font></h1>
+<h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">          {failed_to_start_child,ranch_acceptors_sup,</font></h1><h1 class="" style="margin:0px">
+<font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">          {{case_clause,</font></h1><h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">           {error,{"no such file or directory","asn1.app"}}},</font></h1>
+<h1 class="" style="margin:0px"><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">           [{ranch,require,1,[{file,"src/ranch.erl"},{line,207}]},</font></h1>
+<div><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal"><br></font></div><div><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">I can start asn1 from the erl console so I am not sure what I am missing. Any help is greatly appreciated.</font></div>
+<div><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal"><br></font></div><div><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal">Best regards.</font></div>
+<div><font color="#000000" face="Gill Sans, Tahoma, Verdana, sans-serif" size="3" style="font-weight:normal"><br></font></div>-- <br>-rb
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131008/8752fdd7/attachment.html b/_build/static/archives/extend/attachments/20131008/8752fdd7/attachment.html new file mode 100644 index 00000000..3077367f --- /dev/null +++ b/_build/static/archives/extend/attachments/20131008/8752fdd7/attachment.html @@ -0,0 +1,82 @@ + +<div dir="ltr">Just to complete the loop. As would be expected, adding asn1 to the app.src applications fixes the issue.<div><br></div><div>Thank you,</div><div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><br>
+<div class="gmail_quote">On Mon, Oct 7, 2013 at 10:24 PM, Ryan Brown <span dir="ltr"><<a href="mailto:ryankbrown@gmail.com" target="_blank">ryankbrown@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div dir="ltr">Thanks Loïc. I am actually running R16B on a macbook OS X 10.8. (I'm wondering if the Od could have any effect?)<div><br></div><div>Best,</div><div><br></div><div>Ryan</div></div><div class="gmail_extra">
+<div><div class="h5">
+<br><br><div class="gmail_quote">On Mon, Oct 7, 2013 at 10:13 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+I'm guessing you run an older Erlang which had that issue. Either upgrade Erlang or add asn1 to the list of apps to include in the release (and open a ticket for it please so it can be made to work with older versions).<div>
+
+<div><br>
+<br>
+On 10/08/2013 05:55 AM, Ryan Brown wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
+I was trying to compile and run the ssl_hello_world example in the<br>
+cowboy project and am getting the following error at start-up:<br>
+<br>
+<br>
+  =INFO REPORT==== 7-Oct-2013::21:38:01 ===<br>
+<br>
+<br>
+       application: ssl_hello_world<br>
+<br>
+<br>
+       exited: {bad_return,<br>
+<br>
+<br>
+                {{ssl_hello_world_app,start,[<u></u>normal,[]]},<br>
+<br>
+<br>
+                 {'EXIT',<br>
+<br>
+<br>
+                  {{badmatch,<br>
+<br>
+<br>
+                    {error,<br>
+<br>
+<br>
+                     {{shutdown,<br>
+<br>
+<br>
+                       {failed_to_start_child,ranch_<u></u>acceptors_sup,<br>
+<br>
+<br>
+                        {{case_clause,<br>
+<br>
+<br>
+                          {error,{"no such file or directory","asn1.app"}}},<br>
+<br>
+<br>
+<br>
+  [{ranch,require,1,[{file,"src/<u></u>ranch.erl"},{line,207}]},<br>
+<br>
+<br>
+I can start asn1 from the erl console so I am not sure what I am<br>
+missing. Any help is greatly appreciated.<br>
+<br>
+Best regards.<br>
+<br>
+--<br>
+-rb<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span><font color="#888888">
+</font></span></blockquote><span><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br>-rb
+</font></span></div>
+</blockquote></div><br><br clear="all"><div><br></div>-- <br>-rb
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20131009/7c03cefc/attachment.html b/_build/static/archives/extend/attachments/20131009/7c03cefc/attachment.html new file mode 100644 index 00000000..6870f939 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131009/7c03cefc/attachment.html @@ -0,0 +1,67 @@ + +<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Essentially, the REST service endpoint would be on <a href="http://widgets.net">widgets.net</a> while the clients website, in this case <a href="http://things.com">things.com</a>, has a JavaScript that makes an AJAX call to <a href="http://widgets.net">widgets.net</a>.  The account on <a href="http://widgets.net">widgets.net</a> for <a href="http://things.com">things.com</a> will have the <a href="http://things.com">things.com</a> domain registered to its account, so that <a href="http://widgets.net">widgets.net</a> can check to see if the request is coming from an expected domain.<div><br></div><div>Thanks,</div><div>Lee</div><div><br></div><div><br><div><div>On 9 Oct 2013, at 16:51, Nathan Michaels <<a href="mailto:nathan@nmichaels.org">nathan@nmichaels.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Is the client making the request to your service on <a href="http://widgets.net/">widgets.net</a> because <a href="http://things.com/">things.com</a> sent them there, or is <a href="http://things.com/">things.com</a> making the request directly on behalf of the client? The first is what Loc is talking about. The second is the source IP of the request, which you can definitely get.</div>
+
+<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 11:32 AM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+In short: you can't.<br>
+<br>
+Browsers may send origin/referer/.. headers depending on the type of request, but you can't rely on them to be real or even just there.<div class="HOEnZb"><div class="h5"><br>
+<br>
+On 10/09/2013 05:30 PM, Lee Sylvester wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called <a href="http://things.com/" target="_blank">things.com</a> makes a request to my service on <a href="http://widgets.net/" target="_blank">widgets.net</a>.  I need to see that the request is made FROM <a href="http://things.com/" target="_blank">things.com</a> for validation purposes. Is it correct that host will provide this?<br>
+
+
+<br>
+Thanks,<br>
+Lee<br>
+<br>
+Sent from my iPhone<br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+On Oct 9, 2013, at 2:31 PM, Loc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>> wrote:<br>
+<br>
+cowboy_req:host/1?<br>
+<br>
+Please use the nice manual we have now.<br>
+<br>
+  <a href="http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/manual/cowboy_req</a><br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+On 10/09/2013 03:27 PM, Lee Sylvester wrote:<br>
+Hi,<br>
+<br>
+When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.<br>
+
+
+<br>
+Thanks,<br>
+Lee<br>
+<br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</blockquote>
+<br>
+<br>
+--<br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu/" target="_blank">http://ninenines.eu</a><br>
+</blockquote></blockquote>
+<br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu/" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</div></div></blockquote></div><br></div>
+_______________________________________________<br>Extend mailing list<br><a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>http://lists.ninenines.eu:81/listinfo/extend<br></blockquote></div><br></div></body></html> + diff --git a/_build/static/archives/extend/attachments/20131009/cc05d6f5/attachment.html b/_build/static/archives/extend/attachments/20131009/cc05d6f5/attachment.html new file mode 100644 index 00000000..40290673 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131009/cc05d6f5/attachment.html @@ -0,0 +1,67 @@ + +<div dir="ltr">Is the client making the request to your service on <a href="http://widgets.net">widgets.net</a> because <a href="http://things.com">things.com</a> sent them there, or is <a href="http://things.com">things.com</a> making the request directly on behalf of the client? The first is what Loïc is talking about. The second is the source IP of the request, which you can definitely get.</div>
+
+<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 9, 2013 at 11:32 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+In short: you can't.<br>
+<br>
+Browsers may send origin/referer/.. headers depending on the type of request, but you can't rely on them to be real or even just there.<div class="HOEnZb"><div class="h5"><br>
+<br>
+On 10/09/2013 05:30 PM, Lee Sylvester wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Thank you.  I couldn't work out if that's the host being called from or the host name in the request.  For example, a store called <a href="http://things.com" target="_blank">things.com</a> makes a request to my service on <a href="http://widgets.net" target="_blank">widgets.net</a>.  I need to see that the request is made FROM <a href="http://things.com" target="_blank">things.com</a> for validation purposes. Is it correct that host will provide this?<br>
+
+
+<br>
+Thanks,<br>
+Lee<br>
+<br>
+Sent from my iPhone<br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+On Oct 9, 2013, at 2:31 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>> wrote:<br>
+<br>
+cowboy_req:host/1?<br>
+<br>
+Please use the nice manual we have now.<br>
+<br>
+  <a href="http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_req" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/manual/cowboy_req</a><br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+On 10/09/2013 03:27 PM, Lee Sylvester wrote:<br>
+Hi,<br>
+<br>
+When receiving a Cowboy request, is there a way to find out which hostname the user made the request from?  I'm using CORS in my REST and Bullet app, where each call can be made through a given account.  However, I'd like to be able to lock requests for each account to a designated hostname to protect that users account usage.<br>
+
+
+<br>
+Thanks,<br>
+Lee<br>
+<br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</blockquote>
+<br>
+<br>
+--<br>
+Loïc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</blockquote></blockquote>
+<br>
+<br>
+-- <br>
+Loïc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131015/203060cc/attachment.html b/_build/static/archives/extend/attachments/20131015/203060cc/attachment.html new file mode 100644 index 00000000..93be1f66 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131015/203060cc/attachment.html @@ -0,0 +1,78 @@ + +<div dir="ltr">thanks for your help. suppose that I want to stream live audio. I do not know how long my audio program will be, and as I stream it, if I have a timeout, the server will just disconnect the user that listens to the audio in the browser. and the browser won't reconnect. Would you suggest the "right" way to implement something like that? Would infinite timeout suffice? or is it a bad practice? another type of handler maybe?</div>
+<div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/15 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Yep. And it will also disconnect if the client sends too much. It has to disconnect and reconnect eventually, there's no way around it.<div class="im"><br>
+<br>
+On 10/16/2013 05:03 AM, akonsu wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+so it will disconnect if the client only listens and sends nothing to<br>
+the socket, correct?<br>
+<br>
+<br></div>
+2013/10/15 Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>><div class="im"><br>
+<br>
+    The socket connected to the client.<br>
+<br>
+    TCP isn't perfect, there is no way to be 100% sure the client is<br>
+    still connected, hence the timeout. If the client is still up you<br>
+    should make it reconnect.<br>
+<br>
+<br>
+    On 10/16/2013 04:55 AM, akonsu wrote:<br>
+<br>
+        Hello,<br>
+<br>
+        the documentation for `init` at<br></div>
+        <a href="http://ninenines.eu/docs/en/__cowboy/HEAD/manual/cowboy___loop_handler" target="_blank">http://ninenines.eu/docs/en/__<u></u>cowboy/HEAD/manual/cowboy___<u></u>loop_handler</a><div class="im"><br>
+        <<a href="http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/manual/cowboy_<u></u>loop_handler</a>><br>
+        says:<br>
+<br>
+        The receive loop will run for a duration of up to Timeout<br>
+        milliseconds<br>
+        after it last received data from the socket, at which point it<br>
+        will stop<br>
+        and send a 204 No Content reply.<br>
+<br>
+        What socket does it refer to? I had an impression that the loop<br>
+        handles<br>
+        erlang messages. Do these messages come through a socket (sorry<br>
+        about a<br>
+        trivial question, but I am new to erlang), and this is the<br>
+        socket that<br>
+        the docs talk about?<br>
+<br>
+        The reason why I am asking is because I used to have a Timeout<br>
+        of 60000,<br>
+        and even though messages kept coming non stop, it still kept<br>
+        disconnecting after a minute, until I set Timeout to infinity.<br>
+<br>
+        thanks<br>
+        Konstantin<br>
+<br>
+<br></div>
+        ______________________________<u></u>___________________<br>
+        Extend mailing list<br>
+        <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a> <mailto:<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.<u></u>ninenines.eu</a>><br>
+        <a href="http://lists.ninenines.eu:81/__listinfo/extend" target="_blank">http://lists.ninenines.eu:81/_<u></u>_listinfo/extend</a><div class="im"><br>
+        <<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a>><br>
+<br>
+<br>
+<br>
+    --<br>
+    Loďc Hoguin<br>
+    Erlang Cowboy<br>
+    Nine Nines<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+</div></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loïc Hoguin</font></span><div class="HOEnZb"><div class="h5"><br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131015/591e8649/attachment.html b/_build/static/archives/extend/attachments/20131015/591e8649/attachment.html new file mode 100644 index 00000000..d06f0bbe --- /dev/null +++ b/_build/static/archives/extend/attachments/20131015/591e8649/attachment.html @@ -0,0 +1,46 @@ + +<div dir="ltr">so it will disconnect if the client only listens and sends nothing to the socket, correct?</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/15 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The socket connected to the client.<br>
+<br>
+TCP isn't perfect, there is no way to be 100% sure the client is still connected, hence the timeout. If the client is still up you should make it reconnect.<div><div class="h5"><br>
+<br>
+On 10/16/2013 04:55 AM, akonsu wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hello,<br>
+<br>
+the documentation for `init` at<br>
+<a href="http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler" target="_blank">http://ninenines.eu/docs/en/<u></u>cowboy/HEAD/manual/cowboy_<u></u>loop_handler</a> says:<br>
+<br>
+The receive loop will run for a duration of up to Timeout milliseconds<br>
+after it last received data from the socket, at which point it will stop<br>
+and send a 204 No Content reply.<br>
+<br>
+What socket does it refer to? I had an impression that the loop handles<br>
+erlang messages. Do these messages come through a socket (sorry about a<br>
+trivial question, but I am new to erlang), and this is the socket that<br>
+the docs talk about?<br>
+<br>
+The reason why I am asking is because I used to have a Timeout of 60000,<br>
+and even though messages kept coming non stop, it still kept<br>
+disconnecting after a minute, until I set Timeout to infinity.<br>
+<br>
+thanks<br>
+Konstantin<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+<br>
+-- <br>
+Loďc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131015/94506752/attachment.html b/_build/static/archives/extend/attachments/20131015/94506752/attachment.html new file mode 100644 index 00000000..a847b802 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131015/94506752/attachment.html @@ -0,0 +1,8 @@ + +<div dir="ltr">Hello,<div><br></div><div>the documentation for `init` at <a href="http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler">http://ninenines.eu/docs/en/cowboy/HEAD/manual/cowboy_loop_handler</a> says:</div>
+<div><br></div><div>The receive loop will run for a duration of up to Timeout milliseconds after it last received data from the socket, at which point it will stop and send a 204 No Content reply.<br></div><div><br></div>
+<div>What socket does it refer to? I had an impression that the loop handles erlang messages. Do these messages come through a socket (sorry about a trivial question, but I am new to erlang), and this is the socket that the docs talk about?</div>
+<div><br></div><div>The reason why I am asking is because I used to have a Timeout of 60000, and even though messages kept coming non stop, it still kept disconnecting after a minute, until I set Timeout to infinity.</div>
+<div><br></div><div>thanks</div><div>Konstantin</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131015/bac10460/attachment.html b/_build/static/archives/extend/attachments/20131015/bac10460/attachment.html new file mode 100644 index 00000000..75224869 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131015/bac10460/attachment.html @@ -0,0 +1,9 @@ + +<div dir="ltr">1. do you mean that there is no way on the server side to tell if the client has disconnected?<div><br><div>2. if I use a normal handler, I will still run into the same problem, it does not matter which handler I use, from the standpoint of deciding whether the client is still there, right?</div>
+<div><br></div><div>I am confused as to how I can implement my streaming and not drop the connection on each client and yet make sure I do close the connections when the clients disconnect...</div><div><br></div><div><div class="gmail_extra">
+<br><div class="gmail_quote">2013/10/15 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Infinite is bad practice, yes. Infinite means some connections will *never* be closed, eating FDs and memory for nothing.<br>
+<br>
+I'm not sure why you want to receive messages, you could just use a normal handler that asks for more data, sends it, ask for more data, sends it, etc.<div class="im"><br></div></blockquote></div></div></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131016/abe38a1a/attachment.html b/_build/static/archives/extend/attachments/20131016/abe38a1a/attachment.html new file mode 100644 index 00000000..9672e317 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131016/abe38a1a/attachment.html @@ -0,0 +1,9 @@ + +<div dir="ltr">ok. the data that I need to send are coming as erlang messages to the process that runs my handler. so it sounds like if I want to use the "normal" cowboy_http_handler, then I need a receive loop inside handle(Req, State) callback, right? Basically, my response stream will potentially never end, I do not know how to handle this properly in cowboy...<br>
+<div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/16 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
+Loop handlers are designed to wait for a long time with the socket *idle* and then eventually send one response then close the socket. Things like long-polling.<br>
+<br>
+What you are doing is just streaming, for which you do not need a timeout because the socket isn't idle. You are just sending a large response, and normal handlers are perfectly capable of doing that.<div class="im">
+<br></div></blockquote></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131016/edbc349c/attachment.html b/_build/static/archives/extend/attachments/20131016/edbc349c/attachment.html new file mode 100644 index 00000000..26d032bf --- /dev/null +++ b/_build/static/archives/extend/attachments/20131016/edbc349c/attachment.html @@ -0,0 +1,46 @@ + +<div dir="ltr">thanks. one more question if you do not mind. you say that we need timeouts when the client does not notify us when it dies. but then you say that if the client dies then the socket write will fail. to me this sounds like a contradiction. would you please clarify?<div>
+<br></div><div>(I assume that this is the problem that we are discussing: <a href="http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect">http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect</a>, right?)</div>
+</div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/10/16 Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div class="im">On 10/16/2013 05:48 AM, akonsu wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+1. do you mean that there is no way on the server side to tell if the<br>
+client has disconnected?<br>
+</blockquote>
+<br></div>
+There are ways, and Cowboy will happily detect them. There's also the problem that a side may be closed without the other side knowing about it, which is why you need timeouts.<div class="im"><br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+2. if I use a normal handler, I will still run into the same problem, it<br>
+does not matter which handler I use, from the standpoint of deciding<br>
+whether the client is still there, right?<br>
+</blockquote>
+<br></div>
+If the client is gone, the send will fail. Normal handlers are pretty much the same except they don't have a timeout, because your code has an explicit end.<br>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+I am confused as to how I can implement my streaming and not drop the<br>
+connection on each client and yet make sure I do close the connections<br>
+when the clients disconnect...<br>
+<br>
+<br></div>
+2013/10/15 Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>><div class="im"><br>
+<br>
+    Infinite is bad practice, yes. Infinite means some connections will<br>
+    *never* be closed, eating FDs and memory for nothing.<br>
+<br>
+    I'm not sure why you want to receive messages, you could just use a<br>
+    normal handler that asks for more data, sends it, ask for more data,<br>
+    sends it, etc.<br>
+<br>
+</div></blockquote>
+<br><div class="HOEnZb"><div class="h5">
+<br>
+-- <br>
+Loïc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131018/00d4df12/attachment.html b/_build/static/archives/extend/attachments/20131018/00d4df12/attachment.html new file mode 100644 index 00000000..71bf2ae1 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131018/00d4df12/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">Hi,<div><br></div><div>I have a handler that spawns a process and links to this process. the new process does not trap exit signals.<div><br></div><div>When I open the URL that is handled by this handler in the browser, and stop the browser before the handler finishes the request, the handler is terminated and my terminate function is called with the Reason set to {error,closed} or something similar.</div>
+<div><br></div><div>When this happens, the linked process does not get killed, so I have to call exit on it from the terminate function.</div><div><br></div><div>is this by design? I suppose when I cancel the browser request, the handler is exited with normal exit code, correct? could you point me to the source code for that part? it is perhaps in the "ranch" repo, no?</div>
+</div><div><br></div><div>thanks in advance</div><div><br></div><div>konstantin</div><div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131029/3df30c1d/attachment.html b/_build/static/archives/extend/attachments/20131029/3df30c1d/attachment.html new file mode 100644 index 00000000..fed7bc12 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131029/3df30c1d/attachment.html @@ -0,0 +1,10 @@ + +<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div><br>On 29 Oct 2013, at 21:25, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com">daniel.goertzen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div>My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:<br><br><br><span style="font-family:courier new,monospace">init(_Transport, _Req, _Opts) -><br>
+        {upgrade, protocol, cowboy_rest}.<br><br>content_types_provided(Req, State) -><br>    {[{<<"application/json">>, get_json}], Req, State}.<br><br>get_json(Req0, State) -><br>    {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+<br>    case catch other_module:request(Params) of<br>        {'EXIT', {badarg, _}} -><br></span></div><div><span style="font-family:courier new,monospace">            hmmm, Params were bad and I would like to return a 404 code now.<br>
+</span></div><div><span style="font-family:courier new,monospace">        Result -><br>            {jiffy:encode(Result), Req1, State}<br>    end.<br></span><br><br><br></div><div>So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+</div><div><br>- return a 200 (ok) response with data.<br></div><div>- crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.<br></div><div><div><br><br></div><div>Is there some other way to cause a 404 response?<br>
+<br></div><div>I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+</div><div><br></div><div>Thanks,<br>Dan.<br></div></div></div></div></div>
+</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a></span><br><span><a href="http://lists.ninenines.eu:81/listinfo/extend">http://lists.ninenines.eu:81/listinfo/extend</a></span><br></div></blockquote></body></html> + diff --git a/_build/static/archives/extend/attachments/20131029/5fc5da75/attachment.html b/_build/static/archives/extend/attachments/20131029/5fc5da75/attachment.html new file mode 100644 index 00000000..32f4e9de --- /dev/null +++ b/_build/static/archives/extend/attachments/20131029/5fc5da75/attachment.html @@ -0,0 +1,26 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
+<div>Hi,</div>
+<div><br>
+</div>
+<div>I'm using cowboy_rest for a part of our api to handle POST requests. Under certain conditions, I would like to redirect to a new location (based on availability of the redirect qs parameter).</div>
+<div>I was unable to get the moved_temporarily/2 callback to work (was not invoked at al). So I just do the 302 myself, using cowboy_req:reply/4. This works, however, every time it produces an error in the emulator process:</div>
+<div> [error] emulator Error in process <0.509.0> on node 'api@dev.loc' with exit value: {function_clause,[{cowboy_req,reply,[204,[],<<0 bytes>>,{http_req,#Port<0.14491>,ranch_tcp,keepalive,<0.509.0>,<<4 bytes>>,'HTTP/1.1',{{10,10,10,1},62197},<<15 bytes>>,undefined,8000,<<26
+ bytes>>,undefined,<<14 bytes>>,[{<<8 bytes>>,<<5 bytes>>}],[{method,<<5 bytes>>}],[{<<4 bytes>>,<<20 bytes>>},{<<10 bytes>>,<<10 bytes>>},{<<14 bytes>>,<<2 bytes>>},{<<6 bytes>>,<<74 bytes>>},{<<6 bytes>>,<<27 bytes>>},{<<10 bytes>>,<<120 bytes>>},{<<12 bytes>>,<<33
+ bytes>>},{<<7 bytes>>,<<54 bytes>>},{<<15 bytes>>,<<17 bytes>>},{<<15 bytes>>,<<14 bytes>>},{<<6 bytes>>,<<245 bytes>>}],[{<<14 bytes>>,34},{<<6 bytes>>,undefined},{<<14 bytes>>,34},{<<12 bytes>>,{<<11 bytes>>,<<21 bytes>>,[]}},{<<17 bytes>>,undefined},{<<13
+ bytes>>,...</div>
+<div><br>
+</div>
+<div>Can you point me out how to (ideally) make use of moved_temporarily/2 or how I can prevent cowboy_rest from wanting to reply with 204 in this case?</div>
+<div><br>
+</div>
+<div>Cheers,</div>
+<div>Rolph</div>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20131029/a9204600/attachment.html b/_build/static/archives/extend/attachments/20131029/a9204600/attachment.html new file mode 100644 index 00000000..b69fae87 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131029/a9204600/attachment.html @@ -0,0 +1,10 @@ + +<div dir="ltr"><div><div><div>My situation is that I have a rest handler that may fail due to invalid url segments. Example situation:<br><br><br><span style="font-family:courier new,monospace">init(_Transport, _Req, _Opts) -><br>
+ {upgrade, protocol, cowboy_rest}.<br><br>content_types_provided(Req, State) -><br> {[{<<"application/json">>, get_json}], Req, State}.<br><br>get_json(Req0, State) -><br> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+<br> case catch other_module:request(Params) of<br>  {'EXIT', {badarg, _}} -><br></span></div><div><span style="font-family:courier new,monospace">   hmmm, Params were bad and I would like to return a 404 code now.<br>
+</span></div><div><span style="font-family:courier new,monospace">   Result -><br>   {jiffy:encode(Result), Req1, State}<br> end.<br></span><br><br><br></div><div>So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+</div><div><br>- return a 200 (ok) response with data.<br></div><div>- crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want.<br></div><div><div><br><br></div><div>Is there some other way to cause a 404 response?<br>
+<br></div><div>I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+</div><div><br></div><div>Thanks,<br>Dan.<br></div></div></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131030/0ab7c8ee/attachment.html b/_build/static/archives/extend/attachments/20131030/0ab7c8ee/attachment.html new file mode 100644 index 00000000..79bd8234 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131030/0ab7c8ee/attachment.html @@ -0,0 +1,38 @@ + +<div dir="ltr"><div>Returning 'halt' caused a status code of 204.<br><br></div>Dan.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 10:27 AM, Ivan uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Instead of <<"this body ignored">> can you return the atom halt?</div><div><br>
+</div><div>#dontevenhaveanyofmycodewithme:(</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div><div class="h5"><div><br>On 30 Oct 2013, at 15:58, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br>
+<br></div><blockquote type="cite"><div><div dir="ltr">Well, this sort of works. I tried this in the response handler:<br><div><br>   {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),<br>
+   {<<"this body gets ignored">>, Req2, State};<br>
+<br><br><br></div><div>The client receives a 404 response, but cowboy crashes:<br><br>=ERROR REPORT==== 8-Sep-2013::22:22:03 ===<br>Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... <br>
+
+<br><br><br></div><div>The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail. </div><br><div>Dan.<br></div><div><br></div></div><div class="gmail_extra">
+
+<br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+<div dir="auto"><div>Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ...</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div>
+<div>
+<div><div><br>On 29 Oct 2013, at 21:25, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">
+<div><div><div>My situation is that I have a rest handler that may fail due to invalid url segments. Example situation:<br><br><br><span style="font-family:courier new,monospace">init(_Transport, _Req, _Opts) -><br>
+ {upgrade, protocol, cowboy_rest}.<br><br>content_types_provided(Req, State) -><br> {[{<<"application/json">>, get_json}], Req, State}.<br><br>get_json(Req0, State) -><br> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+
+
+<br> case catch other_module:request(Params) of<br>  {'EXIT', {badarg, _}} -><br></span></div><div><span style="font-family:courier new,monospace">   hmmm, Params were bad and I would like to return a 404 code now.<br>
+
+
+</span></div><div><span style="font-family:courier new,monospace">   Result -><br>   {jiffy:encode(Result), Req1, State}<br> end.<br></span><br><br><br></div><div>So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+
+
+</div><div><br>- return a 200 (ok) response with data.<br></div><div>- crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want.<br></div><div><div><br><br></div><div>Is there some other way to cause a 404 response?<br>
+
+
+<br></div><div>I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+
+
+</div><div><br></div><div>Thanks,<br>Dan.<br></div></div></div></div></div>
+</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a></span><br>
+
+<span><a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a></span><br></div></blockquote></div></blockquote></div><br></div>
+</div></blockquote></div></div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131030/3ea4ac64/attachment.html b/_build/static/archives/extend/attachments/20131030/3ea4ac64/attachment.html new file mode 100644 index 00000000..751be332 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131030/3ea4ac64/attachment.html @@ -0,0 +1,88 @@ + +<div dir="ltr"><div>That's what I was looking for, thanks!<br><br></div><div>Dan.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 10:25 AM, Tilman Holschuh <span dir="ltr"><<a href="mailto:tilman.holschuh@gmail.com" target="_blank">tilman.holschuh@gmail.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Why not let resource_exists/2 return false when your resource does not exist? You will get 404 on false. This way you separate the implementation for turning your data to json from checking if the request went to the correct resource.<br>
+
+<span class="HOEnZb"><font color="#888888"><br>
+- Tilman<br>
+</font></span><div class="HOEnZb"><div class="h5"><br>
+On 2013-10-30, at 7:58 AM, Daniel Goertzen wrote:<br>
+<br>
+> Well, this sort of works. I tried this in the response handler:<br>
+><br>
+>       {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),<br>
+>       {<<"this body gets ignored">>, Req2, State};<br>
+><br>
+><br>
+><br>
+> The client receives a 404 response, but cowboy crashes:<br>
+><br>
+> =ERROR REPORT==== 8-Sep-2013::22:22:03 ===<br>
+> Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[...<br>
+
+><br>
+><br>
+><br>
+> The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail.<br>
+><br>
+> Dan.<br>
+><br>
+><br>
+><br>
+> On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <<a href="mailto:ivan@llaisdy.com">ivan@llaisdy.com</a>> wrote:<br>
+> Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ...<br>
+><br>
+> Ivan<br>
+><br>
+> --<br>
+> festina lente<br>
+><br>
+><br>
+> On 29 Oct 2013, at 21:25, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com">daniel.goertzen@gmail.com</a>> wrote:<br>
+><br>
+>> My situation is that I have a rest handler that may fail due to invalid url segments. Example situation:<br>
+>><br>
+>><br>
+>> init(_Transport, _Req, _Opts) -><br>
+>>     {upgrade, protocol, cowboy_rest}.<br>
+>><br>
+>> content_types_provided(Req, State) -><br>
+>>   {[{<<"application/json">>, get_json}], Req, State}.<br>
+>><br>
+>> get_json(Req0, State) -><br>
+>>   {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+>><br>
+>>   case catch other_module:request(Params) of<br>
+>>     {'EXIT', {badarg, _}} -><br>
+>>       hmmm, Params were bad and I would like to return a 404 code now.<br>
+>>     Result -><br>
+>>       {jiffy:encode(Result), Req1, State}<br>
+>>   end.<br>
+>><br>
+>><br>
+>><br>
+>> So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+>><br>
+>> - return a 200 (ok) response with data.<br>
+>> - crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want.<br>
+>><br>
+>><br>
+>> Is there some other way to cause a 404 response?<br>
+>><br>
+>> I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+
+>><br>
+>> Thanks,<br>
+>> Dan.<br>
+>> _______________________________________________<br>
+>> Extend mailing list<br>
+>> <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>
+>> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+><br>
+> _______________________________________________<br>
+> Extend mailing list<br>
+> <a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a><br>
+> <a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a><br>
+<br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131030/460453c8/attachment.html b/_build/static/archives/extend/attachments/20131030/460453c8/attachment.html new file mode 100644 index 00000000..ee5dfd0f --- /dev/null +++ b/_build/static/archives/extend/attachments/20131030/460453c8/attachment.html @@ -0,0 +1,23 @@ + +<div dir="ltr">Well, this sort of works. I tried this in the response handler:<br><div><br>   {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),<br>   {<<"this body gets ignored">>, Req2, State};<br>
+<br><br><br></div><div>The client receives a 404 response, but cowboy crashes:<br><br>=ERROR REPORT==== 8-Sep-2013::22:22:03 ===<br>Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... <br>
+<br><br><br></div><div>The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail. </div><br><div>Dan.<br></div><div><br></div></div><div class="gmail_extra">
+<br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div dir="auto"><div>Sorry for terse but I only have a phone. Why can't you return a 404 here? Using something like cowboy:reply(404, ...</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div>
+<div class="h5"><div><br>On 29 Oct 2013, at 21:25, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">
+<div><div><div>My situation is that I have a rest handler that may fail due to invalid url segments. Example situation:<br><br><br><span style="font-family:courier new,monospace">init(_Transport, _Req, _Opts) -><br>
+ {upgrade, protocol, cowboy_rest}.<br><br>content_types_provided(Req, State) -><br> {[{<<"application/json">>, get_json}], Req, State}.<br><br>get_json(Req0, State) -><br> {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+
+<br> case catch other_module:request(Params) of<br>  {'EXIT', {badarg, _}} -><br></span></div><div><span style="font-family:courier new,monospace">   hmmm, Params were bad and I would like to return a 404 code now.<br>
+
+</span></div><div><span style="font-family:courier new,monospace">   Result -><br>   {jiffy:encode(Result), Req1, State}<br> end.<br></span><br><br><br></div><div>So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+
+</div><div><br>- return a 200 (ok) response with data.<br></div><div>- crash and cause a 500 (Internal Server Error) response to be returned. Not exactly the sentiment I want.<br></div><div><div><br><br></div><div>Is there some other way to cause a 404 response?<br>
+
+<br></div><div>I realize I could add path constraint functions, but I will be replicating logic from my underlying request function. Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+
+</div><div><br></div><div>Thanks,<br>Dan.<br></div></div></div></div></div>
+</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a></span><br>
+<span><a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a></span><br></div></blockquote></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131030/6e8ec2f0/attachment.html b/_build/static/archives/extend/attachments/20131030/6e8ec2f0/attachment.html new file mode 100644 index 00000000..e7d1542c --- /dev/null +++ b/_build/static/archives/extend/attachments/20131030/6e8ec2f0/attachment.html @@ -0,0 +1,23 @@ + +<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Instead of <<"this body ignored">> can you return the atom halt?</div><div><br></div><div>#dontevenhaveanyofmycodewithme:(</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div><br>On 30 Oct 2013, at 15:58, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com">daniel.goertzen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Well, this sort of works.  I tried this in the response handler:<br><div><br>            {ok, Req2} = cowboy_req:reply(404, [] , <<"this is the body that gets used">>, Req1),<br>            {<<"this body gets ignored">>, Req2, State};<br>
+<br><br><br></div><div>The client receives a 404 response, but cowboy crashes:<br><br>=ERROR REPORT==== 8-Sep-2013::22:22:03 ===<br>Error in process <0.131.0> with exit value: {function_clause,[{cowboy_req,reply,[200,[],<<31 bytes>>,{http_req,#Port<0.1208>,ranch_tcp,keepalive,<0.131.0>,<<3 bytes>>,'HTTP/1.1',{{192,168,1,187},51017},<<12 bytes>>,undefined,80,<<24 bytes>>,undefined,<<0 bytes>>,undefined,[{channel_num,3}],[{<<10 bytes>>,<<11 bytes>>},{<<4 bytes>>,<<12 bytes>>},{<<6 bytes>>,<<3 bytes>>}],[{<<17 bytes>>,undefined},{<<13 bytes>>,undefined},{<<19 bytes>>,undefined},{<<8 bytes>>,undefined},{<<6 bytes>>,[... <br>
+<br><br><br></div><div>The issue is that the REST wrapper wants to do the cowboy_req:reply(), and when we do the call we cause the wrapper's call to fail. </div><br><div>Dan.<br></div><div><br></div></div><div class="gmail_extra">
+<br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 4:01 PM, Ivan uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+<div dir="auto"><div>Sorry for terse but I only have a phone. Why can't you return a 404 here?  Using something like cowboy:reply(404, ...</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div>
+<div class="h5"><div><br>On 29 Oct 2013, at 21:25, Daniel Goertzen <<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">
+<div><div><div>My situation is that I have a rest handler that may fail due to invalid url segments.  Example situation:<br><br><br><span style="font-family:courier new,monospace">init(_Transport, _Req, _Opts) -><br>
+        {upgrade, protocol, cowboy_rest}.<br><br>content_types_provided(Req, State) -><br>    {[{<<"application/json">>, get_json}], Req, State}.<br><br>get_json(Req0, State) -><br>    {Params, Req1} = lists:mapfoldl(fun cowboy_req:binding/2, Req0, [param1, param2, param3, ....]),<br>
+
+<br>    case catch other_module:request(Params) of<br>        {'EXIT', {badarg, _}} -><br></span></div><div><span style="font-family:courier new,monospace">            hmmm, Params were bad and I would like to return a 404 code now.<br>
+
+</span></div><div><span style="font-family:courier new,monospace">        Result -><br>            {jiffy:encode(Result), Req1, State}<br>    end.<br></span><br><br><br></div><div>So I would like to return a 404 code when my underlying request function fails, but it appears my choices are:<br>
+
+</div><div><br>- return a 200 (ok) response with data.<br></div><div>- crash and cause a 500 (Internal Server Error) response to be returned.  Not exactly the sentiment I want.<br></div><div><div><br><br></div><div>Is there some other way to cause a 404 response?<br>
+
+<br></div><div>I realize I could add path constraint functions, but I will be replicating logic from my underlying request function.  Furthermore, the constraint functions consider parameters in isolation, so that won't work if the validity of parameters is coupled.<br>
+
+</div><div><br></div><div>Thanks,<br>Dan.<br></div></div></div></div></div>
+</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a></span><br>
+<span><a href="http://lists.ninenines.eu:81/listinfo/extend" target="_blank">http://lists.ninenines.eu:81/listinfo/extend</a></span><br></div></blockquote></div></blockquote></div><br></div>
+</div></blockquote></body></html> + diff --git a/_build/static/archives/extend/attachments/20131115/79d7b0ce/attachment.html b/_build/static/archives/extend/attachments/20131115/79d7b0ce/attachment.html new file mode 100644 index 00000000..77e3d85d --- /dev/null +++ b/_build/static/archives/extend/attachments/20131115/79d7b0ce/attachment.html @@ -0,0 +1,45 @@ + +<p>Very excited to hear of this. Cowboy is very good to use.</p>
+<div class="gmail_quote">On Nov 15, 2013 12:23 AM, "Loc Hoguin" <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hello shiny people,<br>
+<br>
+Cowboy 0.9.0 has been released. Ranch 0.9.0 has been released too! So let's start with that.<br>
+<br>
+Ranch 0.9.0 is just stability improvements, better error reporting and a couple new SSL options.<br>
+<br>
+Cowboy 0.9.0 is using it of course, and also has official SPDY support (documented and everything!), a revamped cowboy_static (built-in mimetypes support, and also documented), tons of additions to the guide, tons of user patches and other changes you can find here:<br>
+
+<br>
+ * <a href="https://github.com/extend/cowboy/blob/master/CHANGELOG.md" target="_blank">https://github.com/extend/<u></u>cowboy/blob/master/CHANGELOG.<u></u>md</a><br>
+<br>
+Which reminds me, I want to thank all 70 awesome contributors (myself included) that make the Cowboy project so fun to work on! So, thank you!<br>
+<br>
+When upgrading, please be aware that:<br>
+<br>
+ * A dependency has been added, cowlib<br>
+ * Various undocumented functions have been moved to cowlib<br>
+ * The options for cowboy_static changed a lot, so read the guide<br>
+ * You need to set ERL_LIBS or equivalent for cowboy_static to find your private directory now<br>
+<br>
+You can find the updated guide on <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a> BUT do note that I'm migrating the site so if you do not see "Contribute to this site" in the bottom left next to "Contact", then you are on the old version and should probably head to github for your documentation needs, or use the files in your clone directly. I also have improvements left to make to the site to make navigating documentation easier, so stay tuned!<br>
+
+<br>
+Speaking of the guide, now all the examples, but also the getting started chapter of the guide, are releases. I am hopeful that this will make more people use releases by default instead of an awful start.sh script.<br>
+<br>
+For details on what's coming up next, see the ROADMAP. Next step (0.10) is finishing the request body work, fixing some timeout issues and adding proper multipart support for both requests and responses. This will be the last significant step before 1.0. I have hopes that all this will be ready around the time R17 is released.<br>
+
+<br>
+So yeah, enjoy! And as always please forward any feedback, especially related to the user guide as this is my main focus now.<br>
+<br>
+-- <br>
+Loc Hoguin<br>
+Erlang Cowboy<br>
+Nine Nines<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+______________________________<u></u>_________________<br>
+erlang-questions mailing list<br>
+<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
+<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
+</blockquote></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131117/41119d53/attachment.html b/_build/static/archives/extend/attachments/20131117/41119d53/attachment.html new file mode 100644 index 00000000..c7dbde9a --- /dev/null +++ b/_build/static/archives/extend/attachments/20131117/41119d53/attachment.html @@ -0,0 +1,5 @@ + +<div dir="ltr">Hello,<div><br></div><div>if I call cowboy_req:chunk on the same Req from several processes that run simultaneously, I am guaranteed that the chunks that these processes write to the socket will not interleave with each other?</div>
+<div><br></div><div>thanks</div><div>Konstantin</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131120/6c3ab980/attachment.html b/_build/static/archives/extend/attachments/20131120/6c3ab980/attachment.html new file mode 100644 index 00000000..5c0ee54e --- /dev/null +++ b/_build/static/archives/extend/attachments/20131120/6c3ab980/attachment.html @@ -0,0 +1,34 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
+<div>Cowfolk ,</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div>Just upgraded to cowboy 0.9.0  from 0.8.7.   Seeing this cowboy_clock error on all REST requests.    Anyone seen it?  Investigating now.</div>
+<div><br>
+</div>
+<div>{badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]}</div>
+<div><br>
+</div>
+<div><br>
+</div>
+<div>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">=ERROR REPORT==== 20-Nov-2013::16:24:59 ===</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">Ranch listener http had connection process started with cowboy_protocol:start_link/4 at <0.326.0> exit with reason: {badarg,[{ets,lookup_element,[cowboy_clock,rfc1123,2],[]},{cowboy_clock,rfc1123,0,[{file,"src/cowboy_clock.erl"},{line,62}]},{cowboy_req,reply_no_compress,8,[{file,"src/cowboy_req.erl"},{line,1056}]},{cowboy_req,reply,4,[{file,"src/cowboy_req.erl"},{line,1009}]},{cowboy_rest,respond,3,[{file,"src/cowboy_rest.erl"},{line,996}]},{cowboy_rest,set_resp_body,2,[{file,"src/cowboy_rest.erl"},{line,876}]},{cowboy_protocol,execute,4,[{file,"src/cowboy_protocol.erl"},{line,529}]}]}</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">-kb</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+</div>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20131120/7808a87a/attachment.html b/_build/static/archives/extend/attachments/20131120/7808a87a/attachment.html new file mode 100644 index 00000000..434e143b --- /dev/null +++ b/_build/static/archives/extend/attachments/20131120/7808a87a/attachment.html @@ -0,0 +1,8 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20131120/792230f4/attachment.html b/_build/static/archives/extend/attachments/20131120/792230f4/attachment.html new file mode 100644 index 00000000..bc151557 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131120/792230f4/attachment.html @@ -0,0 +1,41 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
+<div>Because I wasnt starting cow_lib.   Dont ask.  </div>
+<div><br>
+</div>
+<span id="OLK_SRC_BODY_SECTION">
+<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
+<span style="font-weight:bold">From: </span><Brown>, Kevin <<a href="mailto:kevin.brown@turner.com">kevin.brown@turner.com</a>><br>
+<span style="font-weight:bold">Date: </span>Wednesday, November 20, 2013 at 5:11 PM<br>
+<span style="font-weight:bold">To: </span>"<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>" <<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>><br>
+<span style="font-weight:bold">Subject: </span>Re: cowboy 0.9.0: badarg ets:lookup_element cowboy_clock<br>
+</div>
+<div><br>
+</div>
+<div>
+<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
+<div><span style="font-size: 15px;">cowboy_clock not started.    Not sure why that is, but..   </span></div>
+<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
+<br>
+</div>
+<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
+<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
+<span style="font-weight:bold">From: </span><Brown>, Kevin <<a href="mailto:kevin.brown@turner.com">kevin.brown@turner.com</a>><br>
+<span style="font-weight:bold">Date: </span>Wednesday, November 20, 2013 at 4:29 PM<br>
+<span style="font-weight:bold">To: </span>"<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>" <<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>><br>
+<span style="font-weight:bold">Subject: </span>cowboy 0.9.0: badarg ets:lookup_element cowboy_clock<br>
+</div>
+<div><br>
+</div>
+<br class="Apple-interchange-newline">
+</span></div>
+</div>
+</span>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20131120/82981048/attachment.html b/_build/static/archives/extend/attachments/20131120/82981048/attachment.html new file mode 100644 index 00000000..b1765579 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131120/82981048/attachment.html @@ -0,0 +1,25 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
+<div><span style="font-size: 15px;">cowboy_clock not started.    Not sure why that is, but..   </span></div>
+<div style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
+<br>
+</div>
+<span id="OLK_SRC_BODY_SECTION" style="color: rgb(0, 0, 0); font-family: Calibri, sans-serif; font-size: 14px;">
+<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
+<span style="font-weight:bold">From: </span><Brown>, Kevin <<a href="mailto:kevin.brown@turner.com">kevin.brown@turner.com</a>><br>
+<span style="font-weight:bold">Date: </span>Wednesday, November 20, 2013 at 4:29 PM<br>
+<span style="font-weight:bold">To: </span>"<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>" <<a href="mailto:extend@lists.ninenines.eu">extend@lists.ninenines.eu</a>><br>
+<span style="font-weight:bold">Subject: </span>cowboy 0.9.0: badarg ets:lookup_element cowboy_clock<br>
+</div>
+<div><br>
+</div>
+<br class="Apple-interchange-newline">
+</span>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20131121/7d69dbf7/attachment.html b/_build/static/archives/extend/attachments/20131121/7d69dbf7/attachment.html new file mode 100644 index 00000000..5d9299b6 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131121/7d69dbf7/attachment.html @@ -0,0 +1,3 @@ + +<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hello,<div><br></div><div>For a Cowboy-based project Im trying to use stable (<a href="https://github.com/dvv/stable">dvv/stable</a>, written by Vladimir Dronnikov). I keep running into problems. I contacted Vladimir and he stated that the current version of stable was compatible with Cowboy 0.8 and that he didnt have the time to keep up with new cowboy releases. Is any of the list members using stable in a cowboy based project?</div><div><br></div><div>Kind regards,</div><div><br></div><div>Jan Willem Luiten</div></body></html> + diff --git a/_build/static/archives/extend/attachments/20131122/11ccc1ef/attachment.html b/_build/static/archives/extend/attachments/20131122/11ccc1ef/attachment.html new file mode 100644 index 00000000..ab98742d --- /dev/null +++ b/_build/static/archives/extend/attachments/20131122/11ccc1ef/attachment.html @@ -0,0 +1,13 @@ + +<font face="arial" size="2"><p style="margin:0;padding:0;">Hello,</p>
+<p style="margin:0;padding:0;"> </p>
+<p style="margin:0;padding:0;">Does erlang.mk replace rebar?</p>
+<p style="margin:0;padding:0;"> </p>
+<p style="margin:0;padding:0;">Thanks,</p>
+<p style="margin:0;padding:0;"> </p>
+<p style="margin:0;padding:0;">LRP</p>
+<p style="margin:0;padding:0;"> </p>
+<!--WM_COMPOSE_SIGNATURE_START-->
+<p style="margin:0;padding:0;">*********************************************<br />My books:<br /><br />THE GOSPEL OF ASHES<br />http://thegospelofashes.com<br /><br />Strength is not enough. Do they have the courage <br />and the cunning? Can they survive long enough to <br />save the lives of millions?  <br /><br />FREEIN' PANCHO<br />http://freeinpancho.com<br /><br />A community of misfits help a troubled boy find his way <br /><br />AYA TAKEO<br />http://ayatakeo.com<br /><br />Star-crossed love, war and power in an alternative <br />universe<br /><br />Available through Amazon or by request from your <br />favorite bookstore<br /><br /><br />**********************************************</p>
+<!--WM_COMPOSE_SIGNATURE_END--></font> + diff --git a/_build/static/archives/extend/attachments/20131127/11da2202/attachment.html b/_build/static/archives/extend/attachments/20131127/11da2202/attachment.html new file mode 100644 index 00000000..dad266a1 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131127/11da2202/attachment.html @@ -0,0 +1,8 @@ + +<div dir="ltr">Hi;<div><br></div><div>A post on this can be found <a href="http://dc0d.tumblr.com/post/68278862491/toddling-cowboy-carful-a-windows-on-your-way">here</a> (code on <a href="https://github.com/dc0d/lucky_luke">GitHub</a>).</div>
+<div><br></div><div><div class="gmail_default"><span style="font-family:verdana,sans-serif">​</span><font face="verdana, sans-serif">Are these things this way for a reason? (Because otherwise we I can not get samples to run.)</font></div>
+<div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">1 - I have to add 'cowboy' to application list in myapp.app.src.</font></div>
+<div class="gmail_default"><font face="verdana, sans-serif">2 - I have to add '{http_port, 9000}' to 'env' in myapp.app.src (where in the code should I add it?).</font></div><div class="gmail_default"><font face="verdana, sans-serif">3 - I have to explicitly make sure 'cowlib' is started (ok = application:start(cowlib) and I did not see this anywhere but whitout this, it won't work).</font></div>
+<div class="gmail_default"><font face="verdana, sans-serif"><br></font></div><div class="gmail_default"><font face="verdana, sans-serif">Thanks;</font></div></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131127/20905d98/attachment.html b/_build/static/archives/extend/attachments/20131127/20905d98/attachment.html new file mode 100644 index 00000000..42cb7326 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131127/20905d98/attachment.html @@ -0,0 +1,5 @@ + +<div dir="ltr">Hello,<div><br></div><div>I am seeing an error report in my logs:<div><br></div><div><div>=ERROR REPORT==== 27-Nov-2013::00:22:33 ===</div><div>Ranch listener http had connection process started with cowboy_protocol:start_link/4 at <0.4803.9> exit with reason: {error,closed}</div>
+</div><div><br></div><div>looks like this is not worth investigating. can someone please comment on this error?</div></div><div><br></div><div>thanks</div><div>Konstantin</div><div><br></div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131212/2697fbaa/attachment.html b/_build/static/archives/extend/attachments/20131212/2697fbaa/attachment.html new file mode 100644 index 00000000..235b9b9b --- /dev/null +++ b/_build/static/archives/extend/attachments/20131212/2697fbaa/attachment.html @@ -0,0 +1,13 @@ + +<div dir="ltr"><div>Hi,</div><div></div><div>I am using cowboy for our financial webservice platform. We use token based authentication, but I want to give certain ip adresses full access without authentication. I tried :</div>
+<div></div><div><font face="Consolas"><font size="3">{{</font><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:rgb(0,102,204)!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">IP</code></font><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">, </code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:rgb(0,102,204)!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">Port</code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">}, </code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:rgb(0,102,204)!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">Req2</code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">} = </code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:rgb(255,20,147)!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">cowboy_req:peer</code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">(</code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:rgb(0,102,204)!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">Req</code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">).</code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important"></code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">but IP is always {127,0,0,1} - even on production (where request</code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">are comming from different networks)</code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important"></code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">So my question is basically, Is there any way for me to see </code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">frow which </code><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important">IP adresses the request is comming ?</code></div>
+<div><code style="margin:0px!important;padding:0px!important;outline:0px!important;border-radius:0px!important;border:0px currentColor!important;width:auto!important;text-align:left;color:black!important;text-transform:none;line-height:15.39px;text-indent:0px;letter-spacing:normal;overflow:visible!important;font-family:Consolas,"Bitstream Vera Sans Mono","Courier New",Courier,monospace!important;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;word-spacing:0px;vertical-align:baseline!important;float:none!important;white-space:pre-wrap;min-height:inherit!important;background-image:none!important"></code></div>
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20131215/7c20ac97/attachment.html b/_build/static/archives/extend/attachments/20131215/7c20ac97/attachment.html new file mode 100644 index 00000000..c5889031 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131215/7c20ac97/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">I have recently started using <a href="http://erlang.mk">erlang.mk</a> on MacOS X and OpenBSD, and have discovered that the sed escape \s on line 109 for inserting the module list in *.app does not work as intended on these OSs, because they do not use GNU sed. (\s just means the letter 's', not whitespace as in perl.) I expect all other BSD-based OSs to have the same issue.<div>
+<br></div><div>Please consider using [[:space:]] instead. This works on both MacOS X and OpenBSD, as well as on Linux.<br clear="all"><div><br></div>-- <br>Christopher Vance
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20131227/35c9f6e5/attachment.html b/_build/static/archives/extend/attachments/20131227/35c9f6e5/attachment.html new file mode 100644 index 00000000..402339e2 --- /dev/null +++ b/_build/static/archives/extend/attachments/20131227/35c9f6e5/attachment.html @@ -0,0 +1,3 @@ + +Quick guess, you may have an extra space or \r at the end of the PROJECT line in the Makefile.<br><br>Sent from my ASUS Padfone<br><br>lloyd@writersglen.com wrote:<br><br>>Hello,<br>><br>>*** GOAL: <br>><br>>Modify rest_pastebin in Cowboy examples.<br>><br>>*** PROCEDULE 1: <br>><br>>- Pulled Cowboy, including examples into local workstation<br>>- Copied rest_pastebin to a separate directory<br>>- Execute make<br>>      Make compiles just fine<br>><br>>*** PROCEDUE 2 -- resulting in error<br>><br>>- delete the entire rest_pastebin application and recopy from the Cowboy pull<br>>- change all module names and references from rest_pastebin to tagr. Thus rest_pastebin_sup.erl becomes tagr_sup.erl<br>>- Execute make<br>>      Make returns:<br>><br>>...<br>>make[1]: Leaving directory `/home/lloyd/Erl/CB/tagr/deps/cowboy'<br>> ERLC   toppage_handler.erl tagr_sup.erl tagr_app.erl<br>> ERLC   toppage_handler.erl tagr_sup.erl tagr_app.erl<br>> APP    tagr .app.src<br>>cat: src/tagr: No such file or directory<br>>cat: .app.src: No such file or directory<br>>sed: can't read .app: No such file or directory<br>>make: *** [app] Error 2<br>><br>>Note that the filename tagr.app.src has somehow been modified to tagr .app.src<br>><br>>But here's the directory listing: <br>><br>>-rw-rw-r-- 1 lloyd lloyd  436 Dec 26 18:21 tagr_app.erl<br>>-rw-rw-r-- 1 lloyd lloyd  299 Dec 26 18:22 tagr.app.src<br>>-rw-rw-r-- 1 lloyd lloyd  382 Dec 26 18:22 tagr_sup.erl<br>>-rw-rw-r-- 1 lloyd lloyd 3568 Dec 26 18:23 toppage_handler.erl<br>><br>>I can load tagr.app.src in Vim. Using find I've searched for tagr and .app.src with negative results.<br>><br>>Further mystery. I substituted Rebar for relx. Tagr now compiles just fine.<br>><br>>*** Discussion<br>><br>>I stumbled on this problem after making fairly extensive modifications to rest_pastebin. Through much of the process it compiled just fine until it didn't. And from then on I could not get it to compile. I tried everything I could think of: careful source code review (at least 10 passes), searching for tagr .app.src, trying different names (e.g. tagger), rebooting my computer, etc., etc.<br>><br>>Eventually I reduced the problem to the absolute minimum: Change the string rest_pastebin to tagr everywhere relevant. <br>><br>>It's possible I'm missing something somewhere. But where should I look? Otherwise, is it possible that there is a subtle bug in relx?<br>><br>><br>>Many thanks,<br>><br>>Lloyd<br>><br>><br>><br>><br>><br>> <br>><br>><br>> <br>><br>><br>><br>>*********************************************<br>>My books:<br>><br>>THE GOSPEL OF ASHES<br>>http://thegospelofashes.com<br>><br>>Strength is not enough. Do they have the courage <br>>and the cunning? Can they survive long enough to <br>>save the lives of millions?  <br>><br>>FREEIN' PANCHO<br>>http://freeinpancho.com<br>><br>>A community of misfits help a troubled boy find his way <br>><br>>AYA TAKEO<br>>http://ayatakeo.com<br>><br>>Star-crossed love, war and power in an alternative <br>>universe<br>><br>>Available through Amazon or by request from your <br>>favorite bookstore<br>><br>><br>>**********************************************<br>><br>>_______________________________________________<br>>Extend mailing list<br>>Extend@lists.ninenines.eu<br>>https://lists.ninenines.eu/listinfo/extend<br> + diff --git a/_build/static/archives/extend/attachments/20140203/088e7e6a/attachment.html b/_build/static/archives/extend/attachments/20140203/088e7e6a/attachment.html new file mode 100644 index 00000000..4979bf48 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140203/088e7e6a/attachment.html @@ -0,0 +1,120 @@ + +<div dir="ltr">Ok,<div>it is more clear for me. </div><div><br></div><div>Last question I have is about content_types_provided function.</div><div><br></div><div>Is it safe to define it like this?</div><div><br></div><div>
+
+content_types_provided(R, S) -></div><div>   <span style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px">ContentTypes = [{{<<"application">>, <<"json">>, '*'}, <b>undefined</b>}],</span></div>
+
+<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px">   {ContentTypes, Req, State}.</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px">
+
+Callback in content_types_provided is useless for POST requests, as it won’t be called. </div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px">Is it safe to use <b>undefined </b>atom, to have a source code clearer?</div>
+
+<div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:13px"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If Accept is sent and is different than text/html, yes.<br>
+<br>
+This is how HTTP is defined. If the client says it speaks only content-type X but you can only reply with content-type Y, you error out early and stop processing the request. On the other hand if the client doesn't say what content-type it speaks then the server can choose whichever one it wants.<div class="im">
+
+<br>
+<br>
+On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+My application sends both headers: “Content-type” and “Accept” header<br>
+using POST method.<br>
+<br>
+For POST rest handler do I have to specify both: content_types_accepted<br>
+and content_types_provided to manage this kind of request?<br>
+<br>
+<br>
+On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div><div class="h5">
+<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
+<br>
+    The content-type provided is relevant for any response, not just<br>
+    responses to GET requests. It defaults to text/html. If your client<br>
+    doesn't send that content-type, you have to define the callback.<br>
+<br>
+    I notice that the documentation is incorrect about the relevant<br>
+    methods for this callback, I will open a ticket to fix it soon.<br>
+<br>
+<br>
+    On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:<br>
+<br>
+        Hi,<br>
+        I have a rest handler that accepts POST and PUT requests with<br>
+        “application/json” content type.<br>
+<br>
+        I have content_types_accepted function defined as follows:<br>
+<br>
+        content_types_accepted(Req, State) -><br>
+<br>
+<br>
+        {[{‘application/json', from_json}], Req, State}.<br>
+<br>
+<br>
+<br>
+        The problem I have is within a request that has two headers:<br>
+<br>
+        *Content-type*: application/json<br>
+        *Accept*: application/json<br>
+<br>
+        With this combination I receive *406*.<br>
+<br>
+<br>
+        You can repeat it with test:<br>
+<br>
+        http_SUITE.erl:<br>
+        1072 rest_postonly(Config) -><br>
+        1073     Client = ?config(client, Config),<br>
+        1074     Headers = [<br>
+        1075         {<<"content-type">>, <<"text/plain">>},<br>
+        1076         {<<"accept">>, <<"text/plain">>}<br>
+        1077     ],<br></div></div>
+        1078     {ok, Client2} = cowboy_client:request(<<"POST"<u></u>__>>,<div class="im"><br>
+        1079         build_url("/postonly", Config), Headers, "12345",<br>
+        Client),<br></div>
+        1080     {ok, 204, _, _} = cowboy_client:response(__<u></u>Client2).<div class="im"><br>
+<br>
+        My solution to that was to add a content_types_provided function:<br>
+<br>
+<br>
+        content_types_provided(Req, State) -><br>
+<br>
+<br>
+        ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],<br>
+<br>
+<br>
+        {ContentTypes, Req, State}.<br>
+<br>
+<br>
+<br>
+        But it is useless as *to_json* callback registered is not called<br>
+        anyhow.<br>
+<br>
+        Adding *content_types_provided* function is a correct solution<br>
+        in this case?<br>
+<br>
+        Or I am missing something here?<br>
+        “Accept” header is not relevant only in case of GET requests?<br>
+<br>
+        Thank for help,<br>
+        Łukasz Biedrycki<br>
+<br>
+<br></div>
+        ______________________________<u></u>___________________<br>
+        Extend mailing list<br>
+        <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a> <mailto:<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.<u></u>ninenines.eu</a>><br>
+        <a href="https://lists.ninenines.eu/__listinfo/extend" target="_blank">https://lists.ninenines.eu/__<u></u>listinfo/extend</a><div class="im"><br>
+        <<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a>><br>
+<br>
+<br>
+    --<br>
+    Loïc Hoguin<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+</div></blockquote><div class="HOEnZb"><div class="h5">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140203/104f8577/attachment.html b/_build/static/archives/extend/attachments/20140203/104f8577/attachment.html new file mode 100644 index 00000000..c49806fb --- /dev/null +++ b/_build/static/archives/extend/attachments/20140203/104f8577/attachment.html @@ -0,0 +1,28 @@ + +<div dir="ltr">Hi,<div>I have a rest handler that accepts POST and PUT requests with “application/json” content type. </div><div><br></div><div>I have content_types_accepted function defined as follows:</div><div><br></div>
+
+<div><pre style="font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);line-height:18px"><div class="" id="LC93" style="padding-left:10px"><span class="" style="color:rgb(153,0,0);font-weight:bold">content_types_accepted</span><span class="" style>(</span><span class="" style="color:teal">Req</span><span class="" style>,</span> <span class="" style="color:teal">State</span><span class="" style>)</span> <span class="" style="font-weight:bold">-></span></div>
+
+<div class="" id="LC94" style="padding-left:10px">    <span class="" style>{[{</span><span class="" style>‘application/json'</span><span class="" style>,</span> <span class="" style>from_json</span><span class="" style>}],</span> <span class="" style="color:teal">Req</span><span class="" style>,</span> <span class="" style="color:teal">State</span><span class="" style>}.</span></div>
+
+</pre></div><div><br></div><div>The problem I have is within a request that has two headers:</div><div><br></div><div><b>Content-type</b>: application/json</div><div><b>Accept</b>: application/json</div><div><br></div><div>
+
+With this combination I receive <b>406</b>. </div><div><br></div><div>You can repeat it with test:</div><div><br></div><div>http_SUITE.erl:<br></div><div><div>1072 rest_postonly(Config) -></div><div>1073     Client = ?config(client, Config),</div>
+
+<div>1074     Headers = [</div><div>1075         {<<"content-type">>, <<"text/plain">>},</div><div>1076         {<<"accept">>, <<"text/plain">>}</div>
+
+<div>1077     ],</div><div>1078     {ok, Client2} = cowboy_client:request(<<"POST">>,</div><div>1079         build_url("/postonly", Config), Headers, "12345", Client),</div><div>
+1080     {ok, 204, _, _} = cowboy_client:response(Client2).</div>
+</div><div><br></div><div>My solution to that was to add a content_types_provided function:</div><div><br></div><div><pre style="font-family:Consolas,'Liberation Mono',Courier,monospace;font-size:12px;margin-top:0px;margin-bottom:0px;color:rgb(51,51,51);line-height:18px">
+
+<div class="" id="LC108" style="padding-left:10px"><span class="" style="color:rgb(153,0,0);font-weight:bold">content_types_provided</span><span class="" style>(</span><span class="" style="color:teal">Req</span><span class="" style>,</span> <span class="" style="color:teal">State</span><span class="" style>)</span> <span class="" style="font-weight:bold">-></span></div>
+
+<div class="" id="LC109" style="padding-left:10px">    <span class="" style="color:teal">ContentTypes</span> <span class="" style="font-weight:bold">=</span> <span class="" style>[{{</span><span class="" style="font-weight:bold"><<</span><span class="" style="color:rgb(221,17,68)">"application"</span><span class="" style="font-weight:bold">>></span><span class="" style>,</span> <span class="" style="font-weight:bold"><<</span><span class="" style="color:rgb(221,17,68)">"json"</span><span class="" style="font-weight:bold">>></span><span class="" style>,</span> <span class="" style>'*'</span><span class="" style>},</span> <span class="" style>to_json</span><span class="" style>}],</span></div>
+
+<div class="" id="LC110" style="padding-left:10px">    <span class="" style>{</span><span class="" style="color:teal">ContentTypes</span><span class="" style>,</span> <span class="" style="color:teal">Req</span><span class="" style>,</span> <span class="" style="color:teal">State</span><span class="" style>}.</span></div>
+
+</pre></div><div><br></div><div>But it is useless as <b>to_json</b> callback registered is not called anyhow.</div><div><br></div><div>Adding <b>content_types_provided</b> function is a correct solution in this case?</div>
+
+<div>Or I am missing something here?</div><div>“Accept” header is not relevant only in case of GET requests?</div><div><br></div><div>Thank for help,</div><div>ukasz Biedrycki</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140203/2982cff3/attachment.html b/_build/static/archives/extend/attachments/20140203/2982cff3/attachment.html new file mode 100644 index 00000000..b011e41e --- /dev/null +++ b/_build/static/archives/extend/attachments/20140203/2982cff3/attachment.html @@ -0,0 +1,82 @@ + +<div dir="ltr">My application sends both headers: “Content-type” and “Accept” header using POST method.<div><br><div>For POST rest handler do I have to specify both: content_types_accepted and content_types_provided to manage this kind of request?</div>
+
+</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The content-type provided is relevant for any response, not just responses to GET requests. It defaults to text/html. If your client doesn't send that content-type, you have to define the callback.<br>
+
+
+<br>
+I notice that the documentation is incorrect about the relevant methods for this callback, I will open a ticket to fix it soon.<div class="im"><br>
+<br>
+On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+Hi,<br>
+I have a rest handler that accepts POST and PUT requests with<br>
+“application/json” content type.<br>
+<br>
+I have content_types_accepted function defined as follows:<br>
+<br>
+content_types_accepted(Req, State) -><br>
+<br>
+<br>
+{[{‘application/json', from_json}], Req, State}.<br>
+<br>
+<br>
+<br>
+The problem I have is within a request that has two headers:<br>
+<br></div>
+*Content-type*: application/json<br>
+*Accept*: application/json<br>
+<br>
+With this combination I receive *406*.<div class="im"><br>
+<br>
+You can repeat it with test:<br>
+<br>
+http_SUITE.erl:<br>
+1072 rest_postonly(Config) -><br>
+1073     Client = ?config(client, Config),<br>
+1074     Headers = [<br>
+1075         {<<"content-type">>, <<"text/plain">>},<br>
+1076         {<<"accept">>, <<"text/plain">>}<br>
+1077     ],<br>
+1078     {ok, Client2} = cowboy_client:request(<<"POST"<u></u>>>,<br>
+1079         build_url("/postonly", Config), Headers, "12345", Client),<br>
+1080     {ok, 204, _, _} = cowboy_client:response(<u></u>Client2).<br>
+<br>
+My solution to that was to add a content_types_provided function:<br>
+<br>
+<br>
+content_types_provided(Req, State) -><br>
+<br>
+<br>
+ContentTypes = [{{<<"application">>, <<"json">>, '*'}, to_json}],<br>
+<br>
+<br>
+{ContentTypes, Req, State}.<br>
+<br>
+<br>
+<br></div>
+But it is useless as *to_json* callback registered is not called anyhow.<br>
+<br>
+Adding *content_types_provided* function is a correct solution in this case?<div class="im"><br>
+Or I am missing something here?<br>
+“Accept” header is not relevant only in case of GET requests?<br>
+<br>
+Thank for help,<br>
+Łukasz Biedrycki<br>
+<br>
+<br></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140203/e84f6223/attachment.html b/_build/static/archives/extend/attachments/20140203/e84f6223/attachment.html new file mode 100644 index 00000000..a936c1bd --- /dev/null +++ b/_build/static/archives/extend/attachments/20140203/e84f6223/attachment.html @@ -0,0 +1,171 @@ + +<div dir="ltr">Perfect, thanks a lot!<div>Cheers,</div><div>Ł.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 3, 2014 at 8:15 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure. It won't be called if not a GET or HEAD request so that's probably the best value you can return in your case.<div class="im">
+
+<br>
+<br>
+On 02/03/2014 08:08 PM, Łukasz Biedrycki wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
+Ok,<br>
+it is more clear for me.<br>
+<br>
+Last question I have is about content_types_provided function.<br>
+<br>
+Is it safe to define it like this?<br>
+<br>
+content_types_provided(R, S) -><br></div>
+ContentTypes = [{{<<"application">>, <<"json">>, '*'}, *undefined*}],<div class="im"><br>
+    {ContentTypes, Req, State}.<br>
+<br>
+Callback in content_types_provided is useless for POST requests, as it<br>
+won’t be called.<br></div>
+Is it safe to use *undefined *atom, to have a source code clearer?<div class="im"><br>
+<br>
+<br>
+<br>
+<br>
+On Mon, Feb 3, 2014 at 7:37 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br></div><div class="im">
+<mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>> wrote:<br>
+<br>
+    If Accept is sent and is different than text/html, yes.<br>
+<br>
+    This is how HTTP is defined. If the client says it speaks only<br>
+    content-type X but you can only reply with content-type Y, you error<br>
+    out early and stop processing the request. On the other hand if the<br>
+    client doesn't say what content-type it speaks then the server can<br>
+    choose whichever one it wants.<br>
+<br>
+<br>
+    On 02/03/2014 07:26 PM, Łukasz Biedrycki wrote:<br>
+<br>
+        My application sends both headers: “Content-type” and “Accept”<br>
+        header<br>
+        using POST method.<br>
+<br>
+        For POST rest handler do I have to specify both:<br>
+        content_types_accepted<br>
+        and content_types_provided to manage this kind of request?<br>
+<br>
+<br>
+        On Mon, Feb 3, 2014 at 7:23 PM, Loïc Hoguin <<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a><br>
+        <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>><br></div><div><div class="h5">
+        <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a> <mailto:<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>>>> wrote:<br>
+<br>
+             The content-type provided is relevant for any response, not<br>
+        just<br>
+             responses to GET requests. It defaults to text/html. If<br>
+        your client<br>
+             doesn't send that content-type, you have to define the<br>
+        callback.<br>
+<br>
+             I notice that the documentation is incorrect about the relevant<br>
+             methods for this callback, I will open a ticket to fix it soon.<br>
+<br>
+<br>
+             On 02/03/2014 07:13 PM, Łukasz Biedrycki wrote:<br>
+<br>
+                 Hi,<br>
+                 I have a rest handler that accepts POST and PUT<br>
+        requests with<br>
+                 “application/json” content type.<br>
+<br>
+                 I have content_types_accepted function defined as follows:<br>
+<br>
+                 content_types_accepted(Req, State) -><br>
+<br>
+<br>
+                 {[{‘application/json', from_json}], Req, State}.<br>
+<br>
+<br>
+<br>
+                 The problem I have is within a request that has two<br>
+        headers:<br>
+<br>
+                 *Content-type*: application/json<br>
+                 *Accept*: application/json<br>
+<br>
+                 With this combination I receive *406*.<br>
+<br>
+<br>
+                 You can repeat it with test:<br>
+<br>
+                 http_SUITE.erl:<br>
+                 1072 rest_postonly(Config) -><br>
+                 1073     Client = ?config(client, Config),<br>
+                 1074     Headers = [<br>
+                 1075         {<<"content-type">>, <<"text/plain">>},<br>
+                 1076         {<<"accept">>, <<"text/plain">>}<br>
+                 1077     ],<br>
+                 1078     {ok, Client2} =<br></div></div>
+        cowboy_client:request(<<"POST"<u></u>____>>,<div class="im"><br>
+<br>
+                 1079         build_url("/postonly", Config), Headers,<br>
+        "12345",<br>
+                 Client),<br>
+                 1080     {ok, 204, _, _} =<br></div>
+        cowboy_client:response(____<u></u>Client2).<div class="im"><br>
+<br>
+<br>
+                 My solution to that was to add a content_types_provided<br>
+        function:<br>
+<br>
+<br>
+                 content_types_provided(Req, State) -><br>
+<br>
+<br>
+                 ContentTypes = [{{<<"application">>, <<"json">>, '*'},<br>
+        to_json}],<br>
+<br>
+<br>
+                 {ContentTypes, Req, State}.<br>
+<br>
+<br>
+<br>
+                 But it is useless as *to_json* callback registered is<br>
+        not called<br>
+                 anyhow.<br>
+<br>
+                 Adding *content_types_provided* function is a correct<br>
+        solution<br>
+                 in this case?<br>
+<br>
+                 Or I am missing something here?<br>
+                 “Accept” header is not relevant only in case of GET<br>
+        requests?<br>
+<br>
+                 Thank for help,<br>
+                 Łukasz Biedrycki<br>
+<br>
+<br></div>
+                 ______________________________<u></u>_____________________<div class="im"><br>
+                 Extend mailing list<br>
+        <a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a> <mailto:<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.<u></u>ninenines.eu</a>><br></div>
+        <mailto:<a href="mailto:Extend@lists." target="_blank">Extend@lists.</a>__<a href="http://ninenines.eu" target="_blank">ninenin<u></u>es.eu</a><br>
+        <mailto:<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.<u></u>ninenines.eu</a>>><br>
+        <a href="https://lists.ninenines.eu/____listinfo/extend" target="_blank">https://lists.ninenines.eu/___<u></u>_listinfo/extend</a><br>
+        <<a href="https://lists.ninenines.eu/__listinfo/extend" target="_blank">https://lists.ninenines.eu/__<u></u>listinfo/extend</a>><div class="im"><br>
+<br>
+                 <<a href="https://lists.ninenines.eu/__listinfo/extend" target="_blank">https://lists.ninenines.eu/__<u></u>listinfo/extend</a><br>
+        <<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a>>><br>
+<br>
+<br>
+             --<br>
+             Loïc Hoguin<br>
+        <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+<br>
+    --<br>
+    Loïc Hoguin<br>
+    <a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+<br>
+<br>
+</div></blockquote><div class="HOEnZb"><div class="h5">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140207/904cc7bf/attachment.html b/_build/static/archives/extend/attachments/20140207/904cc7bf/attachment.html new file mode 100644 index 00000000..8f835851 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140207/904cc7bf/attachment.html @@ -0,0 +1,8 @@ + +<div dir="ltr">Hi,<div>in my application I would like to add some metrics per handler and per response http status code.</div><div><br></div><div>One way is to add on response callback function, but there I do not have an information about handler and handler opts.</div>
+
+<div><br></div><div>Second way is to add a middleware, but then I do not have an information about response status code.</div><div><br></div><div>Frankly, I like second way more. </div><div>How do like an idea to add response status code to request record similar to: resp_headers or resp_body ?</div>
+
+<div><br></div><div>Cheers,</div><div>Łukasz Biedrycki</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140210/1781c9d2/attachment.html b/_build/static/archives/extend/attachments/20140210/1781c9d2/attachment.html new file mode 100644 index 00000000..571ccf79 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/1781c9d2/attachment.html @@ -0,0 +1,33 @@ + +<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>I promise you, improving the code now to get rid of the warnings is worth it.</div><div><br></div><div>Ivan<br><br>--<br>festina lente<div><br></div></div><div><br>On 10 Feb 2014, at 19:22, "Anton Koval'" <<a href="mailto:psihonavt@gmail.com">psihonavt@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Thanks for explanation. <br>My situation: I'm developing some stuff in module. That module in some kind of "draft' state (e.g. some functions are unused), but regardless that I want to compile project in order to test some specific parts of that module. <br>
+</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 8:48 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You can just define ERLC_OPTS before you include <a href="http://erlang.mk" target="_blank">erlang.mk</a> and it'll use that instead. I'm not sure why you want to disable that though, warnings usually alert you of bugs in your code.<div class="">
+<br>
+<br>
+On 02/10/2014 07:44 PM, Anton Koval' wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
+Hello,<br>
+<br>
+as I understand, by default `make all` performs compile with<br></div>
+option**warnings_as_errors.**<u></u>How can I disable this option?<div class=""><br>
+There are options described at<br>
+<a href="https://github.com/extend/erlang.mk#options" target="_blank">https://github.com/extend/<u></u>erlang.mk#options</a> and I believe that<br></div>
+|ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is<div class=""><br>
+unclear for me where have I to add(put) that option?<br>
+<br>
+Thanks.<br>
+<br>
+<br></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu">Extend@lists.ninenines.eu</a></span><br><span><a href="https://lists.ninenines.eu/listinfo/extend">https://lists.ninenines.eu/listinfo/extend</a></span><br></div></blockquote></body></html> + diff --git a/_build/static/archives/extend/attachments/20140210/2ae635a6/attachment.html b/_build/static/archives/extend/attachments/20140210/2ae635a6/attachment.html new file mode 100644 index 00000000..2d045585 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/2ae635a6/attachment.html @@ -0,0 +1,33 @@ + +<div dir="ltr">Thanks for explanation. <br>My situation: I'm developing some stuff in module. That module in some kind of "draft' state (e.g. some functions are unused), but regardless that I want to compile project in order to test some specific parts of that module. <br>
+</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 8:48 PM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You can just define ERLC_OPTS before you include <a href="http://erlang.mk" target="_blank">erlang.mk</a> and it'll use that instead. I'm not sure why you want to disable that though, warnings usually alert you of bugs in your code.<div class="">
+<br>
+<br>
+On 02/10/2014 07:44 PM, Anton Koval' wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
+Hello,<br>
+<br>
+as I understand, by default `make all` performs compile with<br></div>
+option**warnings_as_errors.**<u></u>How can I disable this option?<div class=""><br>
+There are options described at<br>
+<a href="https://github.com/extend/erlang.mk#options" target="_blank">https://github.com/extend/<u></u>erlang.mk#options</a> and I believe that<br></div>
+|ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is<div class=""><br>
+unclear for me where have I to add(put) that option?<br>
+<br>
+Thanks.<br>
+<br>
+<br></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+-- <br>
+Loc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140210/a2b35e2f/attachment.html b/_build/static/archives/extend/attachments/20140210/a2b35e2f/attachment.html new file mode 100644 index 00000000..363ec211 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/a2b35e2f/attachment.html @@ -0,0 +1,6 @@ + +<div dir="ltr">Hello,<br><br>as I understand, by default `make all` performs compile with option<strong><span class=""> </span></strong>warnings_as_errors.<strong><span class=""> </span></strong><span class="">How can I disable this option?<br>
+There are options described at <a href="https://github.com/extend/erlang.mk#options">https://github.com/extend/erlang.mk#options</a> and I believe that </span><code>ERLC_OPTS should be filled with `-</code>warnings_as_errors`<strong><span class=""></span></strong>. But it is unclear for me where have I to add(put) that option?<br>
+<br>Thanks.<br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140210/b46e2bab/attachment.html b/_build/static/archives/extend/attachments/20140210/b46e2bab/attachment.html new file mode 100644 index 00000000..edc309fa --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/b46e2bab/attachment.html @@ -0,0 +1,15 @@ + +<div dir="ltr">Hi again,<div>another idea is to make environment (Env), which is passed between middlewares, a part of Request record, so I could have an access to it in onresponse callback.</div><div><br></div><div>Any of that makes sense?</div>
+
+<div><br></div><div>Cheers,</div><div>Łukasz Biedrycki</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 7, 2014 at 5:56 PM, Łukasz Biedrycki <span dir="ltr"><<a href="mailto:lukasz.biedrycki@gmail.com" target="_blank">lukasz.biedrycki@gmail.com</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div>in my application I would like to add some metrics per handler and per response http status code.</div>
+
+<div><br></div><div>One way is to add on response callback function, but there I do not have an information about handler and handler opts.</div>
+<div><br></div><div>Second way is to add a middleware, but then I do not have an information about response status code.</div><div><br></div><div>Frankly, I like second way more. </div><div>How do like an idea to add response status code to request record similar to: resp_headers or resp_body ?</div>
+
+
+<div><br></div><div>Cheers,</div><div>Łukasz Biedrycki</div></div>
+</blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140210/bf26d573/attachment.html b/_build/static/archives/extend/attachments/20140210/bf26d573/attachment.html new file mode 100644 index 00000000..31d5ead2 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/bf26d573/attachment.html @@ -0,0 +1,60 @@ + +<div dir="ltr">Hey,<div>I didn’t know about that. </div><div>That is exactly what I need!</div><div>Thank you!</div><div><br></div><div>Cheers,</div><div>Łukasz Biedrycki</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
+
+On Mon, Feb 10, 2014 at 10:49 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+
+You have the meta values in Req which are passed everywhere. You can easily set and retrieve them.<div><div class="h5"><br>
+<br>
+On 02/10/2014 10:41 AM, Łukasz Biedrycki wrote:<br>
+</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
+Hi again,<br>
+another idea is to make environment (Env), which is passed between<br>
+middlewares, a part of Request record, so I could have an access to it in<br>
+onresponse callback.<br>
+<br>
+Any of that makes sense?<br>
+<br>
+Cheers,<br>
+Łukasz Biedrycki<br>
+<br>
+<br>
+On Fri, Feb 7, 2014 at 5:56 PM, Łukasz Biedrycki <<a href="mailto:lukasz.biedrycki@gmail.com" target="_blank">lukasz.biedrycki@gmail.com</a><br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+wrote:<br>
+</blockquote>
+<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+Hi,<br>
+in my application I would like to add some metrics per handler and per<br>
+response http status code.<br>
+<br>
+One way is to add on response callback function, but there I do not have<br>
+an information about handler and handler opts.<br>
+<br>
+Second way is to add a middleware, but then I do not have an information<br>
+about response status code.<br>
+<br>
+Frankly, I like second way more.<br>
+How do like an idea to add response status code to request record similar<br>
+to: resp_headers or resp_body ?<br>
+<br>
+Cheers,<br>
+Łukasz Biedrycki<br>
+<br>
+</blockquote>
+<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140210/fa72e2ba/attachment.html b/_build/static/archives/extend/attachments/20140210/fa72e2ba/attachment.html new file mode 100644 index 00000000..00f1bf63 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140210/fa72e2ba/attachment.html @@ -0,0 +1,41 @@ + +<div dir="ltr">Got it! :) <br>fixed all warnings and removed ERLC_OPTS from Makefile.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 9:46 PM, Ivan Uemlianin <span dir="ltr"><<a href="mailto:ivan@llaisdy.com" target="_blank">ivan@llaisdy.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I promise you, improving the code now to get rid of the warnings is worth it.</div><div><br></div>
+<div>Ivan<br><br>--<br>festina lente<div><br></div></div><div><div class="h5"><div><br>On 10 Feb 2014, at 19:22, "Anton Koval'" <<a href="mailto:psihonavt@gmail.com" target="_blank">psihonavt@gmail.com</a>> wrote:<br>
+<br></div><blockquote type="cite"><div><div dir="ltr">Thanks for explanation. <br>My situation: I'm developing some stuff in module. That module in some kind of "draft' state (e.g. some functions are unused), but regardless that I want to compile project in order to test some specific parts of that module. <br>
+
+</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 8:48 PM, Loc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You can just define ERLC_OPTS before you include <a href="http://erlang.mk" target="_blank">erlang.mk</a> and it'll use that instead. I'm not sure why you want to disable that though, warnings usually alert you of bugs in your code.<div>
+
+<br>
+<br>
+On 02/10/2014 07:44 PM, Anton Koval' wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
+Hello,<br>
+<br>
+as I understand, by default `make all` performs compile with<br></div>
+option**warnings_as_errors.**<u></u>How can I disable this option?<div><br>
+There are options described at<br>
+<a href="https://github.com/extend/erlang.mk#options" target="_blank">https://github.com/extend/<u></u>erlang.mk#options</a> and I believe that<br></div>
+|ERLC_OPTS should be filled with `-|warnings_as_errors`**. But it is<div><br>
+unclear for me where have I to add(put) that option?<br>
+<br>
+Thanks.<br>
+<br>
+<br></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span><font color="#888888">
+</font></span></blockquote><span><font color="#888888">
+<br>
+-- <br>
+Loc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Extend mailing list</span><br><span><a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a></span><br>
+<span><a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/listinfo/extend</a></span><br></div></blockquote></div></div></div></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140303/52007acc/attachment.html b/_build/static/archives/extend/attachments/20140303/52007acc/attachment.html new file mode 100644 index 00000000..de4f2988 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140303/52007acc/attachment.html @@ -0,0 +1,11 @@ + +<div dir="ltr">Hello,<br><br>I have next structure of my project:<br>.<br>├── deps<br>│   ├── cowboy<br>│   ├── cowlib<br>│   ├── erlang_iconv<br>│   ├── erlydtl<br>│   ├── mochiweb_xpath<br>│   └── ranch<br>├── ebin<br>│   ├── fetchers.beam<br>
+│   ├── parsers.beam<br>│   └── wasearch_sup.beam<br>├── <a href="http://erlang.mk">erlang.mk</a><br>├── Makefile<br>├── _rel<br>│   └── ....<br>├── relx<br>├── relx.config<br>├── src<br>│   ├── fetchers.erl<br>│   ├── main_handler.erl<br>
+│   ├── parsers.erl<br>│   ├── tests<br>│   │   ├── parsers_SUITE_data<br>│   │   ├── parsers_SUITE.erl<br>│   │   ├── ....<br>│   ├── wasearch_app.erl<br>│   ├── wasearch.app.src<br>│   └── wasearch_sup.erl<br>└── templates<br>
+    └── index.dtl<br><br>I would prefer to store tests not in `src` directory but rather in `tests` subdirectory. <br>Erlang.mk README says: You can run an individual test suite by using the special <code>test_*</code>
+targets. For example if you have a common_test suite named <code>spdy</code>
+and you want to run only this suite and not the others, you can
+use the <code>make test_spdy</code> command.<br>And of course `make test_parsers`  returns `no rule to make target` error. <br>Is there a way to run suites from custom directory with `make_<mod_name_with_suite>` command? <br>
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20140306/24422ef2/attachment.html b/_build/static/archives/extend/attachments/20140306/24422ef2/attachment.html new file mode 100644 index 00000000..62741bf1 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140306/24422ef2/attachment.html @@ -0,0 +1,19 @@ + +<div dir="ltr">I also found the answer to my own question: custom middleware<div><br></div><div>I just created:</div><div><br></div><div><div> 1 -module(authentication_middleware).</div><div> 2</div><div> 3 -behaviour(cowboy_middleware).</div>
+<div> 4</div><div> 5 -export([execute/2]).</div><div> 6</div><div> 7 execute(Req, Env) -></div><div> 8</div><div> 9   {Path, Req1} = cowboy_req:path(Req),</div><div> 10</div><div> 11   case Path of</div>
+<div> 12     <<"/login.html">> -></div><div> 13       {ok, Req1, Env};</div><div> 14     <<"/do_login">> -></div><div> 15       {ok, Req1, Env};</div>
+<div> 16     _ -></div><div> 17       case id3as_security:is_request_authenticated(Req1) of</div><div> 18         {error, eauth, Req2} -></div><div> 19           {ok, Req4} = cowboy_req:reply(303, [{<<"Location">>, <<"/login.html">>}], "", Req2),</div>
+<div> 20           {halt, Req4};</div><div> 21         {authenticated, _Id, Req2} -></div><div> 22          {ok, Req2, Env}</div><div> 23       end</div><div> 24   end.</div></div>
+<div><br></div><div>And put this between the cowboy_router and cowboy_handler and life is all good.</div><div><br></div><div>-Mark</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 12:47 AM, Mark Nijhof <span dir="ltr"><<a href="mailto:mark.nijhof@cre8ivethought.com" target="_blank">mark.nijhof@cre8ivethought.com</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I want to create a module that basically sits between the incoming request and the http handler for that request to ensure a request is authenticated (using a cookie), if the request is not authenticated then I like to redirect to a specific login page (which should not be filtered).</div>
+
+<div><br></div><div>Is this possible with Cowboy? Should I use the onrequest hook (not sure if I can force redirects from there) for that or is there a better way?</div><div><br></div><div>Cheers,</div><div><br></div><div>
+
+-Mark<span class="HOEnZb"><font color="#888888"><br clear="all"><div><br></div>-- <br><div dir="ltr">Mark Nijhof<br><div><div>t:  <a href="https://twitter.com/MarkNijhof" target="_blank">@MarkNijhof</a><br>s: marknijhof</div>
+</div><div><br></div></div>
+</font></span></div></div>
+</blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">Mark Nijhof<br><div><div>t:  <a href="https://twitter.com/MarkNijhof" target="_blank">@MarkNijhof</a><br>s: marknijhof</div></div><div><br></div>
+</div>
+</div>
+ + diff --git a/_build/static/archives/extend/attachments/20140306/6fa8fe3b/attachment.html b/_build/static/archives/extend/attachments/20140306/6fa8fe3b/attachment.html new file mode 100644 index 00000000..2754a31d --- /dev/null +++ b/_build/static/archives/extend/attachments/20140306/6fa8fe3b/attachment.html @@ -0,0 +1,67 @@ + +<div dir="ltr">Thank you for answer. <br>Is it common way (for OTP-based application) to store tests in `tests` subdirectory rather then in `src/tests/`?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 4:40 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br>
+<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tests should be in ./tests, not ./src/tests.<br>
+<br>
+If you put them in ./tests everything you mentioned will work.<div class=""><br>
+<br>
+On 03/03/2014 09:49 PM, Anton Koval' wrote:<br>
+</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
+Hello,<br>
+<br>
+I have next structure of my project:<br>
+.<br>
+├── deps<br>
+│   ├── cowboy<br>
+│   ├── cowlib<br>
+│   ├── erlang_iconv<br>
+│   ├── erlydtl<br>
+│   ├── mochiweb_xpath<br>
+│   └── ranch<br>
+├── ebin<br>
+│   ├── fetchers.beam<br>
+│   ├── parsers.beam<br>
+│   └── wasearch_sup.beam<br></div>
+├── <a href="http://erlang.mk" target="_blank">erlang.mk</a> <<a href="http://erlang.mk" target="_blank">http://erlang.mk</a>><div><div class="h5"><br>
+├── Makefile<br>
+├── _rel<br>
+│   └── ....<br>
+├── relx<br>
+├── relx.config<br>
+├── src<br>
+│   ├── fetchers.erl<br>
+│   ├── main_handler.erl<br>
+│   ├── parsers.erl<br>
+│   ├── tests<br>
+│   │   ├── parsers_SUITE_data<br>
+│   │   ├── parsers_SUITE.erl<br>
+│   │   ├── ....<br>
+│   ├── wasearch_app.erl<br>
+│   ├── wasearch.app.src<br>
+│   └── wasearch_sup.erl<br>
+└── templates<br>
+     └── index.dtl<br>
+<br>
+I would prefer to store tests not in `src` directory but rather in<br>
+`tests` subdirectory.<br>
+Erlang.mk README says: You can run an individual test suite by using the<br>
+special |test_*| targets. For example if you have a common_test suite<br>
+named |spdy| and you want to run only this suite and not the others, you<br>
+can use the |make test_spdy| command.<br>
+And of course `make test_parsers`  returns `no rule to make target` error.<br>
+Is there a way to run suites from custom directory with<br>
+`make_<mod_name_with_suite>` command?<br>
+<br>
+<br></div></div>
+______________________________<u></u>_________________<br>
+Extend mailing list<br>
+<a href="mailto:Extend@lists.ninenines.eu" target="_blank">Extend@lists.ninenines.eu</a><br>
+<a href="https://lists.ninenines.eu/listinfo/extend" target="_blank">https://lists.ninenines.eu/<u></u>listinfo/extend</a><br>
+<br><span class="HOEnZb"><font color="#888888">
+</font></span></blockquote><span class="HOEnZb"><font color="#888888">
+<br>
+-- <br>
+Loïc Hoguin<br>
+<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><br>
+</font></span></blockquote></div><br></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140306/a517215b/attachment.html b/_build/static/archives/extend/attachments/20140306/a517215b/attachment.html new file mode 100644 index 00000000..9f53e9df --- /dev/null +++ b/_build/static/archives/extend/attachments/20140306/a517215b/attachment.html @@ -0,0 +1,7 @@ + +<div dir="ltr">Hi,<div><br></div><div>I want to create a module that basically sits between the incoming request and the http handler for that request to ensure a request is authenticated (using a cookie), if the request is not authenticated then I like to redirect to a specific login page (which should not be filtered).</div>
+<div><br></div><div>Is this possible with Cowboy? Should I use the onrequest hook (not sure if I can force redirects from there) for that or is there a better way?</div><div><br></div><div>Cheers,</div><div><br></div><div>
+-Mark<br clear="all"><div><br></div>-- <br><div dir="ltr">Mark Nijhof<br><div><div>t:  <a href="https://twitter.com/MarkNijhof" target="_blank">@MarkNijhof</a><br>s: marknijhof</div></div><div><br></div></div>
+</div></div>
+ + diff --git a/_build/static/archives/extend/attachments/20140314/b2f802d3/attachment.html b/_build/static/archives/extend/attachments/20140314/b2f802d3/attachment.html new file mode 100644 index 00000000..a95a7cc4 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140314/b2f802d3/attachment.html @@ -0,0 +1,31 @@ + +<html>
+<head>
+<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">On a dev server I had a Cowboy app suddenly start returning timeouts when calling cowboy_req:body_qs(Request), with surprising frequency, which in turn led to 500s back to the calling client. It only
+ appeared to happen when hitting one particular resource, and was sporadic, and I was wondering if there might be some explanation related to Cowboy (as opposed to maybe really weird VM issues). For full disclosure, we would first check the body with cowboy_req:body(Request)
+ as part of an access log, then ignore the returned cowboy_req:req() that call passed back, since we could not then stream the body off of it again. It was working fine, so I don't think it was related, but it seems more solid now after I removed it and I don't
+ know if that's related or not.</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">Here is an example request that dumped when the process died - </p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">{req,[{socket,#Port<0.7113>},{transport,ranch_tcp},{connection,keepalive},{pid,<0.1805.0>},{method,<<"POST">>},{version,'HTTP/1.1'},{peer,{{10,188,32,225},53188}},{host,<<"bps-feedschedulervip1.turner.com">>},{host_info,undefined},{port,8091},{path,<<"/encoders/Player1/record">>},{path_info,[<<"record">>]},{qs,<<"authToken=…">>},{qs_vals,[{<<"authToken">>,<<"…">>}]},{bindings,[{id,<<"Player1">>}]},{headers,[{<<"host">>,<<"bps-feedschedulervip1.turner.com:8091">>},{<<"content-type">>,<<"application/x-www-form-urlencoded;
+ charset=UTF-8">>},{<<"origin">>,<<"http://bps-newstrondev1.turner.com">>},{<<"content-length">>,<<"48">>},{<<"connection">>,<<"keep-alive">>},{<<"accept">>,<<"application/json, text/javascript, */*; q=0.01">>},{<<"user-agent">>,<<"Mozilla/5.0 (Macintosh; Intel
+ Mac OS X 10_9_2) AppleWebKit/537.74.9 (KHTML, like Gecko) Version/7.0.2 Safari/537.74.9">>},{<<"referer">>,<<"http://bps-newstrondev1.turner.com/newstron/record/record.html">>},{<<"accept-language">>,<<"en-us">>},{<<"accept-encoding">>,<<"gzip, deflate">>}]},{p_headers,[{<<"content-type">>,{<<"application">>,<<"x-www-form-urlencoded">>,[{<<"charset">>,<<"utf-8">>}]}},{<<"if-modified-since">>,undefined},{<<"if-none-match">>,undefined},{<<"if-unmodified-since">>,undefined},{<<"if-match">>,undefined},{<<"accept">>,[{{<<"application">>,<<"json">>,[]},1000,[]},{{<<"text">>,<<"javascript">>,[]},1000,[]},{{<<"*">>,<<"*">>,[]},10,[]}]},{<<"connection">>,[<<"keep-alive">>]}]},{cookies,undefined},{meta,[{charset,undefined},{media_type,{<<"application">>,<<"json">>,[]}}]},{body_state,waiting},{multipart,undefined},{buffer,<<>>},{resp_compress,false},{resp_state,waiting},{resp_headers,[{<<"content-type">>,[<<"application">>,<<"/">>,<<"json">>,<<>>]},{<<"Access-Control-Allow-Origin">>,<<"*">>}]},{resp_body,<<>>},{onresponse,#Fun<access_log_responder.onresponse.4>}]}</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;"><br>
+</p>
+<p style="margin: 0px; font-size: 11px; font-family: Menlo;">As I said, it may be just due to VM issues or something, but I figured I'd ask in case there was any obvious issue.</p>
+</body>
+</html>
+ + diff --git a/_build/static/archives/extend/attachments/20140411/9e3c6c32/attachment.html b/_build/static/archives/extend/attachments/20140411/9e3c6c32/attachment.html new file mode 100644 index 00000000..00111e16 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140411/9e3c6c32/attachment.html @@ -0,0 +1,3 @@ + +<span style="font-family: Arial;">Please report it to erlang-bugs, you'll get better help with ssl bugs there.<br><br>-- <br>Loïc Hoguin<br>http://ninenines.eu</span><span style="font-family: Arial;"><br><br>-------- Original Message --------<br>From:Samir Sow <samset@wanadoo.fr><br>Sent:Fri, 11 Apr 2014 23:23:10 +0200<br>To:extend@lists.ninenines.eu<br>Subject:[99s-extend] ssl<br><br></span>Hi,<br><br>Still struggling with ssl.<br>I decided to check what’s going on at the ssl module level. Did a step by step ssl connection using the erlang ssl doc.<br>Found an error erlang:size badarg, but could not understand if it’s a problem with the key/cert files or with the data sent by the client.<br><br>Any help welcomed. Thx<br><br>Samir<br><br>{ok, SSLSocket} = ssl:ssl_accept(Socket, [{cacertfile, "priv/cert/cacert.crt"}, {certfile, "priv/cert/server.crt"}, {keyfile, "priv/cert/server.key"}]).<br>** exception exit: {{badarg,<br>                        [{erlang,size,<br>                             [[22,3,1,0,176,1,0,0,172,3,3,83,72,89,48,183,175,<br>                               58,145,197,219|...]],<br>                             []},<br>                         {tls_record,get_tls_records_aux,2,<br>                             [{file,"tls_record.erl"},{line,122}]},<br>                         {tls_connection,next_tls_record,2,<br>                             [{file,"tls_connection.erl"},{line,484}]},<br>                         {tls_connection,handle_info,3,<br>                             [{file,"tls_connection.erl"},{line,307}]},<br>                         {gen_fsm,handle_msg,7,<br>                             [{file,"gen_fsm.erl"},{line,503}]},<br>                         {proc_lib,init_p_do_apply,3,<br>                             [{file,"proc_lib.erl"},{line,239}]}]},<br>                    {gen_fsm,sync_send_all_state_event,<br>                        [<0.105.0>,{start,infinity},infinity]}}<br>     in function  gen_fsm:sync_send_all_state_event/3 (gen_fsm.erl, line 242)<br>     in call from ssl_connection:sync_send_all_state_event/2 (ssl_connection.erl, line 1649)<br>     in call from ssl_connection:handshake/2 (ssl_connection.erl, line 97)<br>     in call from tls_connection:start_fsm/8 (tls_connection.erl, line 81)<br>     in call from ssl_connection:ssl_accept/7 (ssl_connection.erl, line 84)<br>_______________________________________________<br>Extend mailing list<br>Extend@lists.ninenines.eu<br>https://lists.ninenines.eu/listinfo/extend<br> + diff --git a/_build/static/archives/extend/attachments/20140420/bf45e4d0/attachment-0001.bin b/_build/static/archives/extend/attachments/20140420/bf45e4d0/attachment-0001.bin new file mode 100644 index 00000000..67d03d72 --- /dev/null +++ b/_build/static/archives/extend/attachments/20140420/bf45e4d0/attachment-0001.bin @@ -0,0 +1,59 @@ +diff --git a/examples/websocket/priv/index.html b/examples/websocket/priv/index.html +index 5bc7f15..3e233fa 100644 +--- a/examples/websocket/priv/index.html ++++ b/examples/websocket/priv/index.html +@@ -1,7 +1,7 @@ + + + +- Websocket client ++ Websocket client foo + +