Wt

Hey,

That does look like it behaves as expected:

Perhaps you would like resourcesURL to be "/resources/" instead of "resources/" ?

Regards,

koen

Hello,

Setting resourcesURL to "/resources/" did not help.

Regards.

Hey,

That does not make sense then: "/resources/..." is an absolute path and this will result in the browser doing a GET for "/resources/..." which should then be handled by nginx. Are you positive the new property value is being used? You can also print its value, WApplication::resourcesUrl()

Regards,

koen

Hello!

That does not make sense then: "/resources/..." is an absolute path and this will result in the browser doing a GET for "/resources/..." which should then be handled by nginx.

Nginx hosts resources under http://site/abc/resources/, not http://site/resources/.

Application is deployed under http://site/abc/.

So the goal is to make the browser load resources from http://site/abc/resources/.

It would be pretty, if this sub-location (http://site/abc/) were configured in nginx config only, not in wt config.

Since Wt uses relative paths, it should not need this sub-location.

Regards.

Hey,

That still doesn't make sense though: if your application is deployed at "/abc/" then "resources/" should really take you to "/abc/resources/"

Are you sure you are deploying at "/abc/" and not "/abc", since the trailing slash does not make difference ?

Regards,

koen

Hello!

I've tried different variants and all of them failed:

location /abc {
    fastcgi_pass 127.0.0.1:5711;
    fastcgi_split_path_info ^(/abc)(.*)$;
    include fastcgi_params;
    fastcgi_param PATH_INFO $fastcgi_path_info;
}

location /abc/ {
    fastcgi_pass 127.0.0.1:5711;
    fastcgi_split_path_info ^(/abc)(.*)$;
    include fastcgi_params;
    fastcgi_param PATH_INFO $fastcgi_path_info;
}

location /abc/ {
    fastcgi_pass 127.0.0.1:5711;
    fastcgi_split_path_info ^(/abc/)(.*)$;
    include fastcgi_params;
    fastcgi_param PATH_INFO $fastcgi_path_info;
}

location /abc/ {
    fastcgi_pass 127.0.0.1:5711;
    fastcgi_split_path_info ^(/abc/)(.*)$;
    include fastcgi_params;
    fastcgi_param PATH_INFO /$fastcgi_path_info;
}

The last one seems to be true, but it is the worst:

it tries to load not only images, but entire application from / instead of /abc/.

Could you provide working tutorial for running Wt fcgi application behind

nginx, using sub-location (/abc/) (affecting nginx side only), please ?

Best Regards.

You should use in wt_config.xml:

http://site/abc/

Remember to put last slash at the and. Then your resources will be loaded as expected.

resources

BR,

Lukasz Matuszewski

Thank you Lukasz Matuszewski!

Suggested configuration of Wt works.

(resourcesURL is set to resources/ instead of resources: both of them work, but resources/ is the default.)

Is there any way not to hardcode http://site/abc/ in Wt config?

IMHO, url scheme, domain name and url prefix should be settings of web server, not of web application.

For example, if I want to deploy the same application both on http and https, it would be impossible,

if url scheme were specified in config of web application.

So it would be better to find a way of configuring it using nginx config, not wt config.

BR.

There should be WApplication->setBaseURL(std::string baseURL) which will be rendered as tag in corresponding pages. For now there is no simple way to do it or i do not know how to do it. Believe i tried different scenarios.

So it should be a feature request which will not be difficult to achieve.

Best regards

Lukasz Matuszewski

You could also provide relative paths that starts from the root directory of you web server (without specifying baseURL).

I have in my wt_config.xml something like this:

    <application-settings location="absolute_path_to_your_fastcgi_application">
      <properties>
        <property name="resourcesURL">/abc/resources</property>
        <property name="extBaseURL">/abc/ext</property>
        <property name="favicon">/abc/favicon.ico</property>
      </properties>
    </application-settings>

For me it just works...

There is no baseURL so this solution is not tied to any of scheme used (http/https).

BR,

Lukasz Matuszewski

Sorry... to be fully functional you must include baseURI property, so in you example it will look like:

<application-settings location="absolute_path_to_your_fastcgi_application">
  <properties>
    <property name="baseURL">/abc/</property>
    <property name="resourcesURL">/abc/resources</property>
    <property name="extBaseURL">/abc/ext</property>
    <property name="favicon">/abc/favicon.ico</property>
    </properties>
  </application-settings>

Here i just putted /abc/ so it resolves to whatever scheme you will use (http/https).

I know it should be absolute url like docs says in wt_config.xml, but it works for me with WAnchor without url set but only set with WResource (so url of WAnchor will be generated on the fly by wt library).

I would like to here from Wt developers what they think about:

...
    <property name="baseURL">/abc/</property>
...

since it is not absolute url, but it seems to work with my WAnchor.

For example without baseURL i will have WAnchor with something like this: http://site/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48 (so you see there is no /abc/ part in url which is wrong, because the link doesn't points to my deployed app).

With baseURL set to /abc/ i have WAnchor like this: http://site/abc/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48 (which is good, because it point to my web fastcgi app that is /abc/my_name_of_wt_fcgi_app.wt).

BR,

Lukasz Matuszewski

Hey,

I think there is some confusion though. The static files should all be served directly by the web server --- the only thing that is served by the FastCGI application is the application itself.

Thus, if you put a FastCGI handler for "/abc" and everything below, then you cannot host your resources, images, etc... within "/abc", unless you add another handler that precedes it specifically for these resources. Perhaps this is the reason of debate ?

Regards,

koen

From my point of understanding every FastCGI application should have their own resources (which is served by web server). So if you put your FastCGI App.wt under /abc directory in web server (that is in example /var/www/abc/App.wt - where /var/www is your DocumentRoot), you could put there the resources for that specific FastCGI resources. It is obvious... that is my point of view.

What really matters for me is a specific setting in wt_config.xml, that is:

...
    <property name="baseURL">/abc/</property>
...

which really works for me (so this fastcgi app could be served secured (https) or plain (http)). My confusion is that it renders as i expect, that is . But it worries me, because of

    std::string Wt::WApplication::resolveRelativeUrl    (   const std::string &     url )   const

which tries to resolve relative url.

So my question is if it will work like in browsers ? That is, will it resolve to actual scheme, server and port used to access the FastCGI app.

I think also that WApplication::setBaseURL(std::string url), should be present in API of wt library... but it is my own opinion... i am not developer of Wt library (but i have desire to be).

Hope to see answer soon,

Lukasz Matuszewski

Hello,

IMHO, fastcgi application should not know scheme, hostname and base url (it is business of webserver). At least, it should not use them while generating urls for GET by browser. (However scheme, hostname and base url can be needed to generate absolute urls for external usage (ie to show link to user, etc...). But FastCGI protocol itself can tell web-application it's scheme, hostname and base url.)

that is in example /var/www/abc/App.wt - where /var/www is your DocumentRoot

IMHO, DocumentRoot (similar to ---docroot option) should be /var/www/abc/, since you can have several Wt applications. If several applications are using same paths (like /img/, /css/), it can result in name collision.

Also, an application deployed under /abc/, should use /abc/img/ and /abc/resouces/ (not /img/ and /resources/), ie all urls, used by application, should be inside /abc/.

i am not developer of Wt library (but i have desire to be).

I too :)

BR.

Hello,

Let me provide little example about FastCGI parameters. For example, http://site/abc/user/ is requested.

fastcgi_split_path_info ^(/abc)(.*)$; tells nginx set $fastcgi_script_name = /abc and $fastcgi_path_info = /user/.

fastcgi_params 
fastcgi_param   QUERY_STRING            $query_string;
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;

fastcgi_param   SCRIPT_FILENAME         $document_root$fastcgi_script_name;
fastcgi_param   SCRIPT_NAME             $fastcgi_script_name;
fastcgi_param   REQUEST_URI             $request_uri;
fastcgi_param   DOCUMENT_URI            $document_uri;
fastcgi_param   DOCUMENT_ROOT           $document_root;
fastcgi_param   SERVER_PROTOCOL         $server_protocol;

fastcgi_param   GATEWAY_INTERFACE       CGI/1.1;
fastcgi_param   SERVER_SOFTWARE         nginx/$nginx_version;

fastcgi_param   REMOTE_ADDR             $remote_addr;
fastcgi_param   REMOTE_PORT             $remote_port;
fastcgi_param   SERVER_ADDR             $server_addr;
fastcgi_param   SERVER_PORT             $server_port;
fastcgi_param   SERVER_NAME             $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param   REDIRECT_STATUS         200;


fastcgi_param PATH_INFO $fastcgi_path_info;

So SCRIPT_NAME = /abc and PATH_INFO = /user/.

Parameters SCRIPT_FILENAME, DOCUMENT_URI, DOCUMENT_ROOT and REQUEST_URI are not used by Wt, are they?

What FastCGI parameters are used as base url and as base url for documents?

BR.

Hello,

IMHO, fastcgi application should not know scheme, hostname and base url

It should have access to these parameters, for example to generate absolute urls. Wt uses own resolver:

  std::string Wt::WApplication::resolveRelativeUrl     (     const std::string &      url )     const

which must know (this function or maybe WApplication object) the scheme, hostname, and base url.

that is in example /var/www/abc/App.wt - where /var/www is your DocumentRoot

IMHO, DocumentRoot (similar to ---docroot option) should be /var/www/abc/, since you can have several Wt applications. If several applications are using same paths (like /img/, /css/), it can result in name collision.

I think it depends. My thinking of it is... ONE DOCUMENT ROOT, AND SERVERAL FASTCGI APPS UNDER DIFFERENT DIRECTORIES UNDER DOCUMENT ROOT (Just like One ring to rule them all :) ). You can see that under DOCUMENT ROOT you can have base for all resources (that is images, css, swf etc). And you can have different resources per fastcgi app under different directories... And in this case the:

  WApplication::setBaseURL(std::string url);

