klacke / yaws
- Source
- Commits
- Network (18)
- Issues (4)
- Downloads (6)
- Wiki (12)
- Graphs
-
Branch:
master
-
yssi ignored on appmods = </, myappmod>
4 comments Created about 1 month ago by lordmetroidUsing the server configuration, appmods = </, myappmod> prevents yssi to execute. Any {yssi, Filename} will simply result in nothing for the client.
Using a normal word instead of / for the appmod trigger do work.
Comments
-
The README says:
./configure --prefix=/usr/localBut there's no configure file (it has been removed some commits ago).
Comments
This is indeed so, A release contains a ./configure whereas the source doesn't.
Create on through autoconf - docs are updated.
ngocdaothanh
Sun Nov 29 22:37:40 -0800 2009
| link
I think a lot of people who want to use the latest version from Github don't know how to build because there's no configure file. README should mention that it can be created by autoconf.
I've realised that - I've had several questions on this. However, I still feel
that it's the right thing (TM) to not have ./configure checked in.
It just results in pointless diffs.
ngocdaothanh
Wed Dec 02 17:00:57 -0800 2009
| link
Thank you for the kind README. It's very clear now.
-
you can apply small patch for fix
-AS_HELP_STRING([--with-defaultcharset=String], [specify default charset, i.e UTF-8])) +AS_HELP_STRING([--with-default-charset=String], [specify default charset, i.e UTF-8]))Comments
Maybe you can set default charset to utf8?
There is no indication of charset on files which are requested as plain text.
Or better configurable option for each virtual host.By default today I don't set it to anything - which implies utf8. (according to the standard)
As for having it a configurable - I don't like that since it would be slightly
inefficient - this is driven today by code that is generated at compile time.Maybe is possible write app for static files? If you can, please, add it to examples. Thanks.
Hmm, what do you mean by "app for static files" - an appmod application that ships static content ? Check the {page, Page} return value.
See
man yaws_api
{page, Page}
Make Yaws return a different page than the one being requested. -
Hello,
Trying to change database backend for a old yaws project to couchdb , I've found that json in couch it's not compatible with json:encode, at least in binaries related stuff. I've patched json.erl to support only encoding of binaries in keys and value,
The patch it's the following, applied to 1.85 version, feel free to apply it if it's useful for another people.
Index: src/json.erl =================================================================== --- src/json.erl (revisión: 9410) +++ src/json.erl (copia de trabajo) @@ -109,6 +109,8 @@ unicode -> encode_string(xmerl_ucs:to_utf8(L)); no -> exit({json_encode, {not_string, L}}) end; +encode(B) when is_binary(B) -> + encode(erlang:binary_to_list(B)); encode({array, Props}) when is_list(Props) -> encode_array(Props); encode({struct, Props} = T) when is_list(Props) -> encode_object(T); encode(Bad) -> exit({json_encode, {bad_term, Bad}}). @@ -116,6 +118,8 @@ %% Encode an Erlang string to JSON. %% Accumulate strings in reverse. +encode_string(B) when is_binary(B) -> + encode_string(erlang:binary_to_list(B)); encode_string(S) -> encode_string(S, [$"]). % " fix highlight for vim :) encode_string([], Acc) -> lists:reverse([$" | Acc]); % " fix highlight for vim :) @@ -145,6 +149,7 @@ encode_object({struct, _Props} = Obj) -> M = obj_fold(fun({Key, Value}, Acc) -> S = case Key of + B when is_binary(B) -> encode_string(B); L when is_list(L) -> encode_string(L); A when is_atom(A) -> encode_string(atom_to_list(A)); _ -> exit({json_encode, {bad_key, Key}})Comments
Hello,
The version that you refer not supports binaries as keys as mine.Regards.
Ok good, once you guys sort this - I'll take what you have.
Looks reasonable to me, but it does cause a binary to go through the is_string method which it currently doesn't do. From the definition of binary_to_list/1, it looks to me like is_string should always return yes for the output of binary_to_list/1, making that round trip an O(len(B)) waste of time. Although encode_string already costs us O(len(S)) I guess.
Would something like this suffice? (I could be even more minimal, and just take the last hunk of the suggested patch, changing encode_string to encode, but this way it's consistent with the existing code.
diff --git a/src/json.erl b/src/json.erl index b0c3c63..cddcb00 100644 --- a/src/json.erl +++ b/src/json.erl @@ -101,7 +101,7 @@ encode(true) -> "true"; encode(false) -> "false"; encode(null) -> "null"; encode(undefined) -> "null"; -encode(B) when is_binary(B) -> encode_string(binary_to_list(B)); +encode(B) when is_binary(B) -> encode_string(B); encode(I) when is_integer(I) -> integer_to_list(I); encode(F) when is_float(F) -> io_lib:format("~g", [F]); encode(L) when is_list(L) -> @@ -117,6 +117,7 @@ encode(Bad) -> exit({json_encode, {bad_term, Bad}}). %% Encode an Erlang string to JSON. %% Accumulate strings in reverse. +encode_string(B) when is_binary(B) -> encode_string(binary_to_list(B)); encode_string(S) -> encode_string(S, [$"]). % " fix highlight for vim :) encode_string([], Acc) -> lists:reverse([$" | Acc]); % " fix highlight for vim :) @@ -146,6 +147,7 @@ encode_string([C | Cs], Acc) -> encode_object({struct, _Props} = Obj) -> M = obj_fold(fun({Key, Value}, Acc) -> S = case Key of + B when is_binary(B) -> encode_string(B); L when is_list(L) -> encode_string(L); A when is_atom(A) -> encode_string(atom_to_list(A)); _ -> exit({json_encode, {bad_key, Key}})Compile-tested only... If it's fine, I can throw together a proper commit with attributions etc fairly quickly, or you're welcome to take it as-is.
Great - patch looks just good, I applied it and pushed,
-
yaws_rpc produces non-compliant jsonrpc results
3 comments Created 2 months ago by TBBleLooking at the JSON-RPC specification at http://json-rpc.org/wiki/specification the returned result of a call needs to contain an error field, with value null for the success case. The example json-rpc python client code on the json-rpc.org site expects this field to be present.
It should be as simple as adding it to encode_handler_payload's json:encode call at http://github.com/klacke/yaws/blob/master/src/yaws_rpc.erl#L314 (as of http://github.com/klacke/yaws/commit/6144b4fe2d6f66a0f7be0ba7931f7ff5eda554be)
Comments
I asked about this on the erlang list - but no response - from any json hackers.
Anyway - It looked as if this was the right thing - but the link above seems dead.
What shall I do ?/klacke
Which link is dead? The JSON-RPC specification link works for me still.
I don't see any way to attach patches to this bug tracker, but my changed code looks like:
encode_handler_payload({response, ErlStruct}, ID, RpcType) -> StructStr = case RpcType of json -> json:encode({struct, [ {result, ErlStruct}, {id, ID}, {error, null}]}); haxe -> [$h, $x, $r | haxe:encode(ErlStruct)] end, {ok, StructStr}.I've also got a patch that allows returning { error, ErlStruct } to fill in the error field in json-rpc or return an exception in haxe (untested). From the look of the yaws_rpc module, soap and soap_dime don't pass through this path.
One further enhancement I might play with is trying to catch exceptions coming out of the rpc call, and turn them into error results, so the really dumb python json-rpc client I'm testing with stops barfing on Yaw's 400 error page when its expecting a JSON-RPC result. ^_^
Would it be useful if I were to fork the project for these changes, or post patches to a mailing list or something?
-
Currently yaws is not buildable with sinan or installable using faxien. Update the package to build and publish it to the recent erlware.org repository.
Comments
-
It is better if Yaws allows specifying both size and timeout when streaming contents. See:
http://osdir.com/ml/web.server.yaws.general/2007-02/msg00028.htmlComments
As I noted in my other comment, the "size" parameter to streaming doesn't make sense because HTTP 1.1 essentially disallows the use of the Content-Length header when employing chunked transfer encoding. So let me ask: why do you think you need the size parameter for streaming?
I have a new alternative streamcontent capability in my local repository that might work perfectly for Comet applications. I'm not going to provide any details at this time because I'm waiting to hear back from Klacke as to whether he finds the proposal acceptable before I push to github (but it might be a few days because I think he's on vacation or traveling or something at the moment).
-
In http://yaws.hyber.org/yman.yaws?page=yaws_api there's no document for streamcontent_with_size.
See:
http://github.com/klacke/yaws/blob/c3a8eb228d989fb8a9e7694817af80b2aa5f621b/src/yaws_server.erl
Comments
The streamcontent_with_size feature seems like an error to me, so maybe that's why it's not documented. For chunked transfer, which is what streamcontent provides, the HTTP spec (RFC2616) states that a Content-Length header must not be sent if the entity length and the transfer length do not match, which is always the case for chunked transfer. The spec also says that if a Transfer-Encoding header and a Content-Length header are both present, the latter must be ignored. See section 4.4 item 3 of RFC2616 http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.4.
I agree, weird feature - don't remember where it comes from.
-
the instructions for cloning and building from github should indicate the necessity to first pull in the needed prerequisites before building by running apt-get build-dep yaws (if ubuntu) - or otherwise list what they are - the errors on "make" really don't indicate much of utility to the user ...
Comments
Any chance you could copy the errors you got and attach them to this issue?
grantmichaels
Sun Aug 02 13:08:57 -0700 2009
| link
i'm not positive that the apt package management system would necessarily remove everything that it added when i needed to build-dep yaws because after i got it working i later added other erl-related packages ... i checked back in the Terminal log to see if it was still there, but it was not ... i should have cut and pasted, but at the time i wasn't planning on notifying anyone ... i saw your request for doing so on IRC, so I thought you might want to update the installation wiki on github specifically ... it's probably not that big of a deal after all, certainly not big enough to recreate the environment =) ...
Build deps for yaws are fairly close to those of erlang. Are you suggesting we should maintain a complete list - that's a pretty big and complicated job for all platforms. I'd rather like to ignore this request. Maintaining this for platforms like e.g all bsd's and linuxes is a huge job - that also get's invalidated as new versions of supported oses occur.
grantmichaels
Thu Aug 06 05:48:25 -0700 2009
| link
i certainly understand that and have no problem with your decision, and furthermore, the answer will still be available in the form of the closed request. Cheers.
-
Process dictionary causes problem when spawning processes
7 comments Created 5 months ago by ferdWhen spawning a new process from within a query to parallelize the few tasks that can be, the default first parameter (#arg) can be sent to the new process, but the yaws libraries won't be able to fetch all the information in it as it appears to be stored in the parent's process dictionary.
Data thus appears missing for no reason, unless when going in the sourceĀ to find out you have to copy the process dictionary to any spawned process in order to keep full functionality.
As far as I know, this is undocumented behavior, so either documenting it or correcting it could possibly help the few other people who will trip on that bug.
Comments
ngocdaothanh
Sun Aug 02 17:40:59 -0700 2009
| link
I think this is not a bug, but the use of process dictionary should be documented.
This is indeed true,yaws uses the process dict. It's fairly safe to bring along some of the dict entries to the new process and -re-putting them.
Agree - should be documented. Unclear where though ....
Steve - wasn't this something you rambled about some time ago - i.e. the ability to transfer the proc dict to another process through a call in yaws_api.erl ???
Yes, but unfortunately I haven't fixed it yet. I just cleared some other things I was working on so I'll tackle this next.
Would there be any problem to something a bit like:
new_spawn(Fun) -> L = get(), spawn(fun() -> [put(X,Y) || {X,Y} <- L], Fun() end).Or is there something complex to take care of? I remember doing something similar to the project I had when I actually needed it.
Each yaws process is created through proc_lib: calls, thus there are a few dict entries that should not be carried over to a new process. In particular $ancestors and $initial_call - apart from that the above code is in principle ok.
-
Problem 1: The 1st chunk is not sent (flushed) right away to the requesting browser
When a timeout, for example 1 minute, is specified (e.g. by {streamcontent_with_timeout, MimeType, FirstChunk, Timeout} in out/1) and the 2nd chunk is not sent within this time, then the 1st chunk will not sent right away to the requesting browser. The 1st chunk will be sent after 1 minute.
Problem 2: Timeout is reset to 30s
Even when infinity is specified, after sending the 2nd chunk, the timeout will be reset to 30s.
About the design of stream_loop_send:
The FlushStatus argument of stream_loop_send/3 has 3 states: flushed, unflushed, and a timeout value. This reminds me of the "authentication system that returns THREE STATES" problem here:
http://weblog.rubyonrails.org/2009/6/3/security-problem-with-authenticate_with_http_digest
Comments
Problem1. I can't reproduce - actually it seems to work just fine: This code:
out(_) ->
{streamcontent_with_timeout, "application/octet-stream", <<"kalle">>, 3000}.And then
[klacke@krom]~ > telnet krom 8000 Trying 127.0.1.1...
Connected to krom.
Escape character is '^]'.
GET /u.yawsHTTP/1.1 200 OK
Connection: close
Server: Yaws/1.84 Yet Another Web Server
Date: Thu, 06 Aug 2009 10:03:49 GMT
Content-Type: application/octet-streamkalle
Connection closed by foreign host.The "kalle" string get shipped immediately, and then after 3 secs, the connection
gets closed. Also looking at the code, it looks good. the FirstChunk should be
shipped directly.Problem2.
Yes, clearly a bug. Fixed, thanks.
-
In yaws_api, yaws_fcgi:call_fcgi_responder should be written yaws_cgi:call_fcgi_responder. There is no yaws_fcgi.erl.
Comments
brunorijsman
Tue Jul 21 04:59:35 -0700 2009
| link
This has been fixed.
-
I'm on Leopard with Yaws 1.84.
- Mount myappmod at / (in yaws.conf: appmods = </, myappmod>) so that it catches all request
- In myappmod:out/1, put({yaws, page}, Arg#arg.server_path) then return {page, Arg#arg.server_path}
Request a non-existing file, Yaws will freeze for about one minute and crash with something like this on the screen:
beam.smp(513,0xb01aa000) malloc: *** mmap(size=1140850688) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug beam.smp(513,0xb01aa000) malloc: *** mmap(size=1140850688) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug beam.smp(513,0xb01aa000) malloc: *** mmap(size=1140330496) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug beam.smp(513,0xb01aa000) malloc: *** mmap(size=1140330496) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 1140328500 bytes of memory (of type "old_heap").
Comments
It would save time and make things easier to fix if you submitted a small test case that duplicates the issue. (This goes for all bug reports.)
What's the purpose of the put() in step 2?
ngocdaothanh
Thu Jul 30 20:03:24 -0700 2009
| link
A simple example code is here:
http://rapidshare.com/files/261986777/pd.zipHowever, I could not reproduce the crash. Maybe because I have updated to the latest version from the GitHub repository.
I am writing a web framework for Yaws here:
http://github.com/ngocdaothanh/aleFor a request, I use the process dictionary to pass things from a layer to another, before filter -> action -> view -> layout etc.
Things in the process dictionary are designed to be in separate namespaces. Seeing that Yaws also use the process dictionary, I will avoid "yaws" for keys.
Thank you for your response to the bug report.
- Mount myappmod at / (in yaws.conf: appmods = </, myappmod>) so that it catches all request
-
"make docs" does not work on Mac OS X 10.5.7
4 comments Created 6 months ago by brunorijsman~/Documents/workspace/yaws> make docs ( cd doc && make docs ) yaws.tex
make[1]: yaws.tex: Command not found
make[1]: [yaws.dvi] Error 127
make: [docs] Error 2
Comments
I find yaws.tex in the old svn repository. Perhaps someone accidentally deleted it?
Hmm, I don't understand, do you mean that the yaws.tex file was deleted?
Anyway, It's certainly possible to build the docs on macosx provided all the
required doc tools are installed, latex2html, dvips, latex, etc.The Makefile could be improved though, so that it says something better if the tools aren't there.
You're right, yaws.tex is there. I was judging from the message show above that it was missing, but the error is really caused by trying to make yaws.ps where it's looking for the $(DVIPS) tool and can't find it.
-
server_options_test does not pass because of 'Date' header
3 comments Created 7 months ago by ngocdaothanhIn test/t2, I ran TEST=server_options_test make test and the test did not pass.
Checking the headers returned from Yaws, I see that there is a 'Date' header which is not matched by any app_test/server_options_recv/2.
An example list of headers returned from Yaws:
{http_response,{1,1},200,"OK"} {http_header,30,'Server',undefined,"Yaws/1.82 Yet Another Web Server"} {http_header,3,'Date',undefined,"Mon, 08 Jun 2009 06:21:34 GMT"} {http_header,34,'Allow',undefined,"GET, HEAD, OPTIONS, PUT, POST, DELETE"} {http_header,38,'Content-Length',undefined,"0"} http_eohShould the following 2 lines be added to app_test.erl?
server_options_recv(S, [{http_header,_,'Date',_,_}|_]=Hdrs) -> do_server_options_recv(S, Hdrs);Comments
-
Just wondering why this module isn't included in the Makefile. :)
(I thought of forking+changing+doing a pull request but there might be a valid reason for the module being left out hence opening an issue instead) :DavideComments
-
I'm getting strange characters when yaws displays the man pages. Had a quick look and I'm not sure what's going on. Using Firefox 3.0.10 on Ubuntu.
Picture:
http://ovik.net/~faah/man-error.pngComments
I bet it's your LESS flags. Try this.
export LESS=erX
man yaws
Ahhh .. you mean when yaws - the webserver - display the man pages. I though you meant the normal, linux man page (tty)
Anyway - it's a local issue at your end somehow. The man pages are produced
as:os:cmd("man " ++ Page ++ " | col -b -p -x");So, do that
3> Page = "yaws".
"yaws" 4> Data = os:cmd("man " ++ Page ++ " | col -b -p -x").If you get UTF-8 characters then - it's you're LOCALE or something.
Hmmm .... I looked further here. maybe it's wrong to invoke the man program in man.yaws. Maybe it would be better to invoke nroff -man instead.
Yeah you were right, the problem was my locale. It was UTF-8, when I changed it to latin-1 the page displays correctly. One way to fix it would be to simply:
Data = os:cmd("env LC_ALL=en_US.ISO-8859-1 man " ++ Page ++ " | col -b -p -x").
This fixed it for me. -
just checked out a clean version and ran ./configure; make
build output, using R13Bgcc -c -fPIC -g -O2 -I/usr/include/security -I/usr/include/pam -I"/usr/local/erlang/R13B/lib/erlang/usr/include" -I/usr/include/pam/ -DDYNAMIC_DRIVER setuid_drv.c
gcc -bundle -fPIC -flat_namespace -undefined suppress -o ../priv/lib/setuid_drv.so setuid_drv.o
gcc -c -g -O2 -I/usr/include/security -I/usr/include/pam -I"/usr/local/erlang/R13B/lib/erlang/usr/include" -I/usr/include/pam/ epam.c
gcc -o ../priv/epam epam.o -lpam
gcc -c -fPIC -g -O2 -I/usr/include/security -I/usr/include/pam -I"/usr/local/erlang/R13B/lib/erlang/usr/include" -I/usr/include/pam/ -DDYNAMIC_DRIVER yaws_sendfile_drv.c
gcc -c -fPIC -g -O2 -I/usr/include/security -I/usr/include/pam -I"/usr/local/erlang/R13B/lib/erlang/usr/include" -I/usr/include/pam/ hashtable.c
gcc -bundle -fPIC -flat_namespace -undefined suppress -o ../priv/lib/yaws_sendfile_drv.so yaws_sendfile_drv.o hashtable.o
. ../vsn.mk; \cat yaws_generated.template | \ ../scripts/Subst %VSN% 1.81 | \ ../scripts/Subst %VARDIR% /Users/dbudworth/yaws/var | \ ../scripts/Subst %localinstall% true | \ ../scripts/Subst %ETCDIR% /Users/dbudworth/yaws/etc > yaws_generated.erlset -x; <br/>
if [ true = "true" ]; then \ echo "-define(HAVE_SENDFILE, true)." > yaws_configure.hrl; \ else touch yaws_configure.hrl; fi- '[' true = true ']'
- echo '-define(HAVE_SENDFILE, true).'
"/usr/local/erlang/current/bin/erlc" -W -pa ../../yaws -I ../include -o ../ebin yaws.erl
"/usr/local/erlang/current/bin/erlc" -W -pa ../../yaws -I ../include -o ../ebin yaws_app.erl
"/usr/local/erlang/current/bin/erlc" -W -pa ../../yaws -I ../include -o ../ebin yaws_ticker.erl
"/usr/local/erlang/current/bin/erlc" -W -pa ../../yaws -I ../include -o ../ebin yaws_config.erl
./yaws_config.erl:1145: field extra_cgi_vars undefined in record sconf
make[1]: [../ebin/yaws_config.beam] Error 1
make: [all] Error 1
Comments
wow, that came out poorly formatted. Basically, I was just saying that it looks like an incomplete change was comitted
I'm getting the same problem. You can checkout an old commit until it gets fixed.
This worked for me: git checkout -b branch-name b732bd1
-
(
logdir = /var/log/yawsfile /var/log/yaws/pt.foothold.ru:8080.access is empty (((
virt server pt.foothold.ru
port = 8080 listen = 0.0.0.0 docroot = /var/www/html/sub-domain/foothold.ru/pt.ru dir_listings = false allowed_scripts = cgi,yaws access_log = true deflate = true dav = false
Comments
-
Yaws should serve static files for appmods
7 comments Created 8 months ago by ngocdaothanhIf there are:
A static file at path /xxx An appmod also mounted at path /xxx Currently Yaws always forward requests to /xxx to the appmod. This is not desirable for application programmers.More information:
http://wiki.github.com/klacke/yaws/root-appmod
Comments
Well - you can't have both. Either an appmod is responsible for all data below /xxx or it isn't.
Steve Vinoski suggested:
Isn't the answer to issue #5 to just have a "for everything else"
out/1 function in the appmod that just does a {page, ...} to tell Yaws
to send the file instead?And - I think this will work fine.
ngocdaothanh
Wed Apr 29 18:01:14 -0700 2009
| link
Either an appmod is responsible for all data below /xxx or it isn't.
I mean: (1) if the path is /xxx/yyy/zzz, Yaws should pass the request to the appmod, (2) if the path is exactly /xxx, Yaws should serve the static file.
Currently, when running on Yaws the Nitrogen web framework (http://nitrogenproject.com/) must use the path /web/yyy/zzz for all dynamic contents. And the /web prefix is ugly.
Regards.
Ok,
Have you tried the {page, Page} suggestion for the top level page ?
ngocdaothanh
Fri May 22 12:37:38 -0700 2009
| link
{page, Page} works: http://groups.google.com/group/nitrogenweb/browse_thread/thread/c2ce70f696b77c9e
Thanks a lot.
Since {page, Page} works as expected, closing this issue.
OTOH, - and I've my self come across the very same issue discussed in the google group mentioned above. One possible - and light weight solution could be to assign an exception list to an appmod. That way it would be possible to have an appmod for / but let everything under e.g. /static be directly served by yaws.
?
-
If the ebin directory that is specified in the yaws.conf file has not had a
beam file (untested with other file types) placed in it, the server will
fail to launch at the command line stating that it expects a directory at
the ebin_dir line. Once a beam has been placed in this directory and the
server started, it does not seem to mind if the file is removed.This was noticed on Ubuntu Gutsy, package install of erlang, source install
of yaws 1.76.Comments
-
I attempted to turn caching off by specifying "max_num_cached_files = 0" in
yaws.conf, but after the first page access, beam uses 100% CPU, and there
is hundreds of messages like below added to the report.log:=INFO REPORT==== 3-Aug-2008::21:55:01 === Max size cached bytes reached for server "ltop"
Comments
-
testing the issue system
Comments
Indeed, and do you also get en email now that I comment your comment ?





Need more info, I don't understand exactly what the problem is.
With my normal server configuration:
<server localhost>
</server>
Using the appmod file:
$ cat conductor.erl
-module(conductor).
-include("yaws_api.hrl").
-export([out/1]).
out(A) -> {yssi, "test.yaws"}.
And in the docroot folder I have:
$ cat test.yaws
<erl> out(A) -> {html, "this is test.yaws in docroot"}. </erl>
Calling the appmod gives me no results from the yssi:
$ curl http://127.0.0.1:8080/
$
However if I changes
appmods = </, conductor> to appmods = <myappmod, conductor>
And calls the appmod, the yssi works:
$ curl http://127.0.0.1:8080/myappmod
this is test.yaws in docroot
$
So in short returning {yssi, Filename} values from an appmod that uses / as the trigger does not work.
Thanks, good report now. I'll try to make time to have a look at this.
I had a look at this and this is not easy to fix, the return value {yssi, "test.yaws"}
will turn into appmod processing once again since there is an appmod at top.
The code was never written for this case to work.
I'd prefer to not fix this.
Sorry