Last 30 days

• Dec 02, 2009

  issue 19 (The patch which allow Mochiweb to work through HTTPS) commented on by nesrait   -   Attaching an updated version of the foo.diff patch (based on r113). Some changes were required to get http://code.google.com/p/mochiweb/issues/detail?id=44 working. Tested with the example.erl provided above and the keepalive-example attached with Issue 44 . Cheers, Davide

  Attaching an updated version of the foo.diff patch (based on r113). Some changes were required to get http://code.google.com/p/mochiweb/issues/detail?id=44 working. Tested with the example.erl provided above and the keepalive-example attached with Issue 44 . Cheers, Davide
• Dec 01, 2009

  issue 51 (mochiweb only listens on ipv4 even when ipv6 is available an...) reported by linzberger   -   What steps will reproduce the problem? 1. start a mochiweb server on a host configured with both ipv4 and ipv6 2. check address bindings with "netstat -tln" What is the expected output? What do you see instead? tcp6 0 0 :::8000 :::* LISTEN would indicate listening on *both* v4 and v6, but instead tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN indicating v4 only bind is shown. What version of the product are you using? On what operating system? svn checkout done on 1st december 2009, running on erlang/otp 13.b.2 running on debian linux. I believe the attached patch fixes this issue. It seems gen_tcp_listen expects only the inet6 option for binding both v4 and v6.

  What steps will reproduce the problem? 1. start a mochiweb server on a host configured with both ipv4 and ipv6 2. check address bindings with "netstat -tln" What is the expected output? What do you see instead? tcp6 0 0 :::8000 :::* LISTEN would indicate listening on *both* v4 and v6, but instead tcp 0 0 0.0.0.0:8000 0.0.0.0:* LISTEN indicating v4 only bind is shown. What version of the product are you using? On what operating system? svn checkout done on 1st december 2009, running on erlang/otp 13.b.2 running on debian linux. I believe the attached patch fixes this issue. It seems gen_tcp_listen expects only the inet6 option for binding both v4 and v6.
• Nov 28, 2009

  issue 50 (escript: exception error: undefined function mochiweb_skel:s...) commented on by coolchevy   -   Thanks, I have forgotten.

  Thanks, I have forgotten.
• Nov 28, 2009

  issue 50 (escript: exception error: undefined function mochiweb_skel:s...) Status changed by bob.ippolito   -   Build the project first with make.

  Status: Invalid

  Build the project first with make.

  Status: Invalid
• Nov 28, 2009

  issue 50 (escript: exception error: undefined function mochiweb_skel:s...) reported by coolchevy   -   What steps will reproduce the problem? 1. coolchevy@conote:~/www/erlang/mochiweb$ ./scripts/new_mochiweb.erl test_app ../ What is the expected output? What do you see instead? escript: exception error: undefined function mochiweb_skel:skelcopy/2 in function erl_eval:do_apply/5 in call from erl_eval:expr/5 in call from erl_eval:local_func/5 in call from escript:interpret/3 in call from escript:start/1 in call from init:start_it/1 in call from init:start_em/1 What version of the product are you using? On what operating system? coolchevy@conote:~/www/erlang/mochiweb$ svn up At revision 113. coolchevy@conote:~/www/erlang/mochiweb$ erl -version Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.7.3

  What steps will reproduce the problem? 1. coolchevy@conote:~/www/erlang/mochiweb$ ./scripts/new_mochiweb.erl test_app ../ What is the expected output? What do you see instead? escript: exception error: undefined function mochiweb_skel:skelcopy/2 in function erl_eval:do_apply/5 in call from erl_eval:expr/5 in call from erl_eval:local_func/5 in call from escript:interpret/3 in call from escript:start/1 in call from init:start_it/1 in call from init:start_em/1 What version of the product are you using? On what operating system? coolchevy@conote:~/www/erlang/mochiweb$ svn up At revision 113. coolchevy@conote:~/www/erlang/mochiweb$ erl -version Erlang (SMP,ASYNC_THREADS) (BEAM) emulator version 5.7.3