will help (so you could use:

const std::string& Wt::WEnvironment::hostName   (    )  const;
const std::string& Wt::WEnvironment::urlScheme () const;

)

PS under Apache web server you can have only one DocumentRoot per VirtualHost, so it is the main reason of my configuration presented above.

BR

Lukasz Matuszewski

Hey Lukas,

>It should have access to these parameters, for example to generate absolute urls. Wt uses own resolver:

std::string Wt::WApplication::resolveRelativeUrl ( const std::string & url ) const

which must know (this function or maybe WApplication object) the scheme, hostname, and base url.

Actually, that isn't the case. The resolveRelativeUrl will use "../../path" to resolve a relative URL against the correct location, without needing to know absolute URLs.

If you do not call makeAbsoluteUrl() yourself, and do not specify a baseURL property, then Wt will never create absolute URLs itself. And makeAbsoluteUrl() is a liability when deploying behind a reverse proxy.

And there is no reason why you do not configure the docroot in Apache to match the same location as the "docroot" property in wthttpd, so that you can indeed freely switch between the two modes of deployment. In fact, that is what we've seen many customers do, without any problem.

A simple, pragamatic way to configure the apache docroot is to to simply make it so that the 404's you see disappear.

Regards,

koen

Hey Koen,

And there is no reason why you do not configure the docroot in Apache to match the same location as the "docroot" property in wthttpd, so that you can indeed freely switch between the two modes of deployment. In fact, that is what we've seen many customers do, without any problem.

