Discussion:
[Wt-interest] Can't get docroot ";" syntax to work
K. Frank
2016-07-11 14:24:36 UTC
Permalink
Hello List!

I am building my app to be a wthttpd server. When I start it from the
command line, I pass it the --docroot argument, for example, as:

mixed_links --http-address=0.0.0.0 --http-port=80
--deploy-path=/mixed_links --docroot=".;/static_links"

(I have tried several variations of this.)

This is on windows with a mingw-w64-built wt-3.3.3.

As I understand it, this should tell wthttpd to look for static content in the
current working directory (the directory from which my app, mixed_links.exe,
was launched) and the "static_links" subdirectory of the current working
directory.

My problem is that I can't get wthttpd to use anything after the ";" in the
docroot argument.

Two points:

First, I have tried lots of variations with both directories and files, and
wthttpd can only server static html files that are in the single docroot
directory that appears before the ";".

Second, I print out WApplication::docRoot() when my WApplication is
instantiated, and that only gives me the part of the docroot argument
that comes before the ";".

So, I am quite confused.

Is this how docroot is supposed to work? Including on windows? Is
docroot thought (or known) to work, including on windows? Are there
any know docroot bugs in version 3.3.3?


Thanks for any help.


K. Frank
Koen Deforche
2016-07-11 15:06:04 UTC
Permalink
Hey,
Post by K. Frank
Hello List!
I am building my app to be a wthttpd server. When I start it from the
mixed_links --http-address=0.0.0.0 --http-port=80
--deploy-path=/mixed_links --docroot=".;/static_links"
In this call, --docroot=".;/static_links" is equivalent to --docroot=".".

The ';/path1,/path2,.." syntax is only used to get rid of so-called "ugly
internal path URLs" that are encoded as a query argument
'?_=/internal/path'. This is used in Wt only if you're deploying on a path
that ends itself with a '/', for example --deploy-path=/mixed_links/ or the
default --deploy-path='/'. In that case it is used to be able to use
nice-looking internal paths (/internal/path) while still knowing which
paths ('/static_links') to have handled by the static file server of
wthttpd. If the application is not deployed ending with a '/' then there is
no ambiguity in the first place.

Since you are not having ugly internal paths to start with (you may even
not be using them?), you probably want something different, but from your
explanation I'm not exactly sure what. The docroot directive is really
similar to the 'docroot' as you would configure them in any other webserver
such as apache or nginx.

Admittedly, it's a common, recurring, confusing topic all-together.

Koen
K. Frank
2016-07-11 17:36:59 UTC
Permalink
Hi Koen!
Post by Koen Deforche
Hey,
Post by K. Frank
Hello List!
I am building my app to be a wthttpd server. When I start it from the
mixed_links --http-address=0.0.0.0 --http-port=80
--deploy-path=/mixed_links --docroot=".;/static_links"
In this call, --docroot=".;/static_links" is equivalent to --docroot=".".
Thank you for your reply.

Some follow up questions:

Is the following true? If the deploy-path does not end in "/", then the ";"
docroot syntax does nothing. That is, the ";" and anything after it is
effectively ignored.

Is it true -- regardless of whether deploy-path ends in "/" -- that
WApplication::docRoot() only returns the part of the --docroot
command-line argument that appears before the ";"? In a similar
vein, does Wt provide a public api that gives the part of docroot
after the ";" (or the whole docroot string)?
Post by Koen Deforche
The ';/path1,/path2,.." syntax is only used to get rid of so-called "ugly
internal path URLs" that are encoded as a query argument
'?_=/internal/path'. This is used in Wt only if you're deploying on a path
that ends itself with a '/', for example --deploy-path=/mixed_links/ or the
default --deploy-path='/'. In that case it is used to be able to use
nice-looking internal paths (/internal/path) while still knowing which paths
('/static_links') to have handled by the static file server of wthttpd. If
the application is not deployed ending with a '/' then there is no ambiguity
in the first place.
I don't know whether I care about using a deploy-path the ends in "/",
and avoiding ugly paths sounds good. But, regardless, I am trying to
understand what is going on.

I *think* I have "--deploy-path=/" working the way you describe, but,
for the life of me, I can't get "--deploy-path=/mixed_links/" to work
with the ";" syntax the way I imagine it might.

Let me summarize my set up: I have a subdirectory of my current
working directory called static_links. In it is a file, say, link1.html. If
I deploy as "--deploy-path=/mixed_links/", a link (that evaluates) to:

http://localhost/static_links/link1.html

links to the file successfully whether or not I use ";". That is, both
"--docroot="."" and "--docroot'".;/static_links"" work the same way,
in that wthttpd serves link1.html as static content.