• Nov 22, 2009

  issue 48 (Patch adding 2 useful methods to mochiweb_headers.erl) commented on by fdmanana   -   This third patch adds: + from_binary_list/1 is now a special case of from_binary/1. to_mochiweb_headers/2 was renamed to from_binary/2. + updated the doc comment for from_binary + more tests (for empty lists/strings and binaries and lists containing mixes of strings/binaries)

  This third patch adds: + from_binary_list/1 is now a special case of from_binary/1. to_mochiweb_headers/2 was renamed to from_binary/2. + updated the doc comment for from_binary + more tests (for empty lists/strings and binaries and lists containing mixes of strings/binaries)
• Nov 20, 2009

  issue 48 (Patch adding 2 useful methods to mochiweb_headers.erl) commented on by fdmanana   -   Hello, this second version of the patch fixes a bug that arises when an empty binary (<<>>, <<"">>, <<"\r\n">>) or empty list is passed to one of those 2 new functions. Btw, can I have some feedback about the patch? best regards, Filipe Manana

  Hello, this second version of the patch fixes a bug that arises when an empty binary (<<>>, <<"">>, <<"\r\n">>) or empty list is passed to one of those 2 new functions. Btw, can I have some feedback about the patch? best regards, Filipe Manana
• Nov 18, 2009

  issue 49 (Mochiweb server doesn't handle bad URL in request) reported by glorybox.away   -   What steps will reproduce the problem? 1. start mochiweb 2. curl "http://127.0.0.1:8000/foo bar" 3. Empty response from server What is the expected output? What do you see instead? Excepted output is something like bad request code and maybe some text message. I see empty response without any message even in mochiweb console without any possibility to handle that in mochiweb application. What version of the product are you using? On what operating system? Latest svn version on Ubuntu 9.10 Please provide any additional information below. I think mochiweb as a HTTP web server should handle invalid requests such as describe by itself, but it would be great if it provided some way to programmer to write handler for this situation.

  What steps will reproduce the problem? 1. start mochiweb 2. curl "http://127.0.0.1:8000/foo bar" 3. Empty response from server What is the expected output? What do you see instead? Excepted output is something like bad request code and maybe some text message. I see empty response without any message even in mochiweb console without any possibility to handle that in mochiweb application. What version of the product are you using? On what operating system? Latest svn version on Ubuntu 9.10 Please provide any additional information below. I think mochiweb as a HTTP web server should handle invalid requests such as describe by itself, but it would be great if it provided some way to programmer to write handler for this situation.
• Nov 17, 2009

  issue 48 (Patch adding 2 useful methods to mochiweb_headers.erl) reported by fdmanana   -   Hello, It's a bit awkward the fact that the trailer/footer of a chunked http message is supplied as a list of binaries and we have no function to convert such list into a mochiweb headers structure. Hereby I send you a patch with 2 useful functions: %% @spec from_binary(RawHttpHeader()) -> headers() %% @type RawHttpHeader() -> binary() %% %% @doc Transforms a raw HTTP header into a mochiweb headers structure. %% %% The given raw HTTP header is a binary representing a full HTTP %% header ending with double CRLF. %% Example: %% <<"Content-Length: 47\r\nContent-Type: text/plain\r\n\r\n">> %% from_binary(RawHttpHeader) -> to_mochiweb_headers(RawHttpHeader, []). %% @spec from_binary_list(RawHttpHeaderList()) -> headers() %% @type RawHttpHeaderList() -> [ binary() ] %% %% @doc Transforms a raw HTTP header into a mochiweb headers structure. %% %% The given raw HTTP header is a list of binaries where each binary %% represents a raw HTTP header line ending with a single CRLF. %% Example: %% [ <<"Content-Length: 47\r\n">>, <<"Content-Type: text/plain\r \n">> ] %% from_binary_list(RawHttpHeaderList) -> from_binary(list_to_binary([RawHttpHeaderList, "\r\n"])). to_mochiweb_headers(RawHttpHeader, Acc) -> { ok, {http_header, _, H, _, V}, Rest } = erlang:decode_packet(httph, RawHttpHeader, []), case Rest of <<"\r\n">> -> make([{H, V} | Acc]); R -> to_mochiweb_headers(R, [{H, V} | Acc]) end. I also added test statements to the test/0 function. best regards, Filipe Manana

  Hello, It's a bit awkward the fact that the trailer/footer of a chunked http message is supplied as a list of binaries and we have no function to convert such list into a mochiweb headers structure. Hereby I send you a patch with 2 useful functions: %% @spec from_binary(RawHttpHeader()) -> headers() %% @type RawHttpHeader() -> binary() %% %% @doc Transforms a raw HTTP header into a mochiweb headers structure. %% %% The given raw HTTP header is a binary representing a full HTTP %% header ending with double CRLF. %% Example: %% <<"Content-Length: 47\r\nContent-Type: text/plain\r\n\r\n">> %% from_binary(RawHttpHeader) -> to_mochiweb_headers(RawHttpHeader, []). %% @spec from_binary_list(RawHttpHeaderList()) -> headers() %% @type RawHttpHeaderList() -> [ binary() ] %% %% @doc Transforms a raw HTTP header into a mochiweb headers structure. %% %% The given raw HTTP header is a list of binaries where each binary %% represents a raw HTTP header line ending with a single CRLF. %% Example: %% [ <<"Content-Length: 47\r\n">>, <<"Content-Type: text/plain\r \n">> ] %% from_binary_list(RawHttpHeaderList) -> from_binary(list_to_binary([RawHttpHeaderList, "\r\n"])). to_mochiweb_headers(RawHttpHeader, Acc) -> { ok, {http_header, _, H, _, V}, Rest } = erlang:decode_packet(httph, RawHttpHeader, []), case Rest of <<"\r\n">> -> make([{H, V} | Acc]); R -> to_mochiweb_headers(R, [{H, V} | Acc]) end. I also added test statements to the test/0 function. best regards, Filipe Manana
• Nov 15, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) Status changed by bob.ippolito   -   applied in r113

  Status: Fixed

  applied in r113

  Status: Fixed
