a few different ways... if it were me, I'd modify the webserver's assembly language hooks and make use of the https://2ton.com.au/library_as_html/dir.inc.html directory reading goods from the library to custom generate HTML/CSS/images for a given listing. (making sure to bake in some access controls/permissions).

Your other alternatives might be to use a FastCGI -indexfiles option and code the directory listing generator in your FastCGI/CGI language of choice... (Even other assembly language CGI environments, like @JohnFound's that runs https://fresh.flatassembler.net via rwasa)

Granted that isn't necessarily "out of the box" easy to do I suppose, haha... most of the other webservers I have played with either have templates that ship alongside the webserver, or the HTML/etc is all hardcoded/baked in ... and since I like the idea of rwasa being a standalone binary (without an install package/configuration script, lots of extra required files, etc), adding these sorts of "you are _definitely_ going to want to customise this feature, or that) didn't really go hand in hand.

Lol good eye! When I wrote it initially, it was a hand-compile of a C++ version I have here somewhere, line 200 is a remnant that didn't get deleted after I got what I wanted Next release of the library will have it commented out thusly. Is it the ELF64_ST_TYPE uint16? something like that from vague recollection. Anyway, you are correct in that it is unused in the HeavyThing implementation.

I would like to discuss a little the buffering issues with rwasa server. This is virtually the only reason why I am using nginx on my domain and I badly want to migrate to rwasa.

The problem is that I am very often using SSE that needs the server to not buffer the FastCGI output, but to directly pass it to the client. This way the server sent events can reach the client instantly.

In nginx, this problem is solved IMHO in most elegant way, by defining a header "X-Accel-Buffering" - if the server receives this header from the FastCGI server and the value of the header is "no", it switches the buffering off and relays the answer directly to the client.

In Apache and the other servers I know, the solution is not so flexible - through the configuration files.

If you are too busy (and don't mind) I can try to implement this feature by myself, but will probably need some guidance in the source and the internal architecture of the project.

Thanks @JohnFound, can you send me an offending/example FastCGI program that does what you want? It will [likely] be much faster for me to implement the change you need than walk you through the rwasa/epoll designs.

Thanks @JohnFound, can you send me an offending/example FastCGI program that does what you want? It will [likely] be much faster for me to implement the change you need than walk you through the rwasa/epoll designs.

Happy to help and at the moment have some free time on my hands.

Cheers

Thanks. I don't have compact example right now, but have implemented debugging echo service installed on board.asm32.info. I have written it when reporting the same bug in the Apache HTTP2 module.

For quick illustration of the problem use curl:

1. As it should be (the buffering switched off). The echo output arrives in an even stream:

Code:

curl https://board.asm32.info/0/\!echoevents/

2. As it is now in rwasa and other servers with buffering:

Code:

curl https://board.asm32.info/1/\!echoevents/

Hope this will help, but if not, I will try to create small stand alone program that to reproduce the problem.

Regards.

P.S. In the case 2, rwasa seems to never returns data until the request is fully processed by the FastCGI client. Nginx in this case at least sends the data on relatively small chunks.

I spent this morning coding up the necessary changes, it works for my tests but more testing is required Will PM you a link to a test binary most likely tomorrow after I test for backward compatibility (took a bit of effort to keep the old functionality there while also supporting the new way).

I spent this morning coding up the necessary changes, it works for my tests but more testing is required Will PM you a link to a test binary most likely tomorrow after I test for backward compatibility (took a bit of effort to keep the old functionality there while also supporting the new way).

If you greenlight will do another formal release with the changes.

Cheers

Great as always! Did you made it through X-Accel-Buffering header or another way? I mean, do I need to change something to the back-end?

The way I did it, there are three separate ways to "enable FastCGI direct mode" with rwasa:

1) Use the X-Accel-Buffering: no header
2) Use the text/event-stream Content-Type
3) Pass -fastcgi_direct to rwasa on the command line and _every_ FastCGI response goes directly.

If the FastCGI program does not specify size or its own chunked transfer encoding, for HTTP/1.1 responses rwasa will correctly add chunked transfer encoding to the FastCGI output, and otherwise leaves it alone.

Hopefully it will work with your event-stream stuff too it works in my development sandbox, haha, stay tuned

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum