mochi / mochiweb Goto Github PK

Attempting make for clone of the respository under Cygwin fails.

Output of build follows, and a workaround also provided below.

[Steve@Tronnix:~/playdar-core/deps/mochiweb]$ make
(cd src;make all)
make[1]: Entering directory `/cygdrive/c/Users/Steve/Documents/playdar-core/deps/mochiweb/src'
erlc -W -I ../include  +debug_info -o ../ebin mochifmt.erl
erlc -W -I ../include  +debug_info -o ../ebin mochifmt_records.erl
erlc -W -I ../include  +debug_info -o ../ebin mochifmt_std.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiglobal.erl
erlc -W -I ../include  +debug_info -o ../ebin mochihex.erl
erlc -W -I ../include  +debug_info -o ../ebin mochijson.erl
erlc -W -I ../include  +debug_info -o ../ebin mochijson2.erl
erlc -W -I ../include  +debug_info -o ../ebin mochilists.erl
erlc -W -I ../include  +debug_info -o ../ebin mochilogfile2.erl
erlc -W -I ../include  +debug_info -o ../ebin mochinum.erl
erlc -W -I ../include  +debug_info -o ../ebin mochitemp.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiutf8.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_acceptor.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_app.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_charref.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_cookies.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_cover.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_echo.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_headers.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_html.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_http.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_io.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_mime.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_multipart.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_request.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_response.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_skel.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_socket.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_socket_server.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_sup.erl
erlc -W -I ../include  +debug_info -o ../ebin mochiweb_util.erl
erlc -W -I ../include  +debug_info -o ../ebin reloader.erl
../support/make_app.escript mochiweb.app.src ../ebin/mochiweb.app "" "mochifmt mochifmt_records mochifmt_std mochiglobal mochihex mochijson mochijson2 mochilists mochilogfile2 mochinum mochitemp mochiutf8 mochiweb mochiweb_acceptor mochiweb_app mochiweb_charref mochiweb_cookies mochiweb_cover mochiweb_echo mochiweb_headers mochiweb_html mochiweb_http mochiweb_io mochiweb_mime mochiweb_multipart mochiweb_request mochiweb_response mochiweb_skel mochiweb_socket mochiweb_socket_server mochiweb_sup mochiweb_util reloader"
escript: exception error: no match of right hand side value
                 ["mochiweb.app.src","../ebin/mochiweb.app",
                  "mochifmt mochifmt_records mochifmt_std mochiglobal mochihex mochijson mochijson2 mochilists mochilogfile2 mochinum mochitemp mochiutf8 mochiweb mochiweb_acceptor mochiweb_app mochiweb_charref mochiweb_cookies mochiweb_cover mochiweb_echo mochiweb_headers mochiweb_html mochiweb_http mochiweb_io mochiweb_mime mochiweb_multipart mochiweb_request mochiweb_response mochiweb_skel mochiweb_socket mochiweb_socket_server mochiweb_sup mochiweb_util reloader"]
make[1]: *** [../ebin/mochiweb.app] Error 127
make[1]: Leaving directory `/cygdrive/c/Users/Steve/Documents/playdar-core/deps/mochiweb/src'
make: *** [all] Error 2

The workaround (suggested by RJ) is to change the "" to "1.3" in this line of the include.mk file.

Currently the cookie expires header will give the following, wrong, date format string:

Sat, 30 Jun 2012 13:43:15 GMT

According to RFC2109 section 10.1.2 this should be:

Sat, 30-Jun-2012 13:43:15 GMT

Some clients (for instance inets httpc) will error.

diff -r b9f158eae221 -r e6deaf176ed5 deps/mochiweb/src/mochiweb_cookies.erl
--- a/deps/mochiweb/src/mochiweb_cookies.erl Thu Jan 27 14:44:22 2011 +0100
+++ b/deps/mochiweb/src/mochiweb_cookies.erl Thu Jan 27 15:32:33 2011 +0100
@@ -120,8 +120,22 @@
Greg = calendar:datetime_to_gregorian_seconds(LocalTime),
calendar:gregorian_seconds_to_datetime(Greg + Secs).