• Nov 15, 2009

  r113 (http://code.google.com/p/mochiweb/issues/detail?id=46) committed by bob.ippolito   -   http://code.google.com/p/mochiweb/issues/detail?id=46

  http://code.google.com/p/mochiweb/issues/detail?id=46
• Nov 15, 2009

  issue 47 (request for mochijson2 to reject string input that is not a ...) Status changed by bob.ippolito   -   Applied in r112

  Status: Fixed

  Applied in r112

  Status: Fixed
• Nov 15, 2009

  r112 (http://code.google.com/p/mochiweb/issues/detail?id=47) committed by bob.ippolito   -   http://code.google.com/p/mochiweb/issues/detail?id=47

  http://code.google.com/p/mochiweb/issues/detail?id=47

Earlier this year

• Nov 11, 2009

  issue 47 (request for mochijson2 to reject string input that is not a ...) commented on by adam.kocoloski   -   Here's an updated patch with some simple tests for invalid 2/3/4-byte sequences

  Here's an updated patch with some simple tests for invalid 2/3/4-byte sequences
• Nov 10, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   Don't know how you feel about undocumented OTP features, but gen_tcp exports an unrecv/2 that seems to be exactly what is needed here. This patch puts the extra data back on the socket if it ends up reading too much. Still need to come up with a test that actually hits this code path.

  Don't know how you feel about undocumented OTP features, but gen_tcp exports an unrecv/2 that seems to be exactly what is needed here. This patch puts the extra data back on the socket if it ends up reading too much. Still need to come up with a test that actually hits this code path.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   You're quite right, idempotence is what matters, and taking care to handle that use case will complicate things.

  You're quite right, idempotence is what matters, and taking care to handle that use case will complicate things.
• Nov 09, 2009

  issue 47 (request for mochijson2 to reject string input that is not a ...) commented on by adam.kocoloski   -   Thanks for the nudge, I'll see if we can get some tests attached to that patch.

  Thanks for the nudge, I'll see if we can get some tests attached to that patch.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by bob.ippolito   -   I think that it's possible to have an idempotent PUT request with a body that is pipelined, however rare it may be.

  I think that it's possible to have an idempotent PUT request with a body that is pipelined, however rare it may be.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   Sorry, not sure I follow ... are you thinking of GET requests with bodies, or PUT/POST requests that are pipelined? Both are unusual and I think the latter is a SHOULD NOT in the RFC. I do see how pipelined requests with bodies would be troublesome with this patch.

  Sorry, not sure I follow ... are you thinking of GET requests with bodies, or PUT/POST requests that are pipelined? Both are unusual and I think the latter is a SHOULD NOT in the RFC. I do see how pipelined requests with bodies would be troublesome with this patch.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by bob.ippolito   -   But is it an error if the client pipelines two HTTP requests back to back? Most HTTP servers would handle this gracefully wouldn't they? mochiweb currently should (other than the potential timeout issue).

  But is it an error if the client pipelines two HTTP requests back to back? Most HTTP servers would handle this gracefully wouldn't they? mochiweb currently should (other than the potential timeout issue).
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   bah, bad patch ... here's the right one

  bah, bad patch ... here's the right one
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   bah, bad patch ... here's the right one

  bah, bad patch ... here's the right one
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by adam.kocoloski   -   Hi Bob, good point. Here's an updated patch that checks the size of the received data before applying the Fun

  Hi Bob, good point. Here's an updated patch that checks the size of the received data before applying the Fun
• Nov 09, 2009

  issue 47 (request for mochijson2 to reject string input that is not a ...) commented on by bob.ippolito   -   mochijson2 is intended to work ONLY with UTF-8 input and output, so this isn't a problem. I'll try and take a closer look at the patch later this week, it would be better if there were tests! :)

  mochijson2 is intended to work ONLY with UTF-8 input and output, so this isn't a problem. I'll try and take a closer look at the patch later this week, it would be better if there were tests! :)
