Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

more w3c compliance

git-svn-id: https://erlyaws.svn.sourceforge.net/svnroot/erlyaws/trunk/yaws@791 9fbdc01b-0d2c-0410-bfb7-fb27d70d8b52
  • Loading branch information...
commit e35a59185374eeb06d3221d9070269bc046a8810 1 parent a35bad5
@klacke authored
View
45 www/arg.yaws
@@ -10,18 +10,18 @@ out(A) ->
<h2> The Arg </h2>
-<p>This page displays the Arg #arg structure
-supplied to the out/1 function.
-
-<p> The #arg structure is a very important datastructure for the
-yaws programmer. It is the main mechanism whereby the server can pass
-data to the web application. There are several data items
-which are of interest to the webapplication, such as which headers
-were sent from the client, etc.
-The #arg recored is defined in <tt>yaws_api.hrl</tt> and is defined as:
-
-<div class="box">
-<pre>
+ <p>This page displays the Arg #arg structure
+ supplied to the out/1 function.
+ </p>
+ <p> The #arg structure is a very important datastructure for the
+ yaws programmer. It is the main mechanism whereby the server can pass
+ data to the web application. There are several data items
+ which are of interest to the webapplication, such as which headers
+ were sent from the client, etc.
+ The #arg recored is defined in <tt>yaws_api.hrl</tt> and is defined as:
+ </p>
+ <div class="box">
+ <pre>
-record(arg, {
@@ -38,22 +38,23 @@ The #arg recored is defined in <tt>yaws_api.hrl</tt> and is defined as:
state, %% State for use by users of the out/1 callback
pid, %% pid of the yaws worker process
opaque, %% useful to pass static data
- appmod_prepath, %% path in front of: <appmod><appmoddata>
-
+ appmod_prepath, %% path in front of: &lt;appmod&gt;&lt;appmoddata&gt;
pathinfo %% Set to 'd/e' when calling c.yaws for the request
%% http://some.host/a/b/c.yaws/d/e
}).
-</pre>
-</div>
-
-<p> As we have seen is several previous examples, the <tt> out/1</tt> function
-defined in .yaws files, gets invoked with a single argument which is
-a #arg{} record, fitting the specific HTTP request being served.
+ </pre>
+ </div>
-<p> The code to display the #arg{} record
-is in defined in file <a href="code.yaws?file=/arg.yaws">arg.yaws</a>
+ <p> As we have seen is several previous examples,
+ the <tt> out/1</tt> function
+ defined in .yaws files, gets invoked with a single argument which is
+ a #arg{} record, fitting the specific HTTP request being served.
+ </p>
+ <p> The code to display the #arg{} record
+ is in defined in file <a href="code.yaws?file=/arg.yaws">arg.yaws</a>
+ </p>
<erl>
View
103 www/bindings.yaws
@@ -6,38 +6,42 @@ out(A) ->
<div id="entry">
<h2> Bindings </h2>
-<p>
-Bindings are the opposite of <a href="ssi.yaws"> Server Side Includes (SSI)</a>.
-SSI is used when entire pages are written largely in EHTML and
-snippets of HTML, or more typically javascript code is inserted into the EHTML
-code.
-
-<p> Bindings are used the other way around. Essentially entire
-pages are written in regular HTML but parts of the HTML needs to be
-dynamically generated.
-
-<p>The yaws callback out/1 can return
-
-<div class="box">
-<pre>
-{bindings, [{Key1, Value2}, {Key2, Value2} .....]}.
-</pre>
-</div>
-
-
-<p>All bindings can then be used in the rest of yaws code (in HTML source and
-within erl tags). In HTML source %%Key%% is expanded to Value and
-within erl tags yaws_api:get_binding(Key) can be used to extract Value.
-
-<p>With the binding feature it is easier to write transparent yaws code making
-it easier to to work together with Web people knowing little or
-nothing about Erlang.
-
-An example:
-
-
-<div class="box">
-<pre>
+ <p>
+ Bindings are the opposite of
+ <a href="ssi.yaws"> Server Side Includes (SSI)</a>.
+ SSI is used when entire pages are written largely in EHTML and
+ snippets of HTML, or more typically javascript code is
+ inserted into the EHTML
+ code.
+ </p>
+
+ <p> Bindings are used the other way around. Essentially entire
+ pages are written in regular HTML but parts of the HTML needs to be
+ dynamically generated.
+ </p>
+ <p>The yaws callback out/1 can return
+ </p>
+ <div class="box">
+ <pre>
+ {bindings, [{Key1, Value2}, {Key2, Value2} .....]}.
+ </pre>
+ </div>
+
+
+ <p>All bindings can then be used in the rest of yaws code (in HTML source and
+ within erl tags). In HTML source %%Key%% is expanded to Value and
+ within erl tags yaws_api:get_binding(Key) can be used to extract Value.</p>
+
+ <p>With the binding feature it is easier to write transparent yaws code making
+ it easier to to work together with Web people knowing little or
+ nothing about Erlang.</p>
+
+ <p>
+ An example:
+ </p>
+
+ <div class="box">
+ <pre>
&lt;erl&gt;
out(A) -&gt; {bindings, [{"A", "foo"}, {"B", "baz"}]}.
@@ -62,15 +66,15 @@ out(A) -&gt;
%%A%% = %%A%% (hit me)
&lt;/body&gt;
&lt;/html&gt;
-</pre>
-</div>
+ </pre>
+ </div>
<p>
-Which expands to:
+ Which expands to:</p>
-<div class="box">
-<pre>
+ <div class="box">
+ <pre>
@@ -88,23 +92,24 @@ foo = foo (hit me)
-</pre>
-</div>
+ </pre>
+ </div>
-<p> And is rendered as:
+ <p> And is rendered as:</p>
-<div class="box">
-<p>foo</p>
-<p><font size="4">foo != baz</font></p>
-<p>An enormous amount of plain html source here.</p>
+ <div class="box">
+ <p>foo</p>
+ <p><font size="4">foo != baz</font></p>
+ <p>An enormous amount of plain html source here.</p>
-<ul>
-<li>foo</li>
-<li>gazonk</li></ul>
+ <ul>
+ <li>foo</li>
+ <li>gazonk</li>
+ </ul>
-foo = foo (hit me)
-</div>
+ foo = foo (hit me)
+ </div>
View
62 www/cookies.yaws
@@ -7,37 +7,37 @@ out(A) ->
-<h1>Yaws and Cookies</h1>
-<p>
-Cookies are the means in HTTP to assign data to a session. A HTTP session
-typically consists of many (and sometimes concurrent) TCP connections from the
-client to the web server. The first time a client arrives to our webserver, we
-issue the HTTP header <tt>Set-Cookie: var=someval</tt>. The browser will then in
-subsequent connections to the same server pass this cookie "var=someval" in its
-client side <tt>Cookie: var=someval</tt> header. We can thereby assign state to a
-session, either through data actualy encoded into the cookie value itself, or by
-associating server side session data to the cookie.
-<p>
-
-Let's do an example where we set a simple cookie, and create a specific erlang process
-which is then responsible for that session.
-The cookie value will be a string encoding of the pid handling the session.
-
-<p>
-The yaws code in
-<a href="setcookie.yaws">setcookie.yaws</a> sets the cookie in the browser.
-
-<p>And the yaws code in <a href="readcookie.yaws">readcookie.yaws</a>
-will read the cookie
-and report some uninteresting session data.
-
-
-
-A correct definition of cookies can be found at Netscapes
-<a href="http://www.netscape.com/newsref/std/cookie_spec.html">cookie spec</a>
-
-
-<p>The code to set the cookie looks like:
+ <h1>Yaws and Cookies</h1>
+ <p>
+ Cookies are the means in HTTP to assign data to a session. A HTTP session
+ typically consists of many (and sometimes concurrent) TCP connections from the
+ client to the web server. The first time a client arrives to our webserver, we
+ issue the HTTP header <tt>Set-Cookie: var=someval</tt>. The browser will then in
+ subsequent connections to the same server pass this cookie "var=someval" in its
+ client side <tt>Cookie: var=someval</tt> header. We can thereby assign state to a
+ session, either through data actualy encoded into the cookie value itself, or by
+ associating server side session data to the cookie.</p>
+ <p>
+
+ Let's do an example where we set a simple cookie, and create a specific erlang process
+ which is then responsible for that session.
+ The cookie value will be a string encoding of the pid handling the session.
+ </p>
+ <p>
+ The yaws code in
+ <a href="setcookie.yaws">setcookie.yaws</a> sets the cookie in the browser.</p>
+
+ <p>And the yaws code in <a href="readcookie.yaws">readcookie.yaws</a>
+ will read the cookie
+ and report some uninteresting session data.
+ </p>
+
+ <p>
+ A correct definition of cookies can be found at Netscapes
+ <a href="http://www.netscape.com/newsref/std/cookie_spec.html">cookie spec</a></p>
+
+
+ <p>The code to set the cookie looks like:</p>
<erl>
out(A) ->
View
140 www/embed.yaws
@@ -7,37 +7,43 @@ out(A) ->
<div id="entry">
-<h1>Running yaws embedded in another larger application</h1>
-<p>
-Yaws is ideal to embed inside another larger erlang application.
-Many typical erlang applications are control applications
-in need of a webgui specific for the actual application.
-
-<p>In order to run Yaws inside another application, we need to
-perform the following steps.
-
-<ol>
-<li> <p>Either integrate yaws into the build system of the
-larger application or specifically provide the ebin path to
-yaws for the larger application.
-
-<li><p> Provide the application environment {embedded, true}
-to Yaws.
-
-<li><p> The large application typically has it's configuration
-data fed from internal databases, anyway it's usually not feasible
-to let Yaws read it's configuration data from /etc/yaws.conf.
-
-<p>To solve this, when Yaws is started in embedded mode, it doesn't
-read it's config from /etc, rather it expects the larger application
-to feed it the Yaws configuration through the function call
-yaws_api:set_conf(GC, Groups)
-
-<p> The two arguments here are
-<ol>
-<li><p>GC is a #gconf{} record. The definition of the
-record is:
-<pre>
+ <h1>Running yaws embedded in another larger application</h1>
+ <p>
+ Yaws is ideal to embed inside another larger erlang application.
+ Many typical erlang applications are control applications
+ in need of a webgui specific for the actual application.
+ </p>
+
+ <p>In order to run Yaws inside another application, we need to
+ perform the following steps.
+ </p>
+
+ <ol>
+ <li> <p>Either integrate yaws into the build system of the
+ larger application or specifically provide the ebin path to
+ yaws for the larger application. </p>
+ </li>
+
+ <li><p> Provide the application environment {embedded, true}
+ to Yaws.</p>
+ </li>
+ </ol>
+
+ <p> The large application typically has it's configuration
+ data fed from internal databases, anyway it's usually not feasible
+ to let Yaws read it's configuration data from /etc/yaws.conf.</p>
+
+ <p>To solve this, when Yaws is started in embedded mode, it doesn't
+ read it's config from /etc, rather it expects the larger application
+ to feed it the Yaws configuration through the function call
+ yaws_api:set_conf(GC, Groups)
+ </p>
+
+ <p> The two arguments here are</p>
+ <ol>
+ <li><p>GC is a #gconf{} record. The definition of the
+ record is:</p>
+ <pre>
%% global conf
-record(gconf,{file,
yaws_dir,
@@ -60,21 +66,24 @@ record is:
username, %% maybe run as a different user than root
uid %% unix uid of user that started yaws
}).
-</pre>
+ </pre>
-<p>The easiest way to figure out what the individual record
-fields mean is to have a look in the source file yaws_config.erl
+ <p>The easiest way to figure out what the individual record
+ fields mean is to have a look in the source file yaws_config.erl</p>
+ </li>
-<li><p>Groups, is a list of lists of #sconf records.
-Yaws is capable of listening on several IP address and also
-do Virtual Hosting on each IP address.
-<p>Each #sconf{} record describes one web server, whereas a list of
-#sconf{} records describe a web server Virt Hosting several different
-servers.
-
-The sconf record is defined as:
-<pre>
+ <li><p>Groups, is a list of lists of #sconf records.
+ Yaws is capable of listening on several IP address and also
+ do Virtual Hosting on each IP address.
+ </p>
+ <p>Each #sconf{} record describes one web server, whereas a list of
+ #sconf{} records describe a web server Virt Hosting several different
+ servers.
+ </p>
+ <p>
+ The sconf record is defined as:</p>
+ <pre>
-record(ssl,
{
@@ -119,33 +128,35 @@ The sconf record is defined as:
allowed_scripts = [yaws]
}).
-</pre>
-
-</ol>
-</ol>
-
+ </pre>
+ </li>
+ </ol>
-<h2> A very small actual example </h2>
-<p>We provide a minimal example which "embeds" yaws in
-a normal Erlang shell.
-<p>We start Erlang as:
+ <h2> A very small actual example </h2>
+ <p>We provide a minimal example which "embeds" yaws in
+ a normal Erlang shell.
+ </p>
+ <p>We start Erlang as:
+ </p>
-<pre>
+ <pre>
# erl -pa /usr/local/lib/yaws/ebin -yaws embedded true -s ybed
-</pre>
+ </pre>
-<p>The ybed module is very small and is named
-<a href="code.yaws?file=/ybed.erl">ybed.erl</a>
+ <p>The ybed module is very small and is named
+ <a href="code.yaws?file=/ybed.erl">ybed.erl</a>
+ </p>
-<p>The above "erl" command line gives:
+ <p>The above "erl" command line gives:
+ </p>
-<pre>
+ <pre>
# erl -pa /usr/local/lib/yaws/ebin -yaws embedded true -s ybed
Erlang (BEAM) emulator version 5.3.b1 [source] [hipe]
Eshell V5.3.b1 (abort with ^G)
-1>
+1&gt;
=INFO REPORT==== 25-Nov-2003::00:27:18 ===
Yaws: Listening to 0.0.0.0:8888 for servers
- foobar under /tmp
@@ -160,24 +171,29 @@ harder than it might seem at a first glance. The configuration of the
web server was programmatically fed into Yaws from the surrounding application,
in this case, the Erlang shell + the module
<a href="code.yaws?file=/ybed.erl">ybed.erl</a>
+</p>
<h2>The opaque field in the sconf structure </h2>
<p>The sconf structure (which is constructed by the program that
starts and configures Yaws), contains a field, SC#sconf.opaque
+</p>
+
<p> This field is passed on into the #arg{} record, so that any application
specific configuration data which is needed by the .yaws pages that
make up the web GUI application, is easily available there.
+</p>
+
-<p>In essence, if we construct the #sconf as
+<p>In essence, if we construct the #sconf as</p>
<pre>
SC#sconf{opaque = {mystruct, foobar},
.....
</pre>
-<p>A .yaws web page, can do:
+<p>A .yaws web page, can do:</p>
<pre>
out(Arg) ->
MyStruct = Arg#arg.opaque
@@ -186,7 +202,7 @@ out(Arg) ->
</pre>
<p>Thus passing data from the surrounding applications configuration routines
-down to each .yaws web page.
+ down to each .yaws web page.</p>
View
84 www/form.yaws
@@ -8,45 +8,51 @@ out(A) ->
<div id="entry">
-<h2>POST example </h2>
-
-<p>This is a simple example where we get to fill in
-a series of fields and POST the data by hitting the Submit button
-at the end.
-<p>
-The action is set to the yaws file <tt>/post.yaws </tt> which
-gets POSTed data in its <tt>ARG#arg.clidata</tt> field.
-
-
-<form METHOD=POST
- ACTION="/post.yaws"
-
-This is a serious poll.
-
- <p>Your favourite programming language? <input NAME="lang" TYPE=text SIZE="48">
-
-<p>Imperative ? <input NAME="imperative" TYPE=checkbox>
-
-How many tabs to you indent? <input NAME="tabs" TYPE=int>
-
-<p>Which OS do you use?
-
- <ol>
-<li>Windows 95 pro ultra <input NAME="os1" TYPE=checkbox VALUE="w95">
-<li>Windows XP beta cracked <input NAME="os2" TYPE=checkbox VALUE="xpbeta">
-<li>Windows <input NAME="os3" TYPE=checkbox VALUE="windows">
-<li>Other<input NAME="other" SIZE=40>
-</ol>
-
-Your email <input NAME="contact" SIZE="42">
-
-<p>Submit this POST to get an explanation of how to process the
-POSTed data.
-
- <p><input TYPE=submit> <input TYPE=reset>
-
-</form>
-
+ <h2>POST example </h2>
+
+ <p>This is a simple example where we get to fill in
+ a series of fields and POST the data by hitting the Submit button
+ at the end.
+ </p>
+ <p>
+ The action is set to the yaws file <tt>/post.yaws </tt> which
+ gets POSTed data in its <tt>ARG#arg.clidata</tt> field.
+ </p>
+
+ <form method="post"
+ action="/post.yaws">
+
+ This is a serious poll.
+
+ <p>Your favourite programming language? </p>
+ <input name="lang" type="text" size="48" />
+
+ <p>Imperative ? <input name="imperative" type="checkbox"/></p>
+
+ <p>How many tabs to you indent? <input name="tabs" type="text" /></p>
+
+ <p>Which OS do you use?</p>
+
+ <ol>
+ <li>Windows 95 pro ultra
+ <input name="os1" type="checkbox" value="w95"/></li>
+
+ <li>Windows XP beta cracked
+ <input name="os2" type="checkbox" value="xpbeta" /></li>
+ <li>Windows
+ <input name="os3" type="checkbox" value="windows"/></li>
+ <li>Other<input name="other" size="40" /></li>
+ </ol>
+
+ <p>Your email <input name="contact" size="42" /></p>
+
+ <p>Submit this POST to get an explanation of how to process the
+ POSTed data.</p>
+
+ <p><input type="submit" /> <input type="reset" /></p>
+
+ </form>
+
</div>
View
45 www/pcookie.yaws
@@ -6,26 +6,30 @@ out(A) -> {ssi, "TAB.inc", "%%",[{"pcookie", "choosen"}]}.
<div id="entry">
<h1>Persistent Cookies</h1>
-<p>
-We saw in the first <a href="cookies.yaws">cookie</a> example, how we
-assigned a special erlang process to handle each session.
-The cookie has an expiry date, and the correct thing would be to let the
-handling process live as long as the cookie is valid. This is not a good option.
-A better option is to store cookie in a persistant storage. This can be an
-ets table or a dets table. If we choose an ets table, the cookies will disappear
-when the yaws server is restarted, whereas if we choose a dets table,
-the cookies will survive daemon restarts. What to choose depends on the
-type of cookie information we have.
-
-<p>
-The yaws code in
-<a href="setpcookie.yaws">setpcookie.yaws</a> sets the cookie in the browser.
-
-<p>And the yaws code in <a href="readpcookie.yaws">readpcookie.yaws</a>
-will read the cookie
-
-<p>
-Let's show some code. To set the cookie we we have:
+ <p>
+ We saw in the first <a href="cookies.yaws">cookie</a> example, how we
+ assigned a special erlang process to handle each session.
+ The cookie has an expiry date, and the correct thing would be to let the
+ handling process live as long as the cookie is valid. This is not a good option.
+ A better option is to store cookie in a persistant storage. This can be an
+ ets table or a dets table. If we choose an ets table, the cookies will disappear
+ when the yaws server is restarted, whereas if we choose a dets table,
+ the cookies will survive daemon restarts. What to choose depends on the
+ type of cookie information we have.
+ </p>
+
+ <p>
+ The yaws code in
+ <a href="setpcookie.yaws">setpcookie.yaws</a> sets the cookie in the browser.
+ </p>
+
+ <p>And the yaws code in <a href="readpcookie.yaws">readpcookie.yaws</a>
+ will read the cookie
+ </p>
+
+ <p>
+ Let's show some code. To set the cookie we we have:
+ </p>
<erl>
out(A) -> yaws_api:pre_ssi_files(A#arg.docroot, ["setpcookie.yaws"]).
@@ -33,6 +37,7 @@ out(A) -> yaws_api:pre_ssi_files(A#arg.docroot, ["setpcookie.yaws"]).
<p>
And to read the cookie, we have the following code:
+</p>
<erl>
out(A) -> yaws_api:pre_ssi_files(A#arg.docroot, ["readpcookie.yaws"]).
View
80 www/query.yaws
@@ -10,35 +10,37 @@ out(A) ->
<h2>The query part of the url</h2>
-<p>
-A url can have an optional query part. This part is passed in
-the A#arg.querydata which is passed as an argument to the
-out/1 function.
-
-<p>We show how to work with the query part of the url through
-an example, if we have a URL on the form of
-<a href="man.yaws?page=cat">http://yaws.hyber.org/man.yaws?page=cat</a>
-a key/value pair is passed to the page.
-In the above example, we have key=page and its value "cat".
-The code in the page man.yaws, will read these key/value pairs
-in the A#arg.querydata and display the man page.
-
-Assuming a predifined CSS class called box, defined as:
-
-<div class="box"
-<pre>
-div.box { border: solid; border-width: thin; width: 90%;
- background: rgb(211, 211, 211) }
-</pre>
-</div>
-
-<p>
-The following code:
-
-<erl>
-
-out(A) ->
- {ehtml,ssi("man.yaws")}.
+ <p>
+ A url can have an optional query part. This part is passed in
+ the A#arg.querydata which is passed as an argument to the
+ out/1 function.
+ </p>
+
+ <p>We show how to work with the query part of the url through
+ an example, if we have a URL on the form of
+ <a href="man.yaws?page=cat">http://yaws.hyber.org/man.yaws?page=cat</a>
+ a key/value pair is passed to the page.
+ In the above example, we have key=page and its value "cat".
+ The code in the page man.yaws, will read these key/value pairs
+ in the A#arg.querydata and display the man page.</p>
+
+ <p>
+ Assuming a predifined CSS class called box, defined as:</p>
+
+ <div class="box">
+ <pre>
+ div.box { border: solid; border-width: thin; width: 90%;
+ background: rgb(211, 211, 211) }
+ </pre>
+ </div>
+
+ <p>
+ The following code:</p>
+
+ <erl>
+
+ out(A) ->
+{ehtml,ssi("man.yaws")}.
ssi(File) ->
{'div',[{class,"box"}],
@@ -49,29 +51,29 @@ ssi(File) ->
<p> will display a man page if invoked with a proper key/value
-pair in the query part of the URL.
+ pair in the query part of the URL.</p>
<p> This fairly convenient way of getting at the query (or POST)
-is equivalent of the code:
+ is equivalent of the code:</p>
<div class="box">
-<pre>
-P = yaws_api:parse_query_data(A),
-L = case lists:keysearch(page, 1, P) of
- {value, {page, Page}} ->
- .....
+ <pre>
+ P = yaws_api:parse_query_data(A),
+ L = case lists:keysearch(page, 1, P) of
+ {value, {page, Page}} ->
+ .....
</pre>
</div>
<p>The querypart of the URL is part as field in the Arg structure.
-The function <tt>parse_query/1</tt> parses the raw data into
-a key/value list.
+ The function <tt>parse_query/1</tt> parses the raw data into
+ a key/value list. </p>
<p>The <tt>queryvar(ARG,Key)</tt> function returns the value of the
variable if it is found in the query part of the request. If the variable is not found
or if the variable is unset, the <tt>queryvar(ARG,Key)</tt> function returns <tt>undefined</tt>.
-
+</p>
</div>
View
8 www/readpcookie.yaws
@@ -14,16 +14,16 @@ out(A) ->
[] ->
f("<p> No cookie set from the browser, need to "
"visit <a href=\"setpcookie.yaws\">setpcookie.yaws</a> "
- "to set the cookie first ~n", []);
+ "to set the cookie first </p>~n", []);
NumStr ->
Num = to_integer(NumStr),
case ets:lookup(pcookies, {cookie,Num}) of
[{{cookie, Num}, Data}] ->
f("<p> Yes, I read your cookie:it is ~p~n "
"Your persistent info is ~n"
- "<pre>~n~p~n</pre>~n", [NumStr, Data]);
+ "<pre>~n~p~n</pre> </p>~n", [NumStr, Data]);
[] ->
- f("<p> You had a cookie,but the data is gone",[])
+ f("<p> You had a cookie,but the data is gone </p>",[])
end
end,
{html, L}.
@@ -34,7 +34,7 @@ out(A) ->
<p>
The code to read the cookie, is simple, we get the cookie passed to the yaws
code in the #arg structure which is the argument supplied to the out/1 function.
-The code is:
+The code is:</p>
<erl>
out(A) ->
View
73 www/redirect.yaws
@@ -8,17 +8,18 @@ out(A) ->
<div id="entry">
-<h2>Redirects</H2>
+<h2>Redirects</h2>
-<p> Redirs are a powerful tool in the webapp programmer toolbox. The
-Webserver returns a specific status code (302) and adds a "Location:" header
-to the responce headers to the Browser. The Browser then displays the new
-page as indicated in the "Location" header.
+ <p> Redirs are a powerful tool in the webapp programmer toolbox. The
+ Webserver returns a specific status code (302) and adds a
+ "Location:" header
+ to the responce headers to the Browser. The Browser then displays the new
+ page as indicated in the "Location" header.</p>
-<p> Yaws supports a number of different forms of redirect return values
-from the out/1 function.
-
-The code:
+ <p> Yaws supports a number of different forms of redirect return values
+ from the out/1 function.</p>
+ <p>
+ The code:</p>
<erl>
out(_A) ->
@@ -29,14 +30,15 @@ out(_A) ->
</erl>
<p> Clickable <a href="redirect2.yaws"> On this link </a> executes the
-above redirect code.
+ above redirect code.</p>
<p> The code above redirects to an external URL. The HTTP RFC mandates
-that the Loaction header must contain complete URLs, including the
-the method, http, https etc. A very common case of redirection, is
-a to redirect to another file on the same server. The code
-in <a href="redirect3.yaws"> redirect3.yaws </a> shows an example of
-a yaws redirect relative to the "current" server.
+ that the Loaction header must contain complete URLs, including the
+ the method, http, https etc. A very common case of redirection, is
+ a to redirect to another file on the same server. The code
+ in <a href="redirect3.yaws"> redirect3.yaws </a> shows an example of
+ a yaws redirect relative to the "current" server.
+</p>
<erl>
out(_A) ->
@@ -48,12 +50,15 @@ out(_A) ->
<p> The code in <a href="redirect3.yaws"> redirect3.yaws </a> will
-do a relative redirect to the code in
-<a href="redirect2.yaws"> redirect2.yaws </a> which in its turn redirects, once again, to google. Double redirects.
+ do a relative redirect to the code in
+ <a href="redirect2.yaws"> redirect2.yaws </a> which in its turn
+ redirects, once again, to google. Double redirects.
+</p>
<p>While working with redirects, the tool <a href="http://curl.haxx.se/">
-curl </a> is an excellent way to troubleshoot the behaviour of your redirects.
-For example:
+ curl </a> is an excellent way to troubleshoot the behaviour of your
+ redirects.
+ For example:</p>
<div class="box">
<pre>
@@ -67,20 +72,20 @@ Content-Type: text/html
<pre>
</div>
-<p>Where <tt> http://rubin.hyber.org:8000</tt> is where I am currently
-testing the <a href="redirect3.yaws"> redirect3.yaws </a> code.
-Learn and use the <a href="http://curl.haxx.se/"> curl </a>
-web client, it may not render pictures pretty, but it sure displays
-headers.
-
-<br>
-
-<p> We show one additional version of redirect code. The code in
-<a href="redirect3.yaws"> redirect3.yaws </a> requires an absolute path.
-If we want to supply a path relative to the current url, we can use
-either the Redirect modifier <tt>rel_path</tt> or <tt>any_path</tt>
-as in :
-
+ <p>Where <tt> http://rubin.hyber.org:8000</tt> is where I am currently
+ testing the <a href="redirect3.yaws"> redirect3.yaws </a> code.
+ Learn and use the <a href="http://curl.haxx.se/"> curl </a>
+ web client, it may not render pictures pretty, but it sure displays
+ headers.
+ </p>
+ <br />
+
+ <p> We show one additional version of redirect code. The code in
+ <a href="redirect3.yaws"> redirect3.yaws </a> requires an absolute path.
+ If we want to supply a path relative to the current url, we can use
+ either the Redirect modifier <tt>rel_path</tt> or <tt>any_path</tt>
+ as in :
+ </p>
<erl>
out(_A) ->
@@ -91,7 +96,7 @@ out(_A) ->
</erl>
<p> <a href = "redirect4.yaws"> Clickable here </a>
-
+</p>
</div>
View
10 www/session.yaws
@@ -11,12 +11,16 @@ out(A) ->
The Yaws session server is ideal (and recommended)
for maintaining cookie state
in a server side application.
+</p>
-The code in <a href="code.yaws?file=/session1.yaws">session1.yaws</a>
-shows a minimalistic way to handle sessions.
-To run it click <a href="session1.yaws">here</a>
+<p>The code in <a href="code.yaws?file=/session1.yaws">session1.yaws</a>
+ shows a minimalistic way to handle sessions.
+ To run it click <a href="session1.yaws">here</a>
+</p>
+<p>
The actual session API is documented in the man page for yaws_api.
+</p>
</div>
View
9 www/ssi.yaws
@@ -98,17 +98,14 @@ out(A) ->
}
}
].
-
-
-
-
-
</erl>
-</html>
+<erl>
+out(A) -> {ssi, "END2",[],[]}.
+</erl>
View
8 www/upload.yaws
@@ -2,10 +2,10 @@
<h2> File upload </h2>
-<p>This page shows how to upload a file to the webserver, nothing of cource
-does actually gets written to disc, but the upload code is
-<a href="code.yaws?file=/upload.yaws"> Here in file upload.yaws </a>
-
+ <p>This page shows how to upload a file to the webserver, nothing of cource
+ does actually gets written to disc, but the upload code is
+ <a href="code.yaws?file=/upload.yaws"> Here in file upload.yaws </a>
+ </p>
<erl>
View
4 www/upload0.yaws
@@ -14,8 +14,8 @@ out(A) ->
{method, post},
{action, "/upload.yaws"}
],
- [{input, [{type, submit}, {value, "Upload"}]},
- {input, [{type,file}, {width, "50"}, {name, foo}]}
+ [{input, [{type, submit}, {value, "Upload"}] ,[]},
+ {input, [{type,file}, {width, "50"}, {name, foo}], []}
]}]}}},
{ssi, "END2",[],[]}].
Please sign in to comment.
Something went wrong with that request. Please try again.