+%% Return a date in the form of: Wdy, DD-Mon-YYYY HH:MM:SS GMT
+%% See also: rfc2109: 10.1.2
+rfc2109_cookie_expires_date(LocalTime) ->

• {{YYYY,MM,DD},{Hour,Min,Sec}} =

•    case calendar:local_time_to_universal_time_dst(LocalTime) of
  

•        [Gmt]   -> Gmt;
  

•        [_,Gmt] -> Gmt
  

•    end,
  

• DayNumber = calendar:day_of_the_week({YYYY,MM,DD}),
• lists:flatten(

•  io_lib:format("~s, ~2.2.0w-~3.s-~4.4.0w ~2.2.0w:~2.2.0w:~2.2.0w GMT",
  

•                [httpd_util:day(DayNumber),DD,httpd_util:month(MM),YYYY,Hour,Min,Sec])).
  

  age_to_cookie_date(Age, LocalTime) ->
• httpd_util:rfc1123_date(add_seconds(Age, LocalTime)).
• rfc2109_cookie_expires_date(add_seconds(Age, LocalTime)).

%% @SPEC parse_cookie(string()) -> [{K::string(), V::string()}]
%% @doc Parse the contents of a Cookie header field, ignoring cookie
@@ -294,14 +308,14 @@
C2 = {"Set-Cookie",
"Customer=WILE_E_COYOTE; "
"Version=1; "

•      "Expires=Tue, 15 May 2007 13:45:33 GMT; "
  

•      "Expires=Tue, 15-May-2007 13:45:33 GMT; "
     "Max-Age=0"},
  

  C2 = cookie("Customer", "WILE_E_COYOTE",
  [{max_age, -111}, {local_time, LocalTime}]),
  C3 = {"Set-Cookie",
  "Customer=WILE_E_COYOTE; "
  "Version=1; "

•      "Expires=Wed, 16 May 2007 13:45:50 GMT; "
  

•      "Expires=Wed, 16-May-2007 13:45:50 GMT; "
     "Max-Age=86417"},
  

  C3 = cookie("Customer", "WILE_E_COYOTE",
  [{max_age, 86417}, {local_time, LocalTime}]),

Hi,

I recently had a client sending cookies with forward slashes "/" in their values.
Mochiweb considers them as separators, and it mentions RFC 2068 as the source for the cookie pairs separators. However I don't see anything explicit in that RFC regarding cookies (and neither in 2616).

RFC 2109 (HTTP State management mechanism) isn't explicit as well about allowed characters for a cookie value. Googling around, many people claim that a cookie value can contain any character except semi-collon and white spaces. Some implementations even eccept quoted cookie values where white spaces are allowed within.

Do you think that removing the forward slash, and eventually other characters from the IS_SEPARATOR macro function in mochiweb_cookies is doable?
I would prefer keeping my mochiweb exactly the same as yours and avoid patching it.

cheers