• Nov 09, 2009

  issue 47 (request for mochijson2 to reject string input that is not a ...) reported by adam.kocoloski   -   What steps will reproduce the problem? 1. mochijson2:decode(<<34, 128, 34>>). % this succeeds 2. mochijson2:encode(mochijson2:decode(<<34, 128, 34>>)). % this roundtrip fails What is the expected output? What do you see instead? I'd like to see mochijson2 reject this input as invalid. Instead it decodes this as <<128>>, which fails the roundtrip: mochijson2:encode(mochijson2:decode(<<34, 128, 34>>)). ** exception exit: {ucs,{bad_utf8_character_code}} in function xmerl_ucs:from_utf8/1 in call from mochijson2:json_encode_string/2 What version of the product are you using? On what operating system? r97, any OS. Discussed in detail in https://issues.apache.org/jira/browse/COUCHDB-345. I think the ideal solution from CouchDB's perspective would be for mochijson2 to accept input in any Unicode encoding. An interim solution that we've adopted is to reject anything other than UTF-8. I'm not sure if that's an appropriate solution for the broader Mochiweb community, but nevertheless I'm attaching the patch.

  What steps will reproduce the problem? 1. mochijson2:decode(<<34, 128, 34>>). % this succeeds 2. mochijson2:encode(mochijson2:decode(<<34, 128, 34>>)). % this roundtrip fails What is the expected output? What do you see instead? I'd like to see mochijson2 reject this input as invalid. Instead it decodes this as <<128>>, which fails the roundtrip: mochijson2:encode(mochijson2:decode(<<34, 128, 34>>)). ** exception exit: {ucs,{bad_utf8_character_code}} in function xmerl_ucs:from_utf8/1 in call from mochijson2:json_encode_string/2 What version of the product are you using? On what operating system? r97, any OS. Discussed in detail in https://issues.apache.org/jira/browse/COUCHDB-345. I think the ideal solution from CouchDB's perspective would be for mochijson2 to accept input in any Unicode encoding. An interim solution that we've adopted is to reject anything other than UTF-8. I'm not sure if that's an appropriate solution for the broader Mochiweb community, but nevertheless I'm attaching the patch.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) commented on by bob.ippolito   -   This patch doesn't look quite correct to me, what if the client sends too much data? I think a more robust solution will be more complicated.

  This patch doesn't look quite correct to me, what if the client sends too much data? I think a more robust solution will be more complicated.