In perfect world it will be sufficient. But in my scenario it will not. You can have one DocumentRoot per VirtualHost, and when you are deploying different apps under same web server then you must use different directories under DocumentRoot to deploy them there or when you want to put everything in same bag you could deploy it under DocumentRoot (but i am trying to avoid this, especially if i want to use different resources (css, js and so on)).

There is also another reason to do different directories under DocumentRoot. It is when we are talking about hosting FastCGI apps for different users on same machine. We are then FastCGI service provider.

My only question is, can i use relative urls in baseURL property (since we can use relative href inside tag in (X)HTML and the known browsers will accept it). I mean my conf looks like this:

/wt/

/wt/resources

/wt/ext

/wt/favicon.ico

It works with http and https, but baseURL is relative, not absolute... and this may infere the std::string WApplication::makeAbsoluteUrl (const std::string &url) const. The docs says about makeAbsoluteUrl() that:

Makes an absolute URL.

Returns an absolute URL for a given (relative url) by including the schema, hostname, and deployment path.

If url is "", then the absolute base URL is returned. This is the absolute URL at which the application is deployed, up to the last '/'.

I think it should be:

Makes an absolute URL.

Returns an absolute URL for a given (relative url) by including the schema, hostname, and deployment path.

If url is "", then the base URL is returned with schema, hostname prepended if needed (that is when baseURL application property does not have such URL components). If there is no baseURL application property this is the absolute URL at which the application is deployed, up to the last '/'.

Hope you will take that into consideration.

BR,

Lukasz Matuszewski

Hey Lukasz,

I am really struggling to understand what is lacking with the current behaviour of Wt w.r.t. docroots. If what you say is true (that you are forced to use absolute paths), then this is an issue that needs fixing in Wt.

But the scenarios that you provide (in general terms) are really tried and tested scenarios that we and customers and other users have been doing. So, please, make it concrete: what two applications are you hosting on what URLs and why do you believe that setting a baseURL is your only solution ?