./mochifmt.erl:none: error in parse transform 'eunit_autoexport': {undef,
[{eunit_autoexport,
parse_transform,
[[{attribute,1,file, ... etc.

Erlang R13B01 (erts-5.7.2)

In this OTP version we must to start 'public_key' application before using 'ssl' application.

Here is a failed build log
http://koji.fedoraproject.org/koji/getfile?taskID=2312725&name=build.log

and here is a successful one (after applying simple patch, mentioned below):
http://koji.fedoraproject.org/koji/getfile?taskID=2312748&name=build.log

Here is a necessary and simple patch:
http://cvs.fedoraproject.org/viewvc/rpms/erlang-mochiweb/devel/erlang-mochiweb-0002-Fix-for-Erlang-OTP-R14A.patch?view=co

It will be helpful if the docs of mochiweb_cookies:cookie/3
say max_age is in units of seconds.

Thanks

When file retrieved from server response header 'Content-Type' doesn't contain charset value. It will cause problems with unicode chars in static files.

It would be very nice to have option to add custom charset to 'Content-Type' header value.

While tracking down a problem with a finicky client, I discovered that the client's "Connection: Close" header was being ignored by mochiweb. Upon inspection, the relevant function "mochiweb_request:do_close/0" is making an exact string comparison between the "connection" header value and the string "close". The HTTP/1.1 spec does not clearly state whether the "close" token should be considered case sensitive or not, but a close reading shows that it is case insensitive.

A recent post on stackoverflow, http://stackoverflow.com/questions/10953635/are-the-http-connection-header-values-case-sensitive, points out that the requirement that the connection header field can carry a header field name, and header field names being case insensitive themelves, does imply that it is case insensitive.

I haven not attached a fix, because I don't know how pervasive this might be. It is clear enough in mochiweb_request.erl, and indeed my own local patch which merely makes the string comparisons case insensitive has fixed my particular problem.

I pushed a fix and a small addition to the test suite to my fork:

http://github.com/kocolosk/mochiweb/commit/d58c6ffd32a1364afff99cb4aa5c801b8d19081d

I've squashed my websockets patch into my mochiweb fork here: https://github.com/RJ/mochiweb/

Relevant commit: RJ@0e94193

Contains an example showing websockets over ssl with origin validation, and some tests for header parsing and decoding websockets frames.

I will endeavour to keep this working, as and when the websockets spec changes.

Hi,

In the code to decode a POST submitted form, with content type "application/x-www-form-urlencoded", there is a process of decoding the urlencoded (percent-hex) strings for the keys and values. A problem is that the hex encoded characters are placed literally back into the translated string. There is no accommodation for the character encoding. This means that the resulting string contains the integers from the utf8 sequence rather than the string translated from the utf8 sequence to unicode codepoints, which is what a string is expected to contain.

There are some methods available in http to communicate the encoding, but they seem to be in total disarray, and besides a form may be configured to send as either POST or GET and then things get really fun.

As far as I can gather, the issue has been punted to "everything is utf8", meaning that we should assume that all modern browsers encode user input as utf-8 before urlencoding and finally encapsulating into the query string format.

Now, with mochiweb at the moment, I can deal with this by assuming the results of mochiweb_util:parse_qs are integer lists that represent utf-8 sequences, and this generally works simply by using "list_to_binary" on a value returned by proplists:get_value(). For instance, the value can be used as part of a json document or in other contexts which expect a utf8 binary. However, this is a hack, because the original string is an invalid representation.

I see two ways out of this sticky wicket. One is to fix the strings created by parse_qs. They would be converted from utf8 to unicode strings. This stays with the spirit of mochiweb where things are mostly strings. The downside of this is that if other people are using list_to_binary to convert them to utf8 there will be breakage.

The second is to keep everything in binaries, thus preserving the original byte sequences as well as utilizing Erlang's default utf8 mode for binary "strings".

I've read the past discussions and attempts to "binaryize" mochiweb (esp. benbro), which I believe ended in the conclusion that it would be not too much fun to do (lots of testing, managing merges, etc.), even though it looked like the effort was nearly complete, and that those looking for Erlang web servers operating in binary mode maybe should look elsewhere. However, at the moment my project is wound up with Webmachine, which itself is bound to Mochiweb.

So, I guess to wind this up I'm looking for advice - am I right that parse_qs is broken in this respect? Is it fixable in the mother code? Should it be handled by a fork? Should that fork bite the bullet to binary, perhaps building on the work of benbro?

Thanks.

https://github.com/mochi/mochiweb/blob/master/src/mochiweb_socket_server.erl#L128

IMHO, start/* is expected not to link, if somebody wants to link, there should be a separate start_link/* function.

http://github.com/mochi/mochiweb/blob/master/src/mochiweb_request.erl#L402

It would appear that mochiweb_request:cleanup/0 is missing ?SAVE_BODY_LENGTH from the list of things to delete from it's process dict. Is that a simple bug, or am I missing something about Req:get(body_length)?

Here is some interesting behavior:

> mochijson2:decode(<<"[15]">>).                                     
[15]
> mochijson2:decode(<<"[10]">>).
"\n"
> list_to_binary(mochijson2:encode([10])). 
<<"[10]">>
> mochijson2:decode(list_to_binary(mochijson2:encode([10]))).
"\n"

So if you encode [10] then code it you don't get [10] back out.

Any ideas?

If one runs:

dialyzer ebin -Wunmatched_returns

one gets various warnings which, although not errors, show places where return values are ignored which often signifies places where the intention of the programmer may not be the one that the code performs. In most cases, these warnings are very easy to fix.

For example, the first of these warnings reads:

mochiweb.erl:23: Expression produces a value of type 'ok' | {'error',_}, but this value is unmatched

and comes from the code:

%% @spec stop() -> ok
%% @doc Stop the MochiWeb server.
stop() ->
    Res = application:stop(mochiweb),
    application:stop(crypto),
    Res.

At least judging from the @SPEC, the intention here is that the mochiweb application should indeed successfully stop, but the code above does not ensure that. In fact, there is no guarantee that the function will return 'ok' as its spec says. Also, there may be an error when trying to stop the crypto application. To ensure these two, and shut off this warning, the following code is better:

%% @spec stop() -> ok
%% @doc Stop the MochiWeb server.
stop() ->
    ok = application:stop(mochiweb),
    ok = application:stop(crypto).

Of course, it might just be that the @SPEC is wrong here, and this function should actually return the result of the application:stop(mochiweb) call and ignore the return value of application:stop(crypto). In such a case, the following code is better:

%% @spec stop() -> ok | {error, term()}
%% @doc Stop the MochiWeb server.
stop() ->
    Res = application:stop(mochiweb),
    _ = application:stop(crypto),
    Res.

Anyway, you may want to review all these places and fix them appropriately.

I can help in this, if you want me to.

Kostis

http://github.com/fdmanana/mochiweb/commit/c8139eab3c1cedb62c679cb9c04b9cea19136448

I'm curious about the catch-all match in the receive block of mochiweb_http:request/2:

Mainly, why does this clause trigger an error, instead of just ignoring the message?

This behavior is causing trouble for me because I have a request handler (a Webmachine resource) that spawns other processes and waits for messages from them. The request handler may decide to send a response to the client before it receives all of the messages from the other processes, though. If Req:should_close() returns false after the handler finishes, the process ends up back in this receive block, with the possibility of some leftover messages ripe for picking from its mailbox. I'd rather just have those messages dropped on the floor, instead of causing errors here.

Could my use case be fixed by possibly expanding the list of clauses to find other types of errors that mochiweb is interested in, while ignoring all other messages, or is there a reason I'm missing for blowing up with a 400 here?

This question will also apply to mochiweb_http:headers/5:

As noted, I'm dealing with a Webmachine resource, so I'm actually working with mochiweb 1.5.1, but the clause there is very similar.

Thanks,
Bryan

Hello. I'm using mochiweb as part of a larger project. I'm trying to achieve a clean dialyzer report. Three unknown functions are being reported in mochiweb's code base.

Are these unknown functions expected? If so, which application(s) are required (e.g. yaws)?

thanks,

Unknown functions:
fdsrv:bind_socket/2
fdsrv:start/0
fdsrv:stop/0
done in 2m26.69s
done (warnings were emitted)
make: *** [dialyze-spec] Error 2
[norton@chibiko hibari (rebarify)]$ f lib -name "*.erl" -exec grep fdsrv: {} ; -print
case catch fdsrv:start() of
case fdsrv:bind_socket(tcp, Port) of
catch fdsrv:stop(),
lib/mochiweb/src/mochiweb_socket_server.erl

I found out mochi-web has bug in parsing header 'x-forwarded-for' which is missing from time to time.

The following code is more kosher for what you want to do there and also shuts off a dialyzer warning.

 diff --git a/src/mochiweb_sup.erl b/src/mochiweb_sup.erl
 index af7df9b..8a3e65f 100644
 --- a/src/mochiweb_sup.erl
 +++ b/src/mochiweb_sup.erl
 @@ -23,8 +23,7 @@ start_link() ->
  %% @doc Add processes if necessary.
  upgrade() ->
      {ok, {_, Specs}} = init([]),
 -    [supervisor:start_child(?MODULE, Spec) || Spec  - Specs],
 -    ok.
 +    lists:foreach(fun(S) -> supervisor:start_child(?MODULE, S) end, Specs).
 
  %% @spec init([]) -> SupervisorTree
  %% @doc supervisor callback, ensures yaws is in embedded mode and then

Kostis

Example:

 20> mochiweb_html:parse("<done>Matt’s Breaking Line</done>").    
 ** exception error: bad argument
      in function  iolist_to_binary/1
         called as iolist_to_binary([60,100,111,110,101,62,77,97,116,116,8217,
                                          115,32,66,114,101,97,107,105,110,103,32,
                                          76,105,110,101,60,47|...])
      in call from mochiweb_html:tokens/1
      in call from mochiweb_html:parse/1

 17> mochiweb_html:parse(<<"<done>Matts Breaking Line</done>">>). 
 {<<"done">>,[],[<<"Matts Breaking Line">>]}

Going through mochiweb_html and replacing all iolist_to_binary/1 with unicode:characters_to_binary/1 almost works (along with replacing all binary_to_list/1 with unicode:characters_to_list/1). It causes the functions to return, but the output is garbled:

 14> io:format("~s~n", [unicode:characters_to_binary(mochiweb_html:to_html(mochiweb_html:parse("<done>Matt’s Breaking Line</done>")))]).
 <done>Matt�s Breaking Line</done>

Any ideas on how to help multi-byte characters survive a mochiweb_html:parse/1 to mochiweb_html:to_html/1 cycle?

Handling ' in mochiweb_charref. Right now mochiweb_charref does not handle '

I think the full exhaust list supported by HTML can be found here:
http://www.w3.org/TR/html5/named-character-references.html#named-character-references

When running dialyzer against mochiweb's codebase I found the following error:

src/mochifmt_records.erl:29: Call to missing or unexported function mochifmt:get_value/3

Apparently, the solution would be to remove the argument THIS from the call to mochifmt:get_value/3 in mochifmt_records.erl.

If a multibyte character exists either in the querystring or the post body, mochiweb's parse_qs and parse_post will return something unexpected:

Currently, for /?foo=progeyö we get:
parse_qs() -> [{"foo","progeyö"}]
..since the last character is two bytes wide.

I've added parse_qs_utf8() and parse_post_utf8() that run the values through xmerl_ucs:from_utf8/1, and cache the results like the normal parse_qs does:

RJ@60f4ae7

So now if you want to, on requests that need it, you can use parse_qs_utf8 or parse_post_utf8:
parse_qs_utf8() [{"foo","progeyö"}]

NB: this means xmerl needs to be started.

When trying to make a project created with mochiweb (git clone of HEAD as of 2011-03-11) "make app" I got:

Pulling mochiweb from {git,"git://github.com/mochi/mochiweb.git",[]}
Cloning into mochiweb...
error: pathspec 'origin/' did not match any file(s) known to git.
ERROR: git checkout -q origin/ failed with error: 1
make: *** [all] Error 1


The mochiweb dependency in rebar.conf looked like this:
{git, "git://github.com/mochi/mochiweb.git", ""}}]}.

It works if I change the template to:
{git,"git://github.com/mochi/mochiweb.git","HEAD"}

It was a long time since last released 1.3.0, and many new patches were added. Perhaps it's time to tag 1.3.1, 1.4.0 or even 2.0.0, isn't it?

This is feature request not a bug.
Google SPDY supported by Chrome and Firefox (see https://bugzilla.mozilla.org/show_bug.cgi?id=spdy) which means more than 50% of the browser market share.

So trying to see if mochiweb going to implement it.

Hi,

Currently the recbuf of the socket is hardcoded to the value 8192 bytes. This is quite low compared to the default on many systems:

Eshell V5.8.2 (abort with ^G)
1> {ok, S} = gen_tcp:connect("www.sapo.pt", 80, [binary, {packet, 0}]).
{ok,#Port<0.589>}
2>
2> inet:getopts(S, [recbuf]).
{ok,[{recbuf,87380}]}

Being able to change this parameter also allows us to have some performance gains in some scenarios. The following tutorial explains it:
http://www.ibm.com/developerworks/linux/library/l-hisock.html

The following patch makes it configurable:

fdmanana@8d41206

cheers

An example is the url
http://www.tyres-pneus-online.co.uk/car-tyres/PIRELLI/

that contains lines like

Regards
Matteo
http://github.com/matteoredaelli/ebot

I'm running this code http://pastebin.com/DGDXe5D0 and it crashes when I feed it this POST request: curl -F file=@UP-TEST http://localhost/. up-test is small test file.

When parsing a html like this:

mochiweb_html:parse("<a href='test?x=y&b=&amp;'></a>").
{<<"a">>,[{<<"href">>,<<"test?x=y&b=&">>}],[]}

The charref is automatically interpreted, but this is not what you want for url attributes. The problem is that this makes it impossible to turn into html again in the right way because both all ampersands would be escaped. The resulting url will be wrong. (Note that parsing a correct href with a query string also results in a broken url.)

I think the way to fix bug this is to not interpret charrefs in url attributes and reading them as is. When the tree is converted back into html again they should not be escaped and written as-is.

What do you think? I would gladly provide you with a pull-request with tests if you agree.

Description: Starting with a clean checkout/clone today, attempts to run the new_mochiweb.erl script resulted in failure with a reproducible error reported in function mochiweb_skel:skelcopy/2. Changing into the newly created application's directory and invoking 'make' results in failure, apparently indicating that setup was left incomplete for the new app.

Expected Behavior: Running new_mochiweb.erl should successfully produce a new application directory and fully populate it with files suitable for supporting a build in that new app directory using the generated Makefile.

Workaround: Creating the missing directory "deps" inside the new app's directory then re-running new_mochiweb.erl with the same arguments (exactly as before) results in the script running to completion. Changing into the new app's directory and running 'make' runs happily to completion, verifiable by running start-dev.sh and visiting http://localhost:8000 in a browser.

To Reproduce:
work/mochiweb> scripts/new_mochiweb.erl my_app /tmp
/tmp/my_app/
/tmp/my_app/support/
run_tests.escript
include.mk
/tmp/my_app/src/
skel.app
skel_app.erl
skel_web.erl
skel_sup.erl
skel.hrl
skel.erl
skel_deps.erl
Makefile
/tmp/my_app/priv/
/tmp/my_app/priv/www/
index.html
start-dev.sh
start.sh
Makefile
escript: exception error: no match of right hand side value {error,enoent}
in function mochiweb_skel:skelcopy/2
in call from 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/4
in call from escript:start/1
in call from init:start_it/1
in call from init:start_em/1

Supporting Info on Workaround:
work/mochiweb> mkdir /tmp/my_app/deps
work/mochiweb> scripts/new_mochiweb.erl my_app /tmp
/tmp/my_app/
/tmp/my_app/support/
run_tests.escript
include.mk
/tmp/my_app/src/
skel.app
skel_app.erl
skel_web.erl
skel_sup.erl
skel.hrl
skel.erl
skel_deps.erl
Makefile
/tmp/my_app/priv/
/tmp/my_app/priv/www/
index.html
start-dev.sh
start.sh
Makefile
work/mochiweb>

Hey. There's a possibility of a crash happening in the cookie code when the time is set on a DST change: https://github.com/mochi/mochiweb/blob/master/src/mochiweb_cookies.erl#L124

It got reported initially in cowboy whose cookie support is a direct port of mochiweb's written by @BFrog - issue here with more details: ninenines/cowboy#157

I didn't test it specifically in mochiweb, so you might already have taken measures to prevent it in which case please disregard this report.

Pinging related people @ferd @klaar to notice them about me opening this issue here.

Please, enable wiki

It's not a secret that a lot of mochiweb modules such as mochijson or mochinum are widely used and have their own value beside being a part of mochiweb. I think it is a good idea to make something like "mochiweb-utils" package and exclude them from mochiweb itself, isn't it?

minor issue but the spec for recv_body is:

@SPEC recv_body(integer()) -> binary()

yet parse_post checks for undefined?

https://groups.google.com/group/mochiweb/browse_thread/thread/f2c61de1f3ad036d

mochiweb_html:parse("<html><body onload="javascript:A('1&2')"></body></html>") -> {<<"html">>,[],
[{<<"body">>,[{<<"onload">>,<<"javascript:A('12')">>}],[]}]}
If you attentiveness see at input HTML you see javascript:A('1&2') but at result you see only javascript:A('12').

If the Request-URI in the HTTP request line is an absoluteURI, then the protocol, host & port are ignored when creating the mochiweb_request and there is no way to access these values later:
https://github.com/mochi/mochiweb/blob/v2.2.1/src/mochiweb.erl#L45

This is needed to correctly determine the resource identified by a request:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2
and is essential to be able to implement a forward proxy.

Regardless of directory specified or user permissions, I get...

escript: exception error: no case clause matching {error,enoent}
in function mochiweb_skel:skelcopy/4
in call from mochiweb_skel:skelcopy/2
in call from 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/4
in call from escript:start/1
in call from init:start_it/1

Example command:
cd mochiweb/scripts
./new_mochiweb.erl test (produces the above error)

./rebar doc warnings with R14B04. I didn't try older Erlang/OTP releases.

$ ./rebar doc
==> mochiweb (doc)
./src/mochiweb_request.erl, function get_header_value/1: at line 35: warning: redefining built-in type 'iolist'.
./src/mochiweb_request.erl, function get_header_value/1: at line 36: warning: redefining built-in type 'iodata'.
./src/mochijson2.erl, function encoder/1: at line 67: warning: redefining built-in type 'iolist'.
./src/mochijson2.erl, function encoder/1: at line 68: warning: redefining built-in type 'iodata'.
./src/mochijson.erl, function encoder/1: at line 18: warning: redefining built-in type 'iolist'.
./src/mochijson.erl, function encoder/1: at line 19: warning: redefining built-in type 'iodata'.
./src/mochihex.erl, function to_hex/1: at line 11: warning: redefining built-in type 'iolist'.
./src/mochihex.erl, function to_hex/1: at line 12: warning: redefining built-in type 'iodata'.

running 'rebar dialyze' one gets the following warning on mochiweb's source:

which is due to checking for tuple() when the argument is a gb_tree() in the code of mochiweb_headers.erl:

  %% @spec make(headers() | [{key(), value()}]) -> headers()
  %% @doc Construct a headers() from the given list.
  make(L) when is_list(L) ->
     from_list(L);
  %% assume a tuple is already mochiweb_headers.
  make(T) when is_tuple(T) ->
     T.

which breaks the opacity of its argument.

I suggest you take out the is_tuple/1 guard from the second clause.

Kostis

1> mochinum:digits(math:pow(2, -1074)).
"4.9406564584124654e-324"
2> list_to_float(mochinum:digits(math:pow(2, -1074))) =:= 5.0e-324.
true
3> math:pow(2, -1074).
5.0e-324

Hi.
In mochiweb_socket.erl in line 43 there is:
accept(ListenSocket) ->
gen_tcp:accept(ListenSocket, ?ACCEPT_TIMEOUT).

This makes gen_tcp processes to die after timeout.
They constantly get respawned and die every 2 secs.
This adds unnesesary load to VM.
It shoud be better to let them wait for connection 'forever'.

Hi,

The following patch adds a function to mochiweb_requests.erl which allows the caller to know if the request accepts a specific media type:

fdmanana@20fa47c

cheers

Sending "lots of data" via http results in:

2012-05-31 14:02:55.125 [error] <0.3061.0> CRASH REPORT Process <0.3061.0> with 0 neighbours crashed with reason: no case clause matching {ok,{http_error,[0,0,0,14,100,101,118,49,64,49,50,55,46,48,46,48,46,49,0,0,12,239,131,104,3,100,0,8,112,101,101,114,105,110,102,111,104,4,100,0,9,112,101,101,114,95,105,110,102,111,107,0,5,49,46,49,46,50,107,0,5,49,46,49,46,50,104,5,100,0,7,99,104,115,116,97,116,101,100,0,15,100,101,118,57,57,64,49,50,55,46,48,46,48,46,49,108,0,0,0,1,104,2,100,0,15,100,101,118,57,57,64,49,50,55,46,48,46,48,46,49,104,2,97,10]},<<>>} in mochiweb_http:request/3 line 107

I triggered this by mistakenly pointing riak replication at the remote system's http port.

Refer to (courtesy Andrew T.):
https://github.com/mochi/mochiweb/blob/master/src/mochiweb_http.erl#L59

On Windows, it is possible to access arbitrary files by crafting a GET with unescaped backslash characters. For example:

GET /..............\ff\asubdir\secretfile

HTTP/1.1 200 OK
Server: MochiWeb/1.0 (Any of you quaids got a smint?)
Content-Type: text/plain
Content-Length: 14

Hello
World

Origin: http://www.couchbase.com/issues/browse/MB-7390

When using base64 strings in urls or http cookies we need to:

1. Remove "=" padding
2. Replace "+" with "-"
3. Replace "/" with "_"
   http://en.wikipedia.org/wiki/Base64#URL_applications

I've implemented encode_base64_url/1 and decode_base64_url/1 which return binary.
Will you consider adding it?

encode_base64_url(Url) ->
    Url1 = base64:encode(Url),
    Url2 = re:replace(Url1, <<"=+$">>, <<"">>, [{return, binary}]),
    Url3 = binary:replace(Url2, <<"/">>, <<"_">>, [global]),
    binary:replace(Url3, <<"+">>, <<"-">>, [global]).

decode_base64_url(Url64) when is_list(Url64) ->
    decode_base64_url(list_to_binary(Url64));

decode_base64_url(Url64) ->
    Url1 = binary:replace(Url64, <<"-">>, <<"+">>, [global]),
    Url2 = binary:replace(Url1, <<"_">>, <<"/">>, [global]),
    Padding = case byte_size(Url2) rem 4 of
        2 ->
            <<"==">>;
        3 ->
            <<"=">>;
        _ ->
            <<"">>
    end,
    base64:decode(<<Url2/binary, Padding/binary>>).

Steps to reproduce:

1. Download and unpack

$ wget http://ompldr.org/vZzlndw/error.html.bz2
$ bunzip2 error.html.bz2

1. In erlang console:

{ok, Data} = file:read_file("error.html"),

mochiweb_html:parse(Data).
** exception error: no case clause matching <<"<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional."...>>
     in function  mochiweb_html:find_qgt/2 
     in call from mochiweb_html:tokenize/2 
     in call from mochiweb_html:tokens/3 
     in call from mochiweb_html:parse/1 

but HTML source code looks valid.