• Nov 09, 2009

  issue 46 (stream_unchunked_body discriminates against slow connections) reported by adam.kocoloski   -   What steps will reproduce the problem? 1. Try to upload a 1MB file w/o chunked encoding on a connection slower than 100 KBps What is the expected output? What do you see instead? The upload should succeed, but Mochiweb times out if it does not receive 1MB in 10 seconds. What version of the product are you using? On what operating system? I was using CouchDB's embedded version of Mochiweb (a fork of r97). Any OS. We discussed this a bit on the CouchDB developer list at http://mail-archives.apache.org/mod_mbox/couchdb-dev/200911.mbox/%3cE86B310B-29CA- 4BBC-A99E-3DBABC240372@apache.org%3e and ended up switching to Apache's default behavior, which is to only trigger a timeout if no data is received in 5 minutes. The patch I'm attaching that does part of this -- it will never trigger a timeout if server is still receiving data (that's the important imo), but it maintains MochiWeb's default ?IDLE_TIMEOUT of 10 seconds rather than the 5 minutes we went with for Couch.

  What steps will reproduce the problem? 1. Try to upload a 1MB file w/o chunked encoding on a connection slower than 100 KBps What is the expected output? What do you see instead? The upload should succeed, but Mochiweb times out if it does not receive 1MB in 10 seconds. What version of the product are you using? On what operating system? I was using CouchDB's embedded version of Mochiweb (a fork of r97). Any OS. We discussed this a bit on the CouchDB developer list at http://mail-archives.apache.org/mod_mbox/couchdb-dev/200911.mbox/%3cE86B310B-29CA- 4BBC-A99E-3DBABC240372@apache.org%3e and ended up switching to Apache's default behavior, which is to only trigger a timeout if no data is received in 5 minutes. The patch I'm attaching that does part of this -- it will never trigger a timeout if server is still receiving data (that's the important imo), but it maintains MochiWeb's default ?IDLE_TIMEOUT of 10 seconds rather than the 5 minutes we went with for Couch.
• Nov 05, 2009

  r111 (patch from Kostis Sagonas, obtained by using tidier, a tool ...) committed by bob.ippolito   -   patch from Kostis Sagonas, obtained by using tidier, a tool that tidies Erlang code

  patch from Kostis Sagonas, obtained by using tidier, a tool that tidies Erlang code
• Oct 12, 2009

  issue 19 (The patch which allow Mochiweb to work through HTTPS) commented on by bchesneau   -   any status about it ? Would be useful too, I would like to add ssl support to http://github.com/benoitc/couchdbproxy .

  any status about it ? Would be useful too, I would like to add ssl support to http://github.com/benoitc/couchdbproxy .
• Oct 07, 2009

  issue 45 (mochijson:decode() \u00e9 etc.) commented on by vinnitu   -   new version of my wrapper with encode and decode function

  new version of my wrapper with encode and decode function
• Oct 06, 2009

  issue 45 (mochijson:decode() \u00e9 etc.) commented on by vinnitu   -   I written small wrapper to handle this trouble it can be used by json:decode(Json). see attach

  I written small wrapper to handle this trouble it can be used by json:decode(Json). see attach
• Oct 06, 2009

  issue 33 (mochijson:encode issue with {input_encoding, utf8}) commented on by bob.ippolito   -   You can't. input_encoding only affects the input, not the output.

  You can't. input_encoding only affects the input, not the output.
