On 2012-07-24 12:22, Christopher Faulet
Thank you Steve and Christopher for your support.
On 23/07/2012 23:33, Steve Vinoski wrote:
I will try to create a simple test case to reproduce this by stripping
down our application code. I will try to make this just after dinner.
Will keep you informed of my progress on this.
Ok, I created an application that reproduce the problem. I attached it to
this email. Here are the steps to test it:
1- Extract to a folder
2- Go in the `yaws-pared-down` folder just extracted and do in a shell `sh
run-pared-down.sh`. This script will call `rebar compile` to compile the two
modules (one gen_server that starts embedded yaws, and one handler that will
handle http requests) and will start the application.
3- The script assumes that Yaws is installed in `/usr/local/lib/yaws`, you
can of course customize the path in `rebar.config` and in
4- The Yaws server will listen to `http://localhost:8080`
5- In another shell, do `curl -u user:password -X GET
http://localhost:8080`. This will return a plain text response. If you see
the same behavior as me, it would output `Credentials were wrong:
Hope you can reproduce the error with this. I will try to find the culprit,
or at least more informations, tomorrow morning.
Thanks for the test case.
I tried to use it to do some git bisecting to see if I could narrow
down the changes causing the problem, but got to a point between yaws
1.89 and 1.90 that your test program could no longer start yaws
correctly. I manually tried a number of different builds but couldn't
clearly identify what changes might be causing the failure to start
yaws, so I looked at your test program and found that the way it
starts yaws in embedded mode isn't what I expected to see. In
particular it uses application:start(yaws), which might seem intuitive
but it fails to account for properly setting global and server
configuration to allow yaws to start correctly.
I changed your test to use the yaws:start_embedded/3 function described here:
using the same settings you were putting into your gconf and sconf
records (see the diff below). With that change, I can't make it fail
on any version of yaws -- it works on 1.89 and 1.90 with R14B04 as
well as on the current master with R15B01.
hope this helps,
About basic authentication, I found a little bug in
yaws_server:is_auth/2. I attached a patch for Yaws-1.90.
But as Steve said, the way Yaws is started in your test is not
"conventional". You should use yaws:start_embedded/1,2,3,4 to start
yaws, and yaws:add_server/2 to add virtual servers after its start.
These functions take proplists as argument and create corresponding records.
Nevertheless, to create #gconf and #sconf records, you should use,
respectively, yaws:create_gconf/2 and yaws:create_sconf/2. Finally,
yaws_api:setconf/2 should be used to update configuration. All these
functions are backward compatible between versions and using them, you
have not need to know the records definition.
#gconf and #sconf records are updated from time to time. In these cases,
all modules using one of them must be recompiled. So, when it is
possible, it is a good idea to not depend on them. And you must be very
careful when you update them. Note also that yaws_config api is private,
you are not supposed to use it.
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
Erlyaws-list mailing list
First of all, I tested the changes Steve made to my test program and
indeed, it make it work as expected. I then ported the changes to
the application and it works also.
You are both right, our way of starting Yaws is not conventional and
I'm in the process of updating our application to take into account
both of your comments. We will use the way you describe to start the
embedded Yaws processes. Furthermore, we will also make sure to not
use the yaws_config module and to use the appropriate functions to
build the #gconf and #sconf records. Didn't know they were private
in the first place.
As for the bug you found Christopher, I'm glad the it's already
fixed in the master branch.
Again, thank you for your support and have a great day. If I have
further questions, I will post them in another thread.