On the other hand, a link (that evaluates) to:

http://localhost/mixed_links/static_links/link1.html

does not successfully link to the file. The ";" syntax does have an
effect, however. If I deploy with "--docroot="."", the above link returns
a 404, while if I deploy with "--docroot=.;/static_links", the above link
gets processed as an internal path in my application (but wthttpd does
not serve the link1.html file as static content).

So I don't see how to use ";" in this case. (One version of the link works
with or without the ";", while the other version of the link does not work,
with or without the ";".)
Post by Koen Deforche
Since you are not having ugly internal paths to start with (you may even not
be using them?), you probably want something different, but from your
explanation I'm not exactly sure what.
Well, right now, I am just trying to understand how things work. (Right now,
I'm playing around, but my "learning goal" would be to serve a web site with
wthttpd at "http://hostname/" or, if necessary, "http://hostname/app_name"
and have both internal-path links and static-content links underneath that
top-level "landing page," e.g., "http://hostname/internal_path_link1" and
"http://hostname/static_content_link".)

Just to be clear, I may be trying to do something that wthttpd doesn't do
(or doesn't do without some sort of hackery). That's okay, too. I just
want to understand what wthttpd (and Wt in general) does do, and, then,
how to do it.
Post by Koen Deforche
The docroot directive is really
similar to the 'docroot' as you would configure them in any other webserver
such as apache or nginx.
Well, the only webserver I have experimented with in any detail in wthttpd, so
I haven't been able to take much guidance from "standard practice."
Post by Koen Deforche
Admittedly, it's a common, recurring, confusing topic all-together.
And, admittedly, I am recurringly confused ...

I apologize for my confusion, but perhaps a few more words of explanation
about --docroot, its ";" syntax, and how they interact with --deploy-path might
help clear things up in part for me.
Post by Koen Deforche
Koen
Thanks again for your helpful explanations.


K. Frank
Koen Deforche
2016-07-12 07:52:35 UTC
Permalink
Hey,
Post by K. Frank
Is the following true? If the deploy-path does not end in "/", then the ";"
docroot syntax does nothing. That is, the ";" and anything after it is
effectively ignored.
Perhaps that statement wasn't as accurate: if the deploy-path does not end
with "/" I should have said, this not (as) useful, but it's not ignored.
Every path "/this/that" that follows ';' is interpeted as: requests for
"/this/that/*file.png*" are to be interpreted as a request for a static
file, to be retrieved from within the docroot. The path within the docroot
must then be "/this/that/..." (thus if docroot = ".", then the webserver
will try to read "./this/that/*file.png*".
Post by K. Frank
Is it true -- regardless of whether deploy-path ends in "/" -- that
WApplication::docRoot() only returns the part of the --docroot
command-line argument that appears before the ";"? In a similar
vein, does Wt provide a public api that gives the part of docroot
after the ";" (or the whole docroot string)?
Yes. Because the ';' acts as a qualifier for wthttpd to decide what files
to look for in the docroot.
Post by K. Frank
Let me summarize my set up: I have a subdirectory of my current
working directory called static_links. In it is a file, say, link1.html.
If
http://localhost/static_links/link1.html
links to the file successfully whether or not I use ";". That is, both
"--docroot="."" and "--docroot'".;/static_links"" work the same way,
in that wthttpd serves link1.html as static content.
True.
Post by K. Frank
http://localhost/mixed_links/static_links/link1.html
does not successfully link to the file. The ";" syntax does have an
effect, however. If I deploy with "--docroot="."", the above link returns
a 404, while if I deploy with "--docroot=.;/static_links", the above link
gets processed as an internal path in my application (but wthttpd does
not serve the link1.html file as static content).
Not quite so:
- with "--deploy-path=/mixed_links/ --docroot="."", Wt will interpret this
request as an internal path (as it matches the deploy-path of an
application)
- with "--deploy-path=/mixed_links/ --docroot=.;/static_links", just the
same because '/mixed_links/static_links/' does not match '/static_links'
- with "--deploy-path=/mixed_links/ --docroot=.;/mixed_links/static_links",
the request will be interpreted as request for a static file within docroot.
Post by K. Frank
Well, right now, I am just trying to understand how things work. (Right now,
I'm playing around, but my "learning goal" would be to serve a web site with
wthttpd at "http://hostname/" or, if necessary, "http://hostname/app_name"
and have both internal-path links and static-content links underneath that
top-level "landing page," e.g., "http://hostname/internal_path_link1" and
"http://hostname/static_content_link".)
Just to be clear, I may be trying to do something that wthttpd doesn't do
(or doesn't do without some sort of hackery). That's okay, too. I just
want to understand what wthttpd (and Wt in general) does do, and, then,
how to do it.
I think Wt is quite flexible in terms of URL handling (in spite of being
unconventional).

I hope the clarifications help.

Regards,
koen
K. Frank
2016-07-12 18:39:45 UTC
Permalink
Hi Koen!
Post by Koen Deforche
Hey,
...
Post by K. Frank
Let me summarize my set up: I have a subdirectory of my current
working directory called static_links. In it is a file, say, link1.html.
...
http://localhost/mixed_links/static_links/link1.html
does not successfully link to the file. The ";" syntax does have an
effect, however. If I deploy with "--docroot="."", the above link returns
a 404, while if I deploy with "--docroot=.;/static_links", the above link
gets processed as an internal path in my application (but wthttpd does
not serve the link1.html file as static content).
- with "--deploy-path=/mixed_links/ --docroot="."", Wt will interpret this
request as an internal path (as it matches the deploy-path of an
application)
This isn't what I see -- I've tried to repeat the test quite carefully.

As far as I can tell, the link:

http://localhost/mixed_links/static_links/link1.html

is not interpreted as an internal path.

(Actually, I used http://localhost/mixed_links/static_links/sl1.html
in my test, as you will see in the notes, below.)

I really do get a 404. (I've tried this both on ie and opera.) I also
log WApplication::internalPathChanged(), and it doesn't fire when
I click on the link.

Before I launch into the details, let me mention again that my Wt
installation is wt-3.3.3, and both it and my Wt application were built
with mingw-w64 on 64-bit windows 7.


Here are some more detailed notes of my test:

First, here's what happens:

enter "landing page" link in browser
http://localhost/mixed_links/
--> home page (built by my WApplication code)

click on
link to sl1 (as /mixed_links/static_links/sl1.html)
http://localhost/mixed_links/static_links/sl1.html (<-- how it
appears in browser's address entry)
--> 404

browser back button
--> back to home page

click on
link to ip1
http://localhost/mixed_links/?_=/internal_paths/ip1 (<-- how it
appears in browser's address entry)
--> internalPathChanged fires, and my code displays the ip1 page
(As I understand it, I get the "?_=" in the link because my
deploy-path ended in "/".)


Some relevant code snippets from my WApplication:

class MixedLinksApp : public WApplication {
public:
MixedLinksApp (const WEnvironment& env) : WApplication (env) {
cout << "MixedLinksApp::MixedLinksApp ..." << endl;
internalPathChanged().connect (this,
MixedLinksApp::onInternalPathChanged);
makePage (true);
}
void onInternalPathChanged() {
cout << "onInternalPathChanged ..." << endl; // <-- log all
internalPathChanged() signals
makePage (false);
}
void makePage (bool newApp) {
cout << "makePage: newApp = " << newApp << endl;
cout << " appRoot() = " << appRoot() << endl;
cout << " docRoot() = " << docRoot() << endl;

// ...

// *** here's where I create the internal-path ip1 link
t = new WText ("link to <a href='#/internal_paths/ip1'>ip1</a>");
t->setInternalPathEncoding (true);

// *** here's where I create the static-content sl1 link
t = new WText ("link to <a
href='/mixed_links/static_links/sl1.html'>sl1</a> (as
/mixed_links/static_links/sl1.html)");
// t->setInternalPathEncoding (true); <-- I tried both way;
setInternalPathEncoding didn't matter


Lastly, here's the console log. This is both what Wt writes out itself,
and the output from the cout calls in my code. Note that clicking the
ip1 link causes my code to log (and process) the internalPathChanged()
signal, whereas clicking on the sl1 link does not seem to cause the
internalPathChanged() signal to fire. Also, Wt's logging does seem to
show Wt issuing a 404 for the sl1 link.

C:\test>mixed_links --http-address=0.0.0.0 --http-port=80
--deploy-path=/mixed_links/ --docroot="."
Option no-compression is implied because wthttp was built without
zlib support.
[2016-Jul-12 10:50:04.885049] 9916 - [info] "config: reading Wt
config file: c:/witty/wt_config.xml (location = 'mixed_links')"
Option no-compression is implied because wthttp was built without
zlib support.
[2016-Jul-12 10:50:04.885049] 9916 - [info] "WServer/wthttp:
initializing built-in wthttpd"
[2016-Jul-12 10:50:04.885049] 9916 - [info] "wthttp: started
server: http://0.0.0.0:80"
[2016-Jul-12 10:50:23.599482] 9916 - [info] "Wt: session created
(#sessions = 1)"
[2016-Jul-12 10:50:23.599482] 9916 [/mixed_links/ UhtrN8ZHQZnqsFS8]
[info] "WEnvironment: UserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64;
Trident/7.0;
MALC; rv:11.0) like Gecko"
127.0.0.1 - - [2016-Jul-12 10:50:23.599482] "GET /mixed_links/
HTTP/1.1" 200 4665
[2016-Jul-12 10:50:23.599482] 9916 - [info] "WebRequest: took 0ms"
MixedLinksApp::MixedLinksApp ...
[2016-Jul-12 10:50:23.713682] 9916 [/mixed_links/ UhtrN8ZHQZnqsFS8]
[warning] "WApplication: Deploy-path ends with '/', using /?_= for
internal paths"

makePage: newApp = 1
appRoot() =
docRoot() = .
environment().deploymentPath() = /mixed_links/
environment().internalPath() =
internalPath() = /
url() = /mixed_links/?wtd=UhtrN8ZHQZnqsFS8
bookmarkUrl() = ?
127.0.0.1 - - [2016-Jul-12 10:50:23.718682] "GET
/mixed_links/?wtd=UhtrN8ZHQZnqsFS8&request=style HTTP/1.1" 200 116
[2016-Jul-12 10:50:23.718682] 9916 - [info] "WebRequest: took 103.6ms"
127.0.0.1 - - [2016-Jul-12 10:50:23.718682] "GET
/mixed_links/resources/themes/default/wt.css HTTP/1.1" 404 85
127.0.0.1 - - [2016-Jul-12 10:50:23.718682] "GET
/mixed_links/?wtd=UhtrN8ZHQZnqsFS8&sid=-466592228&webGL=true&tz=-240&htmlHistory=true&deployPath=%2Fm
ixed_links%2F&request=script&rand=3300683377 HTTP/1.1" 200 105778
1[27.0.0.1 - - [2016-Jul-12 10:50:23.718682] "GET
/mixed_links/resources/transitions.css HTTP/1.1" 404 852016-Jul-12
10:50:23.718682] 9916 - [info] "W
ebRequest: took 5ms"

127.0.0.1 - - [2016-Jul-12 10:50:23.874184] "POST
/mixed_links/?wtd=UhtrN8ZHQZnqsFS8 HTTP/1.1" 200 30
[2016-Jul-12 10:50:23.876684] 9916 - [info] "WebRequest: took 5ms"
127.0.0.1 - - [2016-Jul-12 10:51:07.529267] "GET
/mixed_links/static_links/sl1.html HTTP/1.1" 404 85
onInternalPathChanged ...
makePage: newApp = 0
appRoot() =
docRoot() = .
environment().deploymentPath() = /mixed_links/
environment().internalPath() =
internalPath() = /internal_paths/ip1
url() = /mixed_links/?wtd=UhtrN8ZHQZnqsFS8
bookmarkUrl() = ?_=/internal_paths/ip1
127.0.0.1 - - [2016-Jul-12 10:52:22.178807] "POST
/mixed_links/?wtd=UhtrN8ZHQZnqsFS8 HTTP/1.1" 200 1838
[2016-Jul-12 10:52:22.178807] 9916 - [info] "WebRequest: took 0ms"


Please let me know if you see anything suspicious or unexpected
in the above. Again, this is not a problem for me -- I don't mind
the 404. I'm just experimenting, and trying to understand how Wt
works and how to use it.
Post by Koen Deforche
I think Wt is quite flexible in terms of URL handling (in spite of being
unconventional).
I hope the clarifications help.
Yes, thanks very much.
Post by Koen Deforche
Regards,
koen
Best regards.


K. Frank
Koen Deforche
2016-07-18 10:49:47 UTC
Permalink
Hey,
Post by K. Frank
Post by Koen Deforche
Post by K. Frank
http://localhost/mixed_links/static_links/link1.html
does not successfully link to the file. The ";" syntax does have an
effect, however. If I deploy with "--docroot="."", the above link
returns
Post by Koen Deforche
Post by K. Frank
a 404, while if I deploy with "--docroot=.;/static_links", the above
link
Post by Koen Deforche
Post by K. Frank
gets processed as an internal path in my application (but wthttpd does
not serve the link1.html file as static content).
- with "--deploy-path=/mixed_links/ --docroot="."", Wt will interpret
this
Post by Koen Deforche
request as an internal path (as it matches the deploy-path of an
application)
This isn't what I see -- I've tried to repeat the test quite carefully.
Sorry, I was wrong indeed, you're initial statement is correct. Although
the path matches the deploy-path, the request is application will use 'ugly
internal paths' and thus interpret this path as a static file request
instead.
Post by K. Frank
Post by Koen Deforche
I hope the clarifications help.
Yes, thanks very much.
Even though they were not clarifying ;-)
Still, are things now still unclear?

Regards,
koen

Loading...