• Oct 06, 2009

  issue 45 (mochijson:decode() \u00e9 etc.) Status changed by bob.ippolito   -   mochijson decodes to unicode code points, not to UTF-8, so what you want is not possible. When it encodes a binary as a string (by default) it considers it to be UTF-8 because binaries only contain octets, but when it encodes a list it assumes it to be unicode code points. You need to change your code to use mochijson2 if you want UTF-8 in both directions. mochijson will never return atoms directly because that can cause a leak in the atom table. The library is doing exactly what it's supposed to do in this case, if you need help you might want to try the google group.

  Status: Invalid

  mochijson decodes to unicode code points, not to UTF-8, so what you want is not possible. When it encodes a binary as a string (by default) it considers it to be UTF-8 because binaries only contain octets, but when it encodes a list it assumes it to be unicode code points. You need to change your code to use mochijson2 if you want UTF-8 in both directions. mochijson will never return atoms directly because that can cause a leak in the atom table. The library is doing exactly what it's supposed to do in this case, if you need help you might want to try the google group.

  Status: Invalid
• Oct 06, 2009

  issue 33 (mochijson:encode issue with {input_encoding, utf8}) commented on by vinnitu   -   how to decode \u00a3 to [194, 163] with this fix?

  how to decode \u00a3 to [194, 163] with this fix?
• Oct 06, 2009

  issue 45 (mochijson:decode() \u00e9 etc.) commented on by vinnitu   -   and maybe you now howto handle with {struct, []} member to do it atom (now it is string in response)

  and maybe you now howto handle with {struct, []} member to do it atom (now it is string in response)
