Menu
▾
▴
erlyaws-list — Discussions regarding the erlang/yaws Web server
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(18) |
Nov
(27) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(34) |
Mar
(19) |
Apr
(14) |
May
(40) |
Jun
(18) |
Jul
(20) |
Aug
(9) |
Sep
(32) |
Oct
(11) |
Nov
(25) |
Dec
(36) |
| 2004 |
Jan
(12) |
Feb
(41) |
Mar
(67) |
Apr
(16) |
May
(36) |
Jun
(26) |
Jul
(19) |
Aug
(28) |
Sep
(5) |
Oct
(11) |
Nov
(9) |
Dec
(45) |
| 2005 |
Jan
(14) |
Feb
(12) |
Mar
(22) |
Apr
(58) |
May
(41) |
Jun
(19) |
Jul
(15) |
Aug
(9) |
Sep
(16) |
Oct
(6) |
Nov
(35) |
Dec
(33) |
| 2006 |
Jan
(6) |
Feb
(39) |
Mar
(17) |
Apr
(29) |
May
(12) |
Jun
(85) |
Jul
(43) |
Aug
(115) |
Sep
(103) |
Oct
(43) |
Nov
(100) |
Dec
(45) |
| 2007 |
Jan
(66) |
Feb
(85) |
Mar
(85) |
Apr
(72) |
May
(28) |
Jun
(12) |
Jul
(2) |
Aug
(4) |
Sep
(46) |
Oct
(38) |
Nov
(38) |
Dec
(50) |
| 2008 |
Jan
(27) |
Feb
(26) |
Mar
(24) |
Apr
(51) |
May
(42) |
Jun
(28) |
Jul
(20) |
Aug
(45) |
Sep
(28) |
Oct
(21) |
Nov
(50) |
Dec
(51) |
| 2009 |
Jan
(40) |
Feb
(66) |
Mar
(42) |
Apr
(33) |
May
(10) |
Jun
(41) |
Jul
(72) |
Aug
(52) |
Sep
(50) |
Oct
(32) |
Nov
(28) |
Dec
(74) |
| 2010 |
Jan
(30) |
Feb
(45) |
Mar
(40) |
Apr
(47) |
May
(54) |
Jun
(19) |
Jul
(48) |
Aug
(58) |
Sep
(50) |
Oct
(31) |
Nov
(7) |
Dec
(20) |
| 2011 |
Jan
(18) |
Feb
(20) |
Mar
(43) |
Apr
(52) |
May
(61) |
Jun
(55) |
Jul
(25) |
Aug
(5) |
Sep
(33) |
Oct
(32) |
Nov
(10) |
Dec
(16) |
| 2012 |
Jan
(25) |
Feb
(46) |
Mar
(29) |
Apr
(28) |
May
(13) |
Jun
(40) |
Jul
(13) |
Aug
(21) |
Sep
(3) |
Oct
(32) |
Nov
(25) |
Dec
(14) |
| 2013 |
Jan
(3) |
Feb
(5) |
Mar
(25) |
Apr
(14) |
May
(15) |
Jun
(18) |
Jul
(21) |
Aug
|
Sep
(17) |
Oct
(1) |
Nov
(15) |
Dec
(16) |
| 2014 |
Jan
(5) |
Feb
(6) |
Mar
(18) |
Apr
(25) |
May
(22) |
Jun
(17) |
Jul
(9) |
Aug
(6) |
Sep
(12) |
Oct
(5) |
Nov
(18) |
Dec
(4) |
| 2015 |
Jan
|
Feb
(20) |
Mar
(3) |
Apr
(21) |
May
(2) |
Jun
(6) |
Jul
(5) |
Aug
(10) |
Sep
(1) |
Oct
(9) |
Nov
(6) |
Dec
(5) |
| 2016 |
Jan
(4) |
Feb
(5) |
Mar
(26) |
Apr
(8) |
May
(16) |
Jun
(20) |
Jul
(1) |
Aug
(5) |
Sep
(8) |
Oct
(4) |
Nov
(2) |
Dec
(10) |
| 2017 |
Jan
(31) |
Feb
(11) |
Mar
(3) |
Apr
(10) |
May
(4) |
Jun
(6) |
Jul
(9) |
Aug
(8) |
Sep
|
Oct
(8) |
Nov
(10) |
Dec
(6) |
| 2018 |
Jan
(6) |
Feb
(5) |
Mar
(1) |
Apr
(1) |
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
(8) |
Oct
(2) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(5) |
Mar
|
Apr
(4) |
May
|
Jun
(13) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
(7) |
Jul
(6) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(2) |
| 2022 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(1) |
Aug
(7) |
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2023 |
Jan
|
Feb
(5) |
Mar
|
Apr
(5) |
May
(12) |
Jun
|
Jul
|
Aug
(3) |
Sep
(2) |
Oct
|
Nov
(7) |
Dec
|
| 2024 |
Jan
|
Feb
(6) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(1) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Per A. (perander) <per...@ci...> - 2024-08-06 15:38:33
|
Steve Vinoski via Erlyaws-list <erl...@li...> on Sunday, July 14, 2024 14:16: > > I've released Yaws 2.2.0, details here: > > https://github.com/erlyaws/yaws/releases/tag/yaws-2.2.0 > > Thanks to all the contributors, especially Per Andersson. My pleasure. :) Thanks for your continued effort Steve and big thanks to all contributors!! -- Per |
|
From: Steve V. <vi...@ie...> - 2024-07-14 12:16:36
|
I've released Yaws 2.2.0, details here: https://github.com/erlyaws/yaws/releases/tag/yaws-2.2.0 Thanks to all the contributors, especially Per Andersson. --steve |
|
From: Steve V. <vi...@ie...> - 2024-07-10 15:47:02
|
There's nothing in yaws code related to this, so this has to be coming from some external entity. If you're not interested in supporting CGI, you might try setting allowed_scripts = [yaws] thereby disabling dispatching for any PHP, CGI, or FastCGI URLs. If the log shows these requests coming from the same client address, maybe you can block them at a firewall or such? --steve On Sat, Jun 29, 2024 at 4:41 PM Bob Paddock <bob...@gm...> wrote: > I set YAWS up on a new virtual host. > > Can anyone shed light on why I'm seeing this every few minutes, and > have been for a few weeks now, in the YAWS report.log?: > > spawn: Could not cd to /home/web/Sites/WWW/example.com/cgi-bin/luci/;stok= > > or > > spawn: Could not cd to /home/web/Sites/WWW/example.com/cgi-bin > > there is no cgi-bin directory so I expect that is why the spawn fails. > > There is nothing other than an index.html page saying "returning soon" > at that site. > > What is exactly initiating this over and over? > > Inbound Attack or I just have something configured wrong on this new host? > > I never saw this on the old virtual host, which had a different IP address. > > The only other thing that appears in the report.log is the occasional > SSL SNI IP address mismatch kind of attacks. > > > If this is an attack kind of issue what are your suggestions on dealing > with it? > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
|
From: Bob P. <bob...@gm...> - 2024-06-29 20:40:47
|
I set YAWS up on a new virtual host. Can anyone shed light on why I'm seeing this every few minutes, and have been for a few weeks now, in the YAWS report.log?: spawn: Could not cd to /home/web/Sites/WWW/example.com/cgi-bin/luci/;stok= or spawn: Could not cd to /home/web/Sites/WWW/example.com/cgi-bin there is no cgi-bin directory so I expect that is why the spawn fails. There is nothing other than an index.html page saying "returning soon" at that site. What is exactly initiating this over and over? Inbound Attack or I just have something configured wrong on this new host? I never saw this on the old virtual host, which had a different IP address. The only other thing that appears in the report.log is the occasional SSL SNI IP address mismatch kind of attacks. If this is an attack kind of issue what are your suggestions on dealing with it? |
|
From: Bob P. <bob...@gm...> - 2024-05-28 16:12:03
|
On Wed, Apr 3, 2024 at 6:09 AM Per Andersson (perander) via Erlyaws-list <erl...@li...> wrote: > I have generated a static mirror of the Yaws Web Page previously hosted > on a Yaws instance on yaws.hyber.org. > > The static web page is hosted on github pages at the following URL > > https://erlyaws.github.io/ > > Ideally it should be hosted on a running Yaws instance I've been serving the git web page master from https://github.com/erlyaws/yaws/tree/master/www for at least a couple of years. The certificate errors that someone reported to me have been fixed, now that I've moved to a working virtual host. https://yetanotherwebserver.net https://www.yetanotherwebserver.net https://yetanotherwebserver.com https://www.yetanotherwebserver.com all end up in the same place. All the cool yaws domains have been taken. :-( What is the best approach for me to start serving the updated version? Point at erlyaws/erlyaws.github.io and rename things back locally so the examples work? Run the gh script on git master clone and make a pull request? Only the set persistent cookie example is not working one what is being served now. Anyone know why? Anyone have the awful cookie warning yaws code at hand that the EU says we need? In checking links I noted that the erlyaws.github.io/ 'man' pages are returning 404 errors. |
|
From: Java H. <jav...@gm...> - 2024-04-06 23:00:08
|
Thank you Per for the effort. this looks really good. Στις Τετ 3 Απρ 2024 στις 12:09 μ.μ., ο/η Per Andersson (perander) via Erlyaws-list <erl...@li...> έγραψε: > Hi all! > > I have generated a static mirror of the Yaws Web Page previously hosted > on a Yaws instance on yaws.hyber.org. > > The static web page is hosted on github pages at the following URL > > https://erlyaws.github.io/ > > Ideally it should be hosted on a running Yaws instance, but that is a > later project. At least the old Yaws Web Page contents are (mostly) > available online, even though it is not dynamic at all. > > > -- > Per > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
|
From: Per A. (perander) <per...@ci...> - 2024-04-03 10:09:03
|
Hi all! I have generated a static mirror of the Yaws Web Page previously hosted on a Yaws instance on yaws.hyber.org. The static web page is hosted on github pages at the following URL https://erlyaws.github.io/ Ideally it should be hosted on a running Yaws instance, but that is a later project. At least the old Yaws Web Page contents are (mostly) available online, even though it is not dynamic at all. -- Per |
|
From: Steve V. <vi...@ie...> - 2024-02-26 00:25:01
|
Thanks for the info. What operating system and version is this? I see a list of obsolete macros at the link below; I'll have to go through it. https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html But if the automake build system wasn't working, believe me, I would have heard about it loudly from a number of users. The fact that some macros are deprecated doesn't mean they no longer work. Note that at github, actions to verify Yaws commits automatically run automake builds on ubuntu-20.04, and those builds work fine. I also do automake builds manually on macOS Sonoma 14.3.1 with autoconf 2.69 and automake 1.16.5, and they too work fine. If you're building in a git clone, and you already did some rebar3 builds there but want to use automake instead, you should be sure to clean everything first: git clean -xdf autoreconf -fi ./configure --steve On Sun, Feb 25, 2024 at 6:10 PM Bob Paddock <bob...@gm...> wrote: > > I'm not aware of any obsolete macros it contains, since it's generated > from configure.ac. Can you provide more details about what version of > automake you're using and what problems you see? > > > autoconf (GNU Autoconf) 2.72 > automake (GNU automake) 1.16.5 > > > autoconf > configure.ac:12: warning: The macro 'AC_CANONICAL_SYSTEM' is obsolete. > configure.ac:12: You should run autoupdate. > ./lib/autoconf/general.m4:2081: AC_CANONICAL_SYSTEM is expanded from... > configure.ac:12: the top level > configure.ac:32: warning: The macro 'AC_PROG_GCC_TRADITIONAL' is obsolete. > configure.ac:32: You should run autoupdate. > ./lib/autoconf/c.m4:1676: AC_PROG_GCC_TRADITIONAL is expanded from... > configure.ac:32: the top level > configure.ac:50: warning: The macro 'AC_HELP_STRING' is obsolete. > configure.ac:50: You should run autoupdate. > ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from... > configure.ac:50: the top level > configure.ac:74: warning: The macro 'AC_HELP_STRING' is obsolete. > configure.ac:74: You should run autoupdate. > ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from... > configure.ac:74: the top level > configure.ac:139: warning: The macro 'AC_HELP_STRING' is obsolete. > configure.ac:139: You should run autoupdate. > ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from... > configure.ac:139: the top level > configure.ac:16: error: possibly undefined macro: AM_INIT_AUTOMAKE > If this token and others are legitimate, please use > m4_pattern_allow. > See the Autoconf documentation. > configure.ac:27: error: possibly undefined macro: AM_SILENT_RULES > configure.ac:34: error: possibly undefined macro: AC_PROG_LD > configure.ac:40: error: possibly undefined macro: AM_DISABLE_STATIC > configure.ac:41: error: possibly undefined macro: AM_ENABLE_SHARED > configure.ac:42: error: possibly undefined macro: AM_PROG_LIBTOOL > configure.ac:76: error: possibly undefined macro: AM_CONDITIONAL > configure.ac:155: error: possibly undefined macro: AC_MSG_ERROR > > Running autoupdate as instructed above: > > autoupdate > configure.ac:32: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use > AC_PROG_CC > > > # ./configure > configure: error: cannot find required auxiliary files: install-sh > config.guess config.sub > > # aclocal > [No Errors with that] > > autoheader > autoheader-2.72: error: error: AC_CONFIG_HEADERS not found in configure.ac > > # automake --force-missing --add-missing > > configure.ac:28: installing 'ac-aux/ar-lib' > configure.ac:28: installing 'ac-aux/compile' > configure.ac:12: installing 'ac-aux/config.guess' > configure.ac:12: installing 'ac-aux/config.sub' > configure.ac:16: installing 'ac-aux/install-sh' > configure.ac:16: installing 'ac-aux/missing' > c_src/Makefile.am: installing 'ac-aux/depcomp' > > That then makes a ./configure that is broken. > > Starts with > > autoconf > configure.ac:32: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use > AC_PROG_CC > configure.ac:35: warning: ac_ext=c > configure.ac:35: ac_cpp='$CPP $CPPFLAGS' > > then really long spew of code ending with: > > configure.ac:35: case $cross_compiling:$ac_tool_warned in > configure.ac:35: yes: is m4_require'd but not m4_defun'd > > It appears that it is trying to execute the label 'yes' from looking > at the code. > > ./lib/autoconf/programs.m4:189: _AC_TOOL_WARN is expanded from... > ./lib/autoconf/programs.m4:221: AC_CHECK_TOOL is expanded from... > ./lib/autoconf/c.m4:460: AC_PROG_CC is expanded from... > configure.ac:35: the top level > configure.ac:37: warning: The macro 'AC_PROG_LD' is obsolete. > configure.ac:37: You should run autoupdate. > m4/libtool.m4:3348: AC_PROG_LD is expanded from... > configure.ac:37: the top level > configure.ac:43: warning: The macro 'AM_DISABLE_STATIC' is obsolete. > configure.ac:43: You should run autoupdate. > m4/ltoptions.m4:260: AM_DISABLE_STATIC is expanded from... > configure.ac:43: the top level > configure.ac:44: warning: The macro 'AM_ENABLE_SHARED' is obsolete. > configure.ac:44: You should run autoupdate. > m4/ltoptions.m4:205: AM_ENABLE_SHARED is expanded from... > configure.ac:44: the top level > configure.ac:45: warning: The macro 'AM_PROG_LIBTOOL' is obsolete. > configure.ac:45: You should run autoupdate. > m4/libtool.m4:100: AM_PROG_LIBTOOL is expanded from... > configure.ac:45: the top level > > Running autoupdate/autoconf again gets a ./configure that at least > starts to do something then dies at 'yes'. 'yes' is a label not code. > > # ./configure > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... x86_64-pc-linux-gnu > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a race-free mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking for gawk... (cached) gawk > checking whether make supports nested variables... (cached) yes > checking whether make supports the include directive... yes (GNU style) > checking for gcc... gcc > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether the compiler supports GNU C... yes > checking whether gcc accepts -g... yes > checking for gcc option to enable C11 features... none needed > checking whether gcc understands -c and -o together... yes > checking dependency style of gcc... gcc3 > checking for ar... ar > checking the archiver (ar) interface... ar > checking for gcc... (cached) gcc > checking whether the compiler supports GNU C... (cached) yes > checking whether gcc accepts -g... (cached) yes > checking for gcc option to enable C11 features... (cached) none needed > checking whether gcc understands -c and -o together... (cached) yes > checking dependency style of gcc... (cached) gcc3 > ./configure: line 6153: syntax error near unexpected token `newline' > ./configure: line 6153: `yes:' > > This is the code around 6153: > > > if test "x$ac_ct_CC" = x; then > CC="" > else > case $cross_compiling:$ac_tool_warned in > yes: > > { printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: using cross > tools not prefixed with host triplet" >&5 > printf "%s\n" "$as_me: WARNING: using cross tools not prefixed with > host triplet" >&2;} > ac_tool_warned=yes ;; > esac > CC=$ac_ct_CC > fi > else > CC="$ac_cv_prog_CC" > fi > |
|
From: Bob P. <bob...@gm...> - 2024-02-25 23:10:36
|
> I'm not aware of any obsolete macros it contains, since it's generated from configure.ac. Can you provide more details about what version of automake you're using and what problems you see?
autoconf (GNU Autoconf) 2.72
automake (GNU automake) 1.16.5
autoconf
configure.ac:12: warning: The macro 'AC_CANONICAL_SYSTEM' is obsolete.
configure.ac:12: You should run autoupdate.
./lib/autoconf/general.m4:2081: AC_CANONICAL_SYSTEM is expanded from...
configure.ac:12: the top level
configure.ac:32: warning: The macro 'AC_PROG_GCC_TRADITIONAL' is obsolete.
configure.ac:32: You should run autoupdate.
./lib/autoconf/c.m4:1676: AC_PROG_GCC_TRADITIONAL is expanded from...
configure.ac:32: the top level
configure.ac:50: warning: The macro 'AC_HELP_STRING' is obsolete.
configure.ac:50: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:50: the top level
configure.ac:74: warning: The macro 'AC_HELP_STRING' is obsolete.
configure.ac:74: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:74: the top level
configure.ac:139: warning: The macro 'AC_HELP_STRING' is obsolete.
configure.ac:139: You should run autoupdate.
./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
configure.ac:139: the top level
configure.ac:16: error: possibly undefined macro: AM_INIT_AUTOMAKE
If this token and others are legitimate, please use
m4_pattern_allow.
See the Autoconf documentation.
configure.ac:27: error: possibly undefined macro: AM_SILENT_RULES
configure.ac:34: error: possibly undefined macro: AC_PROG_LD
configure.ac:40: error: possibly undefined macro: AM_DISABLE_STATIC
configure.ac:41: error: possibly undefined macro: AM_ENABLE_SHARED
configure.ac:42: error: possibly undefined macro: AM_PROG_LIBTOOL
configure.ac:76: error: possibly undefined macro: AM_CONDITIONAL
configure.ac:155: error: possibly undefined macro: AC_MSG_ERROR
Running autoupdate as instructed above:
autoupdate
configure.ac:32: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use AC_PROG_CC
# ./configure
configure: error: cannot find required auxiliary files: install-sh
config.guess config.sub
# aclocal
[No Errors with that]
autoheader
autoheader-2.72: error: error: AC_CONFIG_HEADERS not found in configure.ac
# automake --force-missing --add-missing
configure.ac:28: installing 'ac-aux/ar-lib'
configure.ac:28: installing 'ac-aux/compile'
configure.ac:12: installing 'ac-aux/config.guess'
configure.ac:12: installing 'ac-aux/config.sub'
configure.ac:16: installing 'ac-aux/install-sh'
configure.ac:16: installing 'ac-aux/missing'
c_src/Makefile.am: installing 'ac-aux/depcomp'
That then makes a ./configure that is broken.
Starts with
autoconf
configure.ac:32: warning: AC_PROG_GCC_TRADITIONAL is obsolete; use
AC_PROG_CC
configure.ac:35: warning: ac_ext=c
configure.ac:35: ac_cpp='$CPP $CPPFLAGS'
then really long spew of code ending with:
configure.ac:35: case $cross_compiling:$ac_tool_warned in
configure.ac:35: yes: is m4_require'd but not m4_defun'd
It appears that it is trying to execute the label 'yes' from looking
at the code.
./lib/autoconf/programs.m4:189: _AC_TOOL_WARN is expanded from...
./lib/autoconf/programs.m4:221: AC_CHECK_TOOL is expanded from...
./lib/autoconf/c.m4:460: AC_PROG_CC is expanded from...
configure.ac:35: the top level
configure.ac:37: warning: The macro 'AC_PROG_LD' is obsolete.
configure.ac:37: You should run autoupdate.
m4/libtool.m4:3348: AC_PROG_LD is expanded from...
configure.ac:37: the top level
configure.ac:43: warning: The macro 'AM_DISABLE_STATIC' is obsolete.
configure.ac:43: You should run autoupdate.
m4/ltoptions.m4:260: AM_DISABLE_STATIC is expanded from...
configure.ac:43: the top level
configure.ac:44: warning: The macro 'AM_ENABLE_SHARED' is obsolete.
configure.ac:44: You should run autoupdate.
m4/ltoptions.m4:205: AM_ENABLE_SHARED is expanded from...
configure.ac:44: the top level
configure.ac:45: warning: The macro 'AM_PROG_LIBTOOL' is obsolete.
configure.ac:45: You should run autoupdate.
m4/libtool.m4:100: AM_PROG_LIBTOOL is expanded from...
configure.ac:45: the top level
Running autoupdate/autoconf again gets a ./configure that at least
starts to do something then dies at 'yes'. 'yes' is a label not code.
# ./configure
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gawk... (cached) gawk
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for gcc... (cached) gcc
checking whether the compiler supports GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to enable C11 features... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
./configure: line 6153: syntax error near unexpected token `newline'
./configure: line 6153: `yes:'
This is the code around 6153:
if test "x$ac_ct_CC" = x; then
CC=""
else
case $cross_compiling:$ac_tool_warned in
yes:
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: WARNING: using cross
tools not prefixed with host triplet" >&5
printf "%s\n" "$as_me: WARNING: using cross tools not prefixed with
host triplet" >&2;}
ac_tool_warned=yes ;;
esac
CC=$ac_ct_CC
fi
else
CC="$ac_cv_prog_CC"
fi
|
|
From: Bob P. <bob...@gm...> - 2024-02-25 22:40:39
|
On Sun, Feb 25, 2024 at 10:07 AM Steve Vinoski <vi...@ie...> wrote: >> What am I doing wrong or what am I missing? > Since it says it installs the yaws script under ./bin, if I run this command from my terminal shell, it works: > $ ./bin/yaws -pa ./_build/default/lib/yaws/ebin Yes, that works for me. > That said, I think the "real" way to use rebar3 here would be to use it to create a release, but I haven't tried that in a long time so I'm not even sure it works. When I use ./configure method I end up with a yaws that just works, it doesn't really matter where I put it when I use the configure prefix/install etc. I was expecting the same here, that yaws would just run. > Just to be clear, the ./configure script is part of the automake build system and so should not be used with rebar3. Yes, I realize they are independent. I'll address the configure issue in its own thread. |
|
From: Steve V. <vi...@ie...> - 2024-02-25 15:07:51
|
On Sat, Feb 24, 2024 at 11:16 AM Bob Paddock <bob...@gm...> wrote:
> On Mon, Feb 19, 2024 at 3:14 PM Steve Vinoski via Erlyaws-list
> <erl...@li...> wrote:
>
> > ... I've finally merged the rebar3-support branch to master.
>
> From when I use 'rebar3 shell', everything builds and comes up running
> on the default 0.0.0.0, all good.
>
> Alas when I try to run the built yaws outside of the shell I get this
> error:
>
> yaws/bin # ./yaws
> Erlang/OTP 23 [erts-11.1.8] [source] [64-bit] [smp:20:3] [ds:20:3:10]
> [async-threads:1] [hipe]
>
> {"init terminating in
>
> do_boot",{undef,[{yaws,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
> init terminating in do_boot
> ({undef,[{yaws,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
>
> Crash dump is being written to: erl_crash.dump...done
>
> What am I doing wrong or what am I missing?
>
When you build with rebar3, all the beam files are generated under the
_build directory. You can see this by running "rebar3 shell" and then
asking where the yaws module is. For my build, for example, where my yaws
source dir is in /usr/local/src/yaws:
$ rebar3 shell
===> Verifying dependencies...
--- Installed yaws script at /usr/local/src/yaws/bin
--- Will not overwrite /usr/local/src/yaws/etc/yaws/yaws.conf
===> Analyzing applications...
===> Compiling yaws
...
===> Booted yaws
1> code:which(yaws).
"/usr/local/src/yaws/_build/default/lib/yaws/ebin/yaws.beam"
Since it says it installs the yaws script under ./bin, if I run this
command from my terminal shell, it works:
$ ./bin/yaws -pa ./_build/default/lib/yaws/ebin
That said, I think the "real" way to use rebar3 here would be to use it to
create a release, but I haven't tried that in a long time so I'm not even
sure it works.
Also the ./configure method is broken due to the use of many obsolete
> macros.
> I spent a couple of hours trying to get that beat into submission and
> still ended up with build errors that I could not figure out how to
> fix.
> It is 2024 and this is the best build system we can come up with (not
> picking on yaws, picking on the state of the world build systems)?
>
Just to be clear, the ./configure script is part of the automake build
system and so should not be used with rebar3. That said, I'm not aware of
any obsolete macros it contains, since it's generated from configure.ac.
Can you provide more details about what version of automake you're using
and what problems you see?
As far as rebar3 goes, it's been the standard Erlang build system for years
at this point. Yaws has had support for it since 2016, but it was always
until recently isolated on the rebar3-support branch because I never could
get common-test to work correctly under rebar3. It still doesn't work but I
merged it anyway at the request of rebar3-support branch users, who were
tired of always lagging behind changes on the master branch. Now that both
build systems are on master, both will be maintained at the same level.
--steve
|
|
From: Bob P. <bob...@gm...> - 2024-02-24 16:16:35
|
On Mon, Feb 19, 2024 at 3:14 PM Steve Vinoski via Erlyaws-list
<erl...@li...> wrote:
> ... I've finally merged the rebar3-support branch to master.
>From when I use 'rebar3 shell', everything builds and comes up running
on the default 0.0.0.0, all good.
Alas when I try to run the built yaws outside of the shell I get this error:
yaws/bin # ./yaws
Erlang/OTP 23 [erts-11.1.8] [source] [64-bit] [smp:20:3] [ds:20:3:10]
[async-threads:1] [hipe]
{"init terminating in
do_boot",{undef,[{yaws,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]}}
init terminating in do_boot
({undef,[{yaws,start,[],[]},{init,start_em,1,[]},{init,do_boot,3,[]}]})
Crash dump is being written to: erl_crash.dump...done
What am I doing wrong or what am I missing?
Also the ./configure method is broken due to the use of many obsolete macros.
I spent a couple of hours trying to get that beat into submission and
still ended up with build errors that I could not figure out how to
fix.
It is 2024 and this is the best build system we can come up with (not
picking on yaws, picking on the state of the world build systems)?
|
|
From: Steve V. <vi...@ie...> - 2024-02-19 20:14:14
|
As you probably know, Yaws has been supporting rebar3 on its rebar3-support branch since 2016. Due to the prompting from user Julius Andrikonis with his recent pull request #480 (https://github.com/erlyaws/yaws/pull/480), I've finally merged the rebar3-support branch to master. Running tests with rebar3 has been a problem all these years, and it's still a problem. But I merged rebar3-support anyway, since having the test support didn't seem to be an issue for rebar3 users. --steve |
|
From: Steve V. <vi...@ie...> - 2023-11-16 19:47:53
|
I use kerl https://github.com/kerl/kerl so I can have lots of OTP versions on my system without stepping on each other. --steve On Thu, Nov 16, 2023 at 2:39 PM <er...@ca...> wrote: > I did see issue #427 but it seems I misread it and thought the issue was > fixed. Maybe (probably) I messed something up trying to revert OTP. I'll > start afresh. > > Steve Vinoski wrote: > > Yaws doesn't work with OTP 26; this is issue #467 on github > > https://github.com/erlyaws/yaws/issues/467 > > <https://github.com/erlyaws/yaws/issues/467> . So far it's not been an > > easy problem to solve, otherwise it would already be working. > > > > Yaws does work with 25.3, as I just built it and tested it successfully > > on that version a few days ago, and the github test matrix, which > > includes 25.3, also worked fine when I pushed a new branch up a few days > > ago, and also works for master (I think you can see it here: > > https://github.com/erlyaws/yaws/actions/runs/6841356446 > > <https://github.com/erlyaws/yaws/actions/runs/6841356446>). > > > > If you like, you can file a new issue on github for the 25.x problems > > you're seeing: https://github.com/erlyaws/yaws/issues > > <https://github.com/erlyaws/yaws/issues> . Please include as much detail > > as you can. > > > > --steve > > > > > > > > > > On Thu, Nov 16, 2023 at 1:45 PM <er...@ca... > > <mailto:er...@ca...>> wrote: > > > > Can anyone tell me which version of OTP I should be using for Yaws at > > the moment? > > > > Trying to install Yaws 2.1.1 (redirect-trailing-slash branch) on OTP > > 26.1.2 on a fresh CentOS VM failed with: > > > > --- > > yaws_config.erl:3563:20: file:pid2name/1 is deprecated and will be > > removed in OTP 27; this functionality is no longer supported > > % 3563| {ok, Config} = file:pid2name(FD), > > % | ^ > > > > yaws_config.erl:3579:20: file:pid2name/1 is deprecated and will be > > removed in OTP 27; this functionality is no longer supported > > % 3579| {ok, Config} = file:pid2name(FD), > > % | ^ > > > > make[1]: *** [../ebin/yaws_config.beam] Error 1 > > --- > > > > On OTP 25.3.2.7, install failed with: > > > > configure: error: test Erlang program execution failed > > > > and config.log contained a variety of errors. > > > > > > _______________________________________________ > > Erlyaws-list mailing list > > Erl...@li... > > <mailto:Erl...@li...> > > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > > <https://lists.sourceforge.net/lists/listinfo/erlyaws-list> > > > |
|
From: <er...@ca...> - 2023-11-16 19:40:14
|
I did see issue #427 but it seems I misread it and thought the issue was fixed. Maybe (probably) I messed something up trying to revert OTP. I'll start afresh. Steve Vinoski wrote: > Yaws doesn't work with OTP 26; this is issue #467 on github > https://github.com/erlyaws/yaws/issues/467 > <https://github.com/erlyaws/yaws/issues/467> . So far it's not been an > easy problem to solve, otherwise it would already be working. > > Yaws does work with 25.3, as I just built it and tested it successfully > on that version a few days ago, and the github test matrix, which > includes 25.3, also worked fine when I pushed a new branch up a few days > ago, and also works for master (I think you can see it here: > https://github.com/erlyaws/yaws/actions/runs/6841356446 > <https://github.com/erlyaws/yaws/actions/runs/6841356446>). > > If you like, you can file a new issue on github for the 25.x problems > you're seeing: https://github.com/erlyaws/yaws/issues > <https://github.com/erlyaws/yaws/issues> . Please include as much detail > as you can. > > --steve > > > > > On Thu, Nov 16, 2023 at 1:45 PM <er...@ca... > <mailto:er...@ca...>> wrote: > > Can anyone tell me which version of OTP I should be using for Yaws at > the moment? > > Trying to install Yaws 2.1.1 (redirect-trailing-slash branch) on OTP > 26.1.2 on a fresh CentOS VM failed with: > > --- > yaws_config.erl:3563:20: file:pid2name/1 is deprecated and will be > removed in OTP 27; this functionality is no longer supported > % 3563| {ok, Config} = file:pid2name(FD), > % | ^ > > yaws_config.erl:3579:20: file:pid2name/1 is deprecated and will be > removed in OTP 27; this functionality is no longer supported > % 3579| {ok, Config} = file:pid2name(FD), > % | ^ > > make[1]: *** [../ebin/yaws_config.beam] Error 1 > --- > > On OTP 25.3.2.7, install failed with: > > configure: error: test Erlang program execution failed > > and config.log contained a variety of errors. > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > <mailto:Erl...@li...> > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > <https://lists.sourceforge.net/lists/listinfo/erlyaws-list> > |
|
From: Steve V. <vi...@ie...> - 2023-11-16 19:33:21
|
Yaws doesn't work with OTP 26; this is issue #467 on github https://github.com/erlyaws/yaws/issues/467 . So far it's not been an easy problem to solve, otherwise it would already be working. Yaws does work with 25.3, as I just built it and tested it successfully on that version a few days ago, and the github test matrix, which includes 25.3, also worked fine when I pushed a new branch up a few days ago, and also works for master (I think you can see it here: https://github.com/erlyaws/yaws/actions/runs/6841356446). If you like, you can file a new issue on github for the 25.x problems you're seeing: https://github.com/erlyaws/yaws/issues . Please include as much detail as you can. --steve On Thu, Nov 16, 2023 at 1:45 PM <er...@ca...> wrote: > Can anyone tell me which version of OTP I should be using for Yaws at > the moment? > > Trying to install Yaws 2.1.1 (redirect-trailing-slash branch) on OTP > 26.1.2 on a fresh CentOS VM failed with: > > --- > yaws_config.erl:3563:20: file:pid2name/1 is deprecated and will be > removed in OTP 27; this functionality is no longer supported > % 3563| {ok, Config} = file:pid2name(FD), > % | ^ > > yaws_config.erl:3579:20: file:pid2name/1 is deprecated and will be > removed in OTP 27; this functionality is no longer supported > % 3579| {ok, Config} = file:pid2name(FD), > % | ^ > > make[1]: *** [../ebin/yaws_config.beam] Error 1 > --- > > On OTP 25.3.2.7, install failed with: > > configure: error: test Erlang program execution failed > > and config.log contained a variety of errors. > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
|
From: <er...@ca...> - 2023-11-16 18:45:06
|
Can anyone tell me which version of OTP I should be using for Yaws at
the moment?
Trying to install Yaws 2.1.1 (redirect-trailing-slash branch) on OTP
26.1.2 on a fresh CentOS VM failed with:
---
yaws_config.erl:3563:20: file:pid2name/1 is deprecated and will be
removed in OTP 27; this functionality is no longer supported
% 3563| {ok, Config} = file:pid2name(FD),
% | ^
yaws_config.erl:3579:20: file:pid2name/1 is deprecated and will be
removed in OTP 27; this functionality is no longer supported
% 3579| {ok, Config} = file:pid2name(FD),
% | ^
make[1]: *** [../ebin/yaws_config.beam] Error 1
---
On OTP 25.3.2.7, install failed with:
configure: error: test Erlang program execution failed
and config.log contained a variety of errors.
|
|
From: Steve V. <vi...@ie...> - 2023-11-13 13:33:04
|
I pushed a branch to github with a fix for this, along with a new test: https://github.com/erlyaws/yaws/tree/redirect-trailing-slash If you're able to apply the change and give it a try, please do and let me know how it goes. Meanwhile I'm still doing some code checks before I merge it. --steve On Fri, Nov 10, 2023 at 11:03 AM Steve Vinoski <vi...@ie...> wrote: > Sounds like a Yaws bug, I'll have to investigate it. > > --steve > > On Fri, Nov 10, 2023 at 10:32 AM <er...@ca...> wrote: > >> I'm using the simple method for redirecting a whole site to https in >> yaws.conf like this: >> >> <server domain.tld> >> port = 80 >> listen = 0.0.0.0 >> <redirect> >> / = https://domain.tld >> </redirect> >> </server> >> >> It works except that a request of the form domain.tld/directory/ is >> being redirected to https://domain.tld/directory losing the trailing >> slash which, for my current project, is important. >> >> Is this by design and, if so, can I fix/change it easily within Yaws >> without adding another redirect (which I'm currently doing on the server)? >> >> >> _______________________________________________ >> Erlyaws-list mailing list >> Erl...@li... >> https://lists.sourceforge.net/lists/listinfo/erlyaws-list >> > |
|
From: Steve V. <vi...@ie...> - 2023-11-10 16:03:29
|
Sounds like a Yaws bug, I'll have to investigate it. --steve On Fri, Nov 10, 2023 at 10:32 AM <er...@ca...> wrote: > I'm using the simple method for redirecting a whole site to https in > yaws.conf like this: > > <server domain.tld> > port = 80 > listen = 0.0.0.0 > <redirect> > / = https://domain.tld > </redirect> > </server> > > It works except that a request of the form domain.tld/directory/ is > being redirected to https://domain.tld/directory losing the trailing > slash which, for my current project, is important. > > Is this by design and, if so, can I fix/change it easily within Yaws > without adding another redirect (which I'm currently doing on the server)? > > > _______________________________________________ > Erlyaws-list mailing list > Erl...@li... > https://lists.sourceforge.net/lists/listinfo/erlyaws-list > |
|
From: <er...@ca...> - 2023-11-10 15:32:01
|
I'm using the simple method for redirecting a whole site to https in
yaws.conf like this:
<server domain.tld>
port = 80
listen = 0.0.0.0
<redirect>
/ = https://domain.tld
</redirect>
</server>
It works except that a request of the form domain.tld/directory/ is
being redirected to https://domain.tld/directory losing the trailing
slash which, for my current project, is important.
Is this by design and, if so, can I fix/change it easily within Yaws
without adding another redirect (which I'm currently doing on the server)?
|
|
From: Per A. (perander) <per...@ci...> - 2023-09-25 13:34:44
|
Hi!
From: Java House <jav...@gm...> on Saturday, September 23, 2023:
> In my attempt to build an Enterprise level content management system using yaws (rebar3-support branch) I have come to the following design.
in arg_rewrite I squeeze following functionality:
>
> * url rewrite - to support legacy urls
> * resource resolver - figure out if the req corresponds to a module (modapp etc) or a yaws page on the docroot, extract the access policies required and add all the info into the Arg
> * Then login if required or deliver the content if session has correct access rights.
>
> (For the access policies I am planning to introduce a function that appmods may implement e.g. access_policy() which will return either none or a list [{get, [role1]}, {post, [role1, role2]}] for pages and for modules [{method1, [role1]}, {method2, [role1, role2]}] or maybe a policy file on directory level for the pages.
>
> My problem is following:
> I believe a similar functionality to the resource resolver (to identify what resource will be executed) already exists in yaws_server (still little hard for me to reverse engineer erlang code)
> Could I have a hint reference as of the piece of code that identifies what to deliver?
Appmods has an out/1 callback which takes an arg record and delivers the
content to the user. They also have an auth/2 callback, which takes an arg
record and the Authorization HTTP header and returns values depending
on authentication.
It is also possible to use an authmod, use .yaws_auth files, and configure
auth in yaws.conf.
The arg record contains data related to the request, i.e. the resource used
in the request can be found in the req record path.
Req = yaws_api:arg_req(A),
Path = yaws_api:http_request_path(Req).
> I see there is still development going on in yaws.
> Could we propose ideas and be involved in the process?
Patches are welcome!
Raise issues or send pull requests on github.
> Do you have a forum where you discuss or maybe some online meetings?
This mailing list is what we have and use.
There are other more general Erlang community resources where you can
try your luck as well.
https://www.erlang.org/community
--
Per
|
|
From: Java H. <jav...@gm...> - 2023-09-23 13:43:36
|
Hello
In my attempt to build an Enterprise level content management system using
yaws (rebar3-support branch) I have come to the following design.
in arg_rewrite I squeeze following functionality:
- url rewrite - to support legacy urls
- resource resolver - figure out if the req corresponds to a module
(modapp etc) or a yaws page on the docroot, extract the access policies
required and add all the info into the Arg
- Then login if required or deliver the content if session has correct
access rights.
(For the access policies I am planning to introduce a function that appmods
may implement e.g. access_policy() which will return either none or a list
[{get, [role1]}, {post, [role1, role2]}] for pages and for modules
[{method1, [role1]}, {method2, [role1, role2]}] or maybe a policy file on
directory level for the pages.
My problem is following:
I believe a similar functionality to the resource resolver (to identify
what resource will be executed) already exists in yaws_server (still little
hard for me to reverse engineer erlang code)
Could I have a hint reference as of the piece of code that identifies what
to deliver?
I see there is still development going on in yaws.
Could we propose ideas and be involved in the process?
Do you have a forum where you discuss or maybe some online meetings?
Kind Regards
Nikolas
|
|
From: Java H. <jav...@gm...> - 2023-08-26 18:36:14
|
of course, so simple
Thank you Steve
Στις Σάβ 26 Αυγ 2023 στις 4:49 μ.μ., ο/η Steve Vinoski <vi...@ie...>
έγραψε:
>
>
> On Sat, Aug 26, 2023 at 6:30 AM Java House <jav...@gm...> wrote:
>
>> Hello
>> I am trying to write an arg_rewrite function where I rewrite the
>> requested path but apparently I am doing something wrong.
>> My expectation is that Req0 and Req1 would have same abs_path
>> I tried both
>> Arg#arg{req = Req#http_request{path = {abs_path, Rest}}, state = Rest},
>> and
>> Arg#arg{req = Req#http_request{path = {abs_path, Rest}}},
>>
>> Can someone help?
>>
>
> Since Arg like all Erlang variables is immutable, you need to capture the
> result of "changing" fields of Arg into a new variable, for example:
>
> NewArg = Arg#arg{req = Req#http_request{path = {abs_path, Rest}}},
>
> And then return NewArg as the result. See
> https://github.com/erlyaws/yaws/blob/master/src/yaws_vdir.erl#L14 for an
> example.
>
> --steve
>
>
>>
>> Regards
>> Nikolas
>>
>> arg_rewrite(Arg) -> error_logger:info_msg("ecms_rsr_resolver:arg_rewrite
>> ~p~n", [Arg]), Url = yaws_api:request_url(Arg), error_logger:info_msg("Url
>> ~p~n", [Url]), Req = yaws_api:arg_req(Arg), {abs_path, Path} = Req
>> #http_request.path, case Path of "/rewrite" ++ Rest -> error_logger:
>> info_msg("ecms_rsr_resolver:arg_rewrite Rest ~p~n", [Rest]), Req0 = Req
>> #http_request{path = {abs_path, Rest}}, Arg#arg{req = Req#http_request{
>> path = {abs_path, Rest}}, state = Rest}, Req1 = yaws_api:arg_req(Arg),
>> error_logger:info_msg("ecms_rsr_resolver:arg_rewrite after rewite ~p~n",
>> [Req0, Req1]), Arg; _ -> Arg end.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> =INFO REPORT==== 26-Aug-2023::12:41:42.657401 ===
>> Url {url,"http","10.55.0.4",4441,"/rewrite/yaws",[]}
>>
>> =INFO REPORT==== 26-Aug-2023::12:41:42.657516 ===
>> ecms_rsr_resolver:arg_rewrite Rest "/yaws"
>>
>> =INFO REPORT==== 26-Aug-2023::12:41:42.657562 ===
>> ERROR: "ecms_rsr_resolver:arg_rewrite after rewite ~p~n" - [{http_request,
>> 'GET',
>> {abs_path,
>> "*/yaws*"},
>> {1,1}},
>> {http_request,
>> 'GET',
>> {abs_path,
>> "
>> */rewrite/yaws*"},
>> {1,1}}]
>> ```
>> _______________________________________________
>> Erlyaws-list mailing list
>> Erl...@li...
>> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>>
>
|
|
From: Steve V. <vi...@ie...> - 2023-08-26 14:49:22
|
On Sat, Aug 26, 2023 at 6:30 AM Java House <jav...@gm...> wrote:
> Hello
> I am trying to write an arg_rewrite function where I rewrite the requested
> path but apparently I am doing something wrong.
> My expectation is that Req0 and Req1 would have same abs_path
> I tried both
> Arg#arg{req = Req#http_request{path = {abs_path, Rest}}, state = Rest},
> and
> Arg#arg{req = Req#http_request{path = {abs_path, Rest}}},
>
> Can someone help?
>
Since Arg like all Erlang variables is immutable, you need to capture the
result of "changing" fields of Arg into a new variable, for example:
NewArg = Arg#arg{req = Req#http_request{path = {abs_path, Rest}}},
And then return NewArg as the result. See
https://github.com/erlyaws/yaws/blob/master/src/yaws_vdir.erl#L14 for an
example.
--steve
>
> Regards
> Nikolas
>
> arg_rewrite(Arg) -> error_logger:info_msg("ecms_rsr_resolver:arg_rewrite
> ~p~n", [Arg]), Url = yaws_api:request_url(Arg), error_logger:info_msg("Url
> ~p~n", [Url]), Req = yaws_api:arg_req(Arg), {abs_path, Path} = Req
> #http_request.path, case Path of "/rewrite" ++ Rest -> error_logger:
> info_msg("ecms_rsr_resolver:arg_rewrite Rest ~p~n", [Rest]), Req0 = Req
> #http_request{path = {abs_path, Rest}}, Arg#arg{req = Req#http_request{
> path = {abs_path, Rest}}, state = Rest}, Req1 = yaws_api:arg_req(Arg),
> error_logger:info_msg("ecms_rsr_resolver:arg_rewrite after rewite ~p~n", [
> Req0, Req1]), Arg; _ -> Arg end.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> =INFO REPORT==== 26-Aug-2023::12:41:42.657401 ===
> Url {url,"http","10.55.0.4",4441,"/rewrite/yaws",[]}
>
> =INFO REPORT==== 26-Aug-2023::12:41:42.657516 ===
> ecms_rsr_resolver:arg_rewrite Rest "/yaws"
>
> =INFO REPORT==== 26-Aug-2023::12:41:42.657562 ===
> ERROR: "ecms_rsr_resolver:arg_rewrite after rewite ~p~n" - [{http_request,
> 'GET',
> {abs_path,
> "*/yaws*"},
> {1,1}},
> {http_request,
> 'GET',
> {abs_path,
> "
> */rewrite/yaws*"},
> {1,1}}]
> ```
> _______________________________________________
> Erlyaws-list mailing list
> Erl...@li...
> https://lists.sourceforge.net/lists/listinfo/erlyaws-list
>
|
|
From: Java H. <jav...@gm...> - 2023-08-26 11:29:56
|
Hello
I am trying to write an arg_rewrite function where I rewrite the requested
path but apparently I am doing something wrong.
My expectation is that Req0 and Req1 would have same abs_path
I tried both
Arg#arg{req = Req#http_request{path = {abs_path, Rest}}, state = Rest},
and
Arg#arg{req = Req#http_request{path = {abs_path, Rest}}},
Can someone help?
Regards
Nikolas
arg_rewrite(Arg) -> error_logger:info_msg("ecms_rsr_resolver:arg_rewrite
~p~n", [Arg]), Url = yaws_api:request_url(Arg), error_logger:info_msg("Url
~p~n", [Url]), Req = yaws_api:arg_req(Arg), {abs_path, Path} = Req
#http_request.path, case Path of "/rewrite" ++ Rest -> error_logger:info_msg
("ecms_rsr_resolver:arg_rewrite Rest ~p~n", [Rest]), Req0 = Req#http_request
{path = {abs_path, Rest}}, Arg#arg{req = Req#http_request{path = {abs_path,
Rest}}, state = Rest}, Req1 = yaws_api:arg_req(Arg),
error_logger:info_msg("ecms_rsr_resolver:arg_rewrite
after rewite ~p~n", [Req0, Req1]), Arg; _ -> Arg end.
=INFO REPORT==== 26-Aug-2023::12:41:42.657401 ===
Url {url,"http","10.55.0.4",4441,"/rewrite/yaws",[]}
=INFO REPORT==== 26-Aug-2023::12:41:42.657516 ===
ecms_rsr_resolver:arg_rewrite Rest "/yaws"
=INFO REPORT==== 26-Aug-2023::12:41:42.657562 ===
ERROR: "ecms_rsr_resolver:arg_rewrite after rewite ~p~n" - [{http_request,
'GET',
{abs_path,
"*/yaws*"},
{1,1}},
{http_request,
'GET',
{abs_path,
"
*/rewrite/yaws*"},
{1,1}}]
```
|
100 messages has been excluded from this view by a project administrator.