You say:

In perfect world it will be sufficient. But in my scenario it will not. You can have one DocumentRoot per VirtualHost, and when you are deploying different apps

under same web server then you must use different directories under DocumentRoot to deploy them there or when you want to put everything in same bag

you could deploy it under DocumentRoot (but i am trying to avoid this, especially if i want to use different resources (css, js and so on)).

As I understand, virtual hosts are just a way to host multiple "servers" on one Apache/NGinx. Nothing special there --- you usually given them different document root's and that's it.

When you deploy different apps under the same web server (whether they are on a different virtual host or on the same), then still, you will be deploying them at a different location, right? Is the example that you are thinking of a situation where you have "/wt/SyNaTPG.wt" and "/wt/other.wt" and want their resources, style, etc... and so on to be fetched from different locations? If they are in a different directory, then obviously there is no problem --- the default behaviour is to read from the same directory as the deployed application. If they are in the same directory, then you will have to configure a different resourceURL property for both (these could be relative URLs, like "resources1/" or "resources2/", and also update both applications to be aware that they use unique directories for other assests such as JavaScript and style. Is this the problem you see?

As to why baseURL needs to be an absolute URL: the spec mandates it and some browsers (e.g. lynx) will fail to work correctly or ignore the baseURL if it is not an absolute URL. The problem with WApplication::makeAbsoluteUrl(const std::string& url) is well spotted, but, the library itself does not use this method anywhere, and if you do neither then you have no problem to fear.

Regards,

koen

I will cite myself:

>For example without baseURL i will have WAnchor with something like this: http://site/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48 (so you see there is no /abc/ part in url which is wrong, because the link doesn't points to my deployed app).

With baseURL set to /abc/ i have WAnchor like this: http://site/abc/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48 (which is good, because it point to my web fastcgi app that is /abc/my_name_of_wt_fcgi_app.wt).

So without baseURL set as /abc/ or correctly http://synat.eti.pg.gda.pl/abc/ the mentioned WAnchor (which url is generate on the fly by wt library if WResource is set on WAnchor) will generate wrong url (that is http://synat.eti.pg.gda.pl/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48). The menus i have on mentioned app will also have wrong url's (there will be no /abc/ part of url).

The mentioned my_name_of_wt_fcgi_app.wt app is placed under:

/var/www/abc/my_name_of_wt_fcgi_app.wt

and the DocumentRoot is set like this:

/var/www/

So i think the WAnchor without internal path set and WResource set should generate appropriate url like:

http://synat.eti.pg.gda.pl/abc/my_name_of_wt_fcgi_app.wt?wtd=9FffhfJl4GnLa65X&request=resource&resource=o1osxvb&rand=48

I want also to have another apps, in example in:

/var/www/def/my_name_of_wt_fcgi_app_2.wt

/var/www/ghi/my_name_of_wt_fcgi_app_3.wt

... and so on...

Is my thinking wrong in some part of text i written so far ?

Thanks again for such quick reply. I think i have some wrong assumptions, but i need to verify they here.

BR,

Lukasz Matuszewski

In plain html mode it works as expected, but in ajax mode it doesn't (without baseURL property set as mentioned above). I have tested in lynx, and files are downloaded from WResource, but in ajax mode in Firefox/Iceweasel it doesn't.

Thanks of much of help.

BR,

Lukasz Matuszewski

I have also changed the directory where the app lies to /var/www_synat/SyNaTPG.wt (DocumentRoot is /var/www). With following apache conf:

  Alias /wt/ /var/www_synat/
  <Directory /var/www_synat/>
    Order allow,deny
    Allow from all
    # Don't show indexes for directories on publicly accessible machines (Uncomment if it's a private devshell).
    Options -Indexes
    # Enable CGIs to be executed
    Options +ExecCGI
  </Directory>
</VirtualHost>

and wt_config.xml:

   <application-settings location="/var/www_synat/SyNaTPG.wt">
      <properties>
        <property name="resourcesURL">/wt/resources</property>
        <property name="extBaseURL">/wt/ext</property>
        <property name="favicon">/wt/favicon.ico</property>
      </properties>
    </application-settings>
</server>

and typical log:

[2011-Sep-14 18:46:21.711222] 9491 - [notice] "Wt: initializing session process"
[2011-Sep-14 18:46:21.711331] 9491 - [notice] "Reading Wt config file: /etc/wt/wt_config.xml (location = '/var/www_synat/SyNaTPG.wt')"
[2011-Sep-14 18:47:11.054931] 9491 [/wt/SyNaTPG.wt 9FmD3Pudt912zooD] [notice] "Session created (#sessions = 1)"
[2011-Sep-14 18:47:11.190289] 9491 [/wt/SyNaTPG.wt 9FmD3Pudt912zooD] [[2011-Sep-14 18:48:17.176673] 9488 - [notice] "Shutdown (caught SIGTERM)"
.176661] 9491 - [notice] "Caught SIGTERM"
[2011-Sep-14 18:48:17.176722] 9491 - [notice] "Shutdown: stopping sessions[2011-Sep-14 18:48:17.179577] 9479 - [notice] "Shutdown (caught SIGTERM)"
[2011-Sep-14 18:46:21.753165] 9482 [/wt/SyNaTPG.wt IOwopRWZmN2PNf3m] [warn] "WApplication::addMetaHeader() with no effect"
[2011-Sep-14 18:47:11.022965] 9482 [/wt/SyNaTPG.wt IOwopRWZmN2PNf3m] [notice] "Session destroyed (#sessions = 0)"
[2011-Sep-14 18:48:17.180824] 9482 - [notice] "Caught SIGTERM"
[2011-Sep-14 18:48:17.180894] 9482 - [notice] "Shutdown: stopping sessions."

but when you will login to my app with login lukasz and password anakin (http://synat.eti.pg.gda.pl/) you will see that mentioned WAnchor has wrong url (it has only WResource set, and internal path left untouched). There are also wrong internal paths for WMenuItem's.

It all happens without baseURL property set.

You can check it...i will leave this behaviour without touch to 15.09.2011 day included. I will "fix" it in 16.09.2011, by using baseURL set to /wt/ or with you answer.

BR,

Lukasz Matuszewski

Hey Lukasz,

I believe I am on to it now. The issue at hand is, I believe, simply a bug in Wt related to internal path handling (and not so much an issue related to FastCGI or deployment). Of course it can be fixed with a baseURL but as I said, it shouldn't be necessary, and I much prefer to fix this bug now :-)

If I understand correctly, you intend the initial screen to be at internal path '/menu_signin', but this is currently not actually reflected in the browser --- although I am under the impression that server-side this state is being taken into account when generating new relative URLs.

I believe this is the source cause of the issue we see. How do you specify this initial path? Can you isolate this in a test-case?

Regards,

koen

Hey Koen,

If I understand correctly, you intend the initial screen to be at internal path '/menu_signin', but this is currently not actually reflected in the browser --- although I am under the impression that server-side this state is being taken into account when generating new relative URLs.

OK i will fix it to be /menu_sigin as initial screen internal path.

How do you specify this initial path?

You can see it in when custom WResource is pinned to WAnchor, like mentioned in post about "Wrong UserAgent (Opera, Chrome, Chromium, Safari) behavior with WResource" http://redmine.webtoolkit.eu/boards/2/topics/2831 (there is also full source code added there as attachment)

The mentioned WResource is created in NazArtNazAlbItpModel (source/models/mir_sp_models_nazartnazalbitp.cpp).

@

using namespace Wt;

namespace dbo = Wt::Dbo;

boost::any NazArtNazAlbItpModel::data(const WModelIndex& index, int role)

const

{

if ((role DisplayRole || role EditRole) && index.column() < 4)

return this->QueryModel<dbo::ptr >::data(index, role);

else if (index.column() 4)
{
if (role ParamsResourceRole)

return new ParamsResource(this~~m_dm, this>resultRow(index.row())->m_naa_id);

else if (role DisplayRole || role EditRole)

return WString::tr(MIR_TABLE_EXP_DOWNLOAD_PARAMS);

else

return boost::any();

}

else if (index.column() 5)
{
if (role MusicResourceRole)

return new MusicResource(1, thism_dm, this~~>resultRow(index.row())->m_naa_id);

else if (role DisplayRole || role EditRole)

return WString::tr(MIR_TABLE_EXP_DOWNLOAD);

else

return boost::any();

} else

return boost::any();

}

@

Hope it helps.

BR,

Lukasz Matuszewski

Hey Lukasz,

You mean that it is set using an anchor? But I am under the impression that it is the very first rendering that goes wrong.

I would imagine there is a call to WApplication::setInternalPath() or something with a WMenu ?

I guess the code which contains the string "menu_sigin" is relevant ?

Regards,

koen