Help converting a .htaccess file from a Yoctopuce application


I am not sure the post template would be useful for this issue as this is yet another “.htaccess conversion” thread, not really a problem with my existing Caddy setup, sorry if I should have followed it anyway.

I am planning on installing this on my server, but the installer errors out with:

installer-testdir/Subdir/Node/Test/RewriteRules caused an HTTP 404 Not Found
The file installer-testdir/.htaccess created by the installer did not produce the expected result.
Most probably your Web server does not have mod_rewrite enabled, or AllowOverride is not set for this directory tree.
This is a fatal error, as this software relies on URL rewriting to work properly.

I believe this is because it requires creates a .htaccess with the following content, which has no effect with Caddy:

RewriteEngine on
RewriteRule ^.*$ index.php?node=$0 [L,QSA]

I am struggling to convert that into Caddy syntax. I checked other threads and found similar issues, but couldn’t succeed based on them anyway.

This is the chunk in my Caddyfile where I assume the rewrite directive should go:

yoctovh.domain.tld, www.yoctovh.domain.tld {
       tls email@domain.tld

       root * /var/www/yoctopuce/virtualhub4web # The installer.php file is there

       encode gzip

       php_fastcgi unix//run/php/php7.3-fpm.sock

Wow, that’s some incredibly nasty PHP code. Does not follow modern best practices.

FYI, PHP 7.3 is EOL. You should upgrade to PHP 8.0 at minimum. See PHP: Supported Versions

That said, I think you might be able to get the rewrite to work with this:

php_fastcgi unix//run/php/php8.0-fpm.sock {
	try_files /index.php?node={path}

But really, the PHP app should be reading from the REQUEST_URI variable, and not rely on query parameters for routing.

Thanks @francislavoie for the prompt help! I tried the snippet you posted but I am still getting the same error after restarting the Caddy service:

(As you can see I haven’t updated to php8.0 yet, but thanks for warning me. Actually I did install and try it in the Caddy file, but only got white pages when loading php pages, so I reverted to 7.3 in the snippet. I will investigate later how to make 8.0 work.)

I am afraid I am not skilled enough to check the PHP code in their application. How bad is that? I tend to put a lot of trust in them though, they have a very open way of doing things, so I’m not too concerned about bad intents, but don’t know if they might be security risks with the code.

They just released it a day ago, so perhaps they will improve it later on. They did say though that they had to use tricks to do what they wanted in PHP, but my understanding is there are benefits in doing so instead of relying on more complex dependencies. I’ll keep an eye on their later updates, see what they change.

You should reach out to them and get them to validate compatibility with Caddy. I don’t understand what test they’re trying. I don’t have the time to dive into their code to understand it either.

I understand, thanks @francislavoie. Yes, I actually asked them before seeing other posts on this forum about .htaccess conversions to Caddy syntax, so I thought it was likely the same scenario here and would be compatible as well without them changing their application; but perhaps it isn’t. They haven’t replied yet, perhaps next week.

Looking at the source code, I might have omitted a rule in my first post. You translated the $0 from the first rule into {path} for Caddy, how would I translate the $2 and [QSA,END] here?

It may not be the solution, but it’s worth a try.

There’s not really an equivalent to QSA in Caddy. But the closest would be something like try_files /index.php?node={path}&{query} but this can still produce invalid queries, because if {query} is empty, you end up with an errant & at the end.

I still think this is just a very poorly written app, and it should be updated to support modern routing mechanisms. Rewrites like this are very much legacy.

1 Like

Thanks. I can confirm this did not fix the installation error, unfortunately. I will open an issue and try to convince them of the merits of supporting modern routing mechanisms and be more webserver-agnostic (but unfortunately I don’t know PHP or the Caddy syntax enough to raise a PR, so I hope they will pick up the issue).

@Francis: I will be very happy to learn from you about the modern webserver-agnostic routing mechanism that I could implement in our application to make it more plug-and-play for everyone (assuming making the life easier for a few customer will not make it worse for the 95% users which are using apache-like servers…) Can you give me a startup pointer? I am surprised by your gnarly remarks as the mostly used web solutions still use rewrite rules as far as I know.

@Mat, I replied to your comment on Yoctopuce web site with the solution for your question, using a path_regexp. By the way, next time you have a question, don’t hesitate to send a mail directly to At Yoctopuce, developers are available to directly support our customers. We don’t ask for special skills to ask support questions…

Take a look at this lib, for example:

Modern PHP routing is done by reading the original request URI from $_SERVER['REQUEST_URI'] and making the routing decision based on matching on that URI.

Doing a rewrite to put the original URI in a query param (presumably so you grab it with $_GET) is legacy, and not recommended.

All major PHP frameworks (Laravel, Symfony, Yii, WordPress, etc) all do it this way.

To elaborate on this:

  • Not using PHP namespaces (really should, so you can make use of PSR-4 autoloading)
  • Some PHP files are 10,000 lines long :scream:
  • You should only have one class per file
  • Too many global variables, defines
  • Weird “installer” thing with gzipped code… this is sketchy, it makes it harder/annoying to verify you don’t have malicious code in there
  • Poor/inconsistent style. Use a tool like php-cs-fixer to keep consistent style for the code
  • No use of static analysis or type checker; use psalm or phpstan to ensure input and output types of all the functions make sense

I don’t have time to dig much deeper, but there’s a lot more that could be spoken about.

OK, so what makes you unhappy is the fact that we save to the node arg the part of the URL that is stripped when rewriting all URLs to index.php. We can remove that requirement easily, as we anyway have to start from the URI when using authenticated requests, and I agree that this will make the rewrite rule simpler, which is always better.

Looks like we don’t come from the same school regarding what really matters. But just to clarify:

Not using PHP namespaces / autoload

This is an opiniated choice. This solution is not a module to be integrated with third-party modules, and we don’t like to rely on external autoload mechanisms when there is no added value in using them.

  • Some PHP files are 10,000 lines long :scream:

This is not source code: it is a bundled PHP file to make it easier to manipulate on the server. Our build process creates a PHP 7.x and a PHP 8.x bundles, as we do care about supporting older versions for customers that need it.

  • You should only have one class per file

Opiniated choice. We put together things that belong together.

  • Weird “installer” thing with gzipped code… this is sketchy, it makes it harder/annoying to verify you don’t have malicious code in there

Source code is available as well, and manual installation instructions are coming soon as well.

But we do care to make things really easy to install whenever possible. We provide a self-contained installer because it provides an added value to some customers, even if you don’t see it.

  • Poor/inconsistent style. Use a tool like php-cs-fixer to keep consistent style for the code
  • No use of static analysis or type checker; use psalm or phpstan to ensure input and output types of all the functions make sense

The source code is in PHP 8, type-checked. Again, you are looking at a bundled file transpiled for portability.

This being said, I don’t believe this discussion brings much value to anyone else, so I will leave it as is. I am sure you have your reasons to believe you are right, and you are certainly not alone thinking in this way. But we also have reasons to believe our customers like the way we do work.

Are you aware of PHARs? That’s the official, supported way of bundling PHP code. The approach you’re taking currently is pretty janky. It could be entirely automated by a tool like GitHub - box-project/box: 📦🚀 Fast, zero config application bundler with PHARs.

It’s not opinionated. It’s a question of maintainability. Scrolling through huge files to find things is significantly harder than browsing through a project structure graph.

I wouldn’t even consider contributing to this project with its current structure, because it’s off-putting. That’s why I’m pointing this out. If you use modern standards, it’ll be much easier for people who are interested in the project to help out one way or another.

That’s not the same thing as static analysis. Those types are checked at runtime. Static analysis runs offline, ahead of time. It catches bugs as you write the code, before you even run it.

Nice seeing you here @yoctopuce. Your efforts to improve virtualhub4web and looking into Caddy resources and are greatly appreciated, thanks.

I saw that, thank you! I haven’t been able to make it work yet, but admittedly I spent very little time on it because I’m currently on a trip, and should take the time to read again the Caddy documentation to make sure I am properly integrating your Caddy rules into my existing caddyfile. Hope I can make it work soon!

As for contacting the support, I just genuinely thought that my issue was not with the application itself, but with me failing to translate the Apache rules into Caddy rules, because I saw other threads about similar translations and they got solutions. I am well aware that the vast majority of servers use Apache or Nginx so I didn’t think my corner case would be considered so I did not want to bother.

That was me using that term but I’m a total muggle here in PHP, I meant no offense at all about the initial implementation when using those words.

I am sorry to be the starting point of some negatives waves floating around, and for having cost time to both of you. I just love what I saw about the features Virtualhub4web offers (I hope that the critics are not demotivating, what Virtualhub4web can do is really awesome), and I also love how Caddy made my life easier after years using Apache and Nginx, so I wanted to make them work together, with no intent to expose the code or choices behind the application in a bad way (I have no opinion, I am not educated enough on PHP). Now that it’s done, I do hope however that @francislavoie’s detailed comments can help making the tool even more robust, like with the simplification of the rewrite rule without the node requirement, or easier contributions to the code (not from me until I learn PHP, obviously). They probably would not have stumbled upon vhub4web without that post, yet if the comments are relevant, then that’d be open source paying off once again in the end.

Hope no one is too salty about that discussion, it could benefit everyone in the end (and I do agree that simplified tools on top of manual installs with instructions are useful in the Yoctopuce software, considering the diverse target audience, but if there are more standard ways to do it, that’s nice too).

1 Like

Yeah – no ill-intent from me, and I apologize if my wording came off aggressive. As a professional PHP dev, I just have a certain expectation of quality when reviewing PHP code, and I can’t help but wince sometimes when I see something that doesn’t feel right to me. But clearly you’re building something that people find interesting, so :+1: thanks for that!

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.