• Oct 06, 2009

  issue 45 (mochijson:decode() \u00e9 etc.) reported by vinnitu   -   1> mochijson:encode("\303\251"). [34,"\\u00c3","\\u00a9",34] 2> mochijson:decode([34,"\\u00c3","\\u00a9",34]). "\303\251" and we can see input in (1) and output in (2) is equal, it is good, but i am wait for "\u00e9" see next example ==================================== 3> mochijson:encode(<<"\303\251">>). [34,"\\u00e9",34] 4> mochijson:decode([34,"\\u00e9",34]). "\351" ok, we get in (3) "\u00e9" but(!) input (1) not equal output (4)!!! - it is bad :((( The difference is not-binary and binary input form and in my case it will work properly with mochijson2, but... I need form {struct, []}, {array, []} and I cannot get it work with mochijson2 :-( Please, tell me what can I do to solve this trouble?.. Thx.

  1> mochijson:encode("\303\251"). [34,"\\u00c3","\\u00a9",34] 2> mochijson:decode([34,"\\u00c3","\\u00a9",34]). "\303\251" and we can see input in (1) and output in (2) is equal, it is good, but i am wait for "\u00e9" see next example ==================================== 3> mochijson:encode(<<"\303\251">>). [34,"\\u00e9",34] 4> mochijson:decode([34,"\\u00e9",34]). "\351" ok, we get in (3) "\u00e9" but(!) input (1) not equal output (4)!!! - it is bad :((( The difference is not-binary and binary input form and in my case it will work properly with mochijson2, but... I need form {struct, []}, {array, []} and I cannot get it work with mochijson2 :-( Please, tell me what can I do to solve this trouble?.. Thx.
• Oct 04, 2009

  issue 19 (The patch which allow Mochiweb to work through HTTPS) commented on by hqmq27   -   I also vote for inclusion of this feature into the official release. I am writing an application that I would like to license, but the client will require https for sure. I would much rather use mochiweb than yaws for this.

  I also vote for inclusion of this feature into the official release. I am writing an application that I would like to license, but the client will require https for sure. I would much rather use mochiweb than yaws for this.
• Sep 28, 2009

  r110 (change default backlog to 128) committed by bob.ippolito   -   change default backlog to 128

  change default backlog to 128
• Sep 28, 2009

  issue 22 (Problems uploading files) Status changed by bob.ippolito   -   fixed in r109

  Status: Fixed

  fixed in r109

  Status: Fixed
• Sep 28, 2009

  r109 (finally fixing http://code.google.com/p/mochiweb/issues/deta...) committed by bob.ippolito   -   finally fixing http://code.google.com/p/mochiweb/issues/detail?id=22

  finally fixing http://code.google.com/p/mochiweb/issues/detail?id=22
• Sep 28, 2009

  issue 39 (No useful diagnostics for errors during Mochiweb_request:sen...) Status changed by bob.ippolito   -   Sockets close for all sorts of reasons and it's usually the fault of the client. This is a deliberate decision to prevent noise when you're doing millions of requests a day...

  Status: WontFix

  Sockets close for all sorts of reasons and it's usually the fault of the client. This is a deliberate decision to prevent noise when you're doing millions of requests a day...

  Status: WontFix
• Sep 28, 2009

  issue 41 (Windows CR) Status changed by bob.ippolito   -   I can't reproduce this

  Status: Invalid

  I can't reproduce this

  Status: Invalid
• Sep 28, 2009

  issue 35 (Coalesce UTF-16 surrogate pairs in mochijson2:decode) Status changed by bob.ippolito   -   applied in r108

  Status: Fixed

  applied in r108

  Status: Fixed
• Sep 28, 2009

  r108 (apply utf16-surrogate-pair.diff from http://code.google.com/...) committed by bob.ippolito   -   apply utf16-surrogate-pair.diff from http://code.google.com/p/mochiweb/issues/detail?id=35

  apply utf16-surrogate-pair.diff from http://code.google.com/p/mochiweb/issues/detail?id=35
• Sep 28, 2009

  issue 44 (export a continuation from mochiweb_http so hibernating proc...) Status changed by bob.ippolito   -   applied in r106

  Status: Fixed

  applied in r106

  Status: Fixed
• Sep 28, 2009

  r107 (add a stub examples folder) committed by bob.ippolito   -   add a stub examples folder

  add a stub examples folder
• Sep 28, 2009

  r106 (http://code.google.com/p/mochiweb/issues/detail?id=44) committed by bob.ippolito   -   http://code.google.com/p/mochiweb/issues/detail?id=44

  http://code.google.com/p/mochiweb/issues/detail?id=44
• Sep 28, 2009

  r105 (301.patch from Ben Hood on Jul 16th to add slashes for direc...) committed by bob.ippolito   -   301.patch from Ben Hood on Jul 16th to add slashes for directories

  301.patch from Ben Hood on Jul 16th to add slashes for directories
• Sep 16, 2009

  issue 44 (export a continuation from mochiweb_http so hibernating proc...) reported by chris.piro   -   if you're writing a web app that implements comet long polling, you'll save a lot of memory by hibernating between the request and response. however, since the execution context is discarded when the handler hibernates, control flow falls out the bottom of your callback, the handler terminates, and keep alives don't work. if mochiweb_http exposes a continuation that encapsulates returning to the top of the request loop then we can call that in our hibernate callback, and control flow returns to mochiweb like it would have without hibernate. does that sound reasonable? i've included a patch that does that without changing the existing interface, so it shouldn't bother existing user code. i've also included an example showing how to make a server with it. some of that longwindedness might get rolled into a comment or included in some documentation somewhere, cuz it's not really straightforward. speaking of documentation: it'd be useful to have a web page somewhere with an introduction and some examples. i could throw my example on a blog somewhere, but it'd be nice for the project if there were centralized docs. i'd be willing to compile what's out there on the blogs with my experience into a quick tutorial if you think that'd help. thanks, chris

  if you're writing a web app that implements comet long polling, you'll save a lot of memory by hibernating between the request and response. however, since the execution context is discarded when the handler hibernates, control flow falls out the bottom of your callback, the handler terminates, and keep alives don't work. if mochiweb_http exposes a continuation that encapsulates returning to the top of the request loop then we can call that in our hibernate callback, and control flow returns to mochiweb like it would have without hibernate. does that sound reasonable? i've included a patch that does that without changing the existing interface, so it shouldn't bother existing user code. i've also included an example showing how to make a server with it. some of that longwindedness might get rolled into a comment or included in some documentation somewhere, cuz it's not really straightforward. speaking of documentation: it'd be useful to have a web page somewhere with an introduction and some examples. i could throw my example on a blog somewhere, but it'd be nice for the project if there were centralized docs. i'd be willing to compile what's out there on the blogs with my experience into a quick tutorial if you think that'd help. thanks, chris
• Aug 30, 2009

  issue 43 (Why i checkout svn, the mochiweb can't start....) commented on by luan.nombx   -   I'm sorry!!!

  I'm sorry!!!