Web++: A C++ Web Framework
132 subscribers
440 photos
36 videos
20 files
177 links
Web++ Framework (A C++ web framework to ease the pain of web development)

Using modern C++20/23.
GitHub: https://github.com/the-moisrex/webpp

I've been working on this project since 2019...
Download Telegram
I like bit manipulating!
πŸ‘2
Media is too big
VIEW IN TELEGRAM
2023-10-14: Working on web++'s scheme parser of the URI parser.
πŸ”₯3
Media is too big
VIEW IN TELEGRAM
2023-10-15: Continuing to work on the URI parser.

Recorded using asciinema, replay with 50x speed.

The whole thing is in terminal using neovim with SpaceVim installed on it.
❀3
I like my bits manipulated 😁
πŸ‘1
Did you know you couldn't use hex numbers as IPv4 octets, but you kinda can? In WHATWG compliant URL Parsers, it's a warning, not an error:

Β» http://127.0.0x10.1
is same as:
Β» http://127.0.16.1

I don't agree with this decision though, and also it messes up my error handling ideas that I had in mind, but ...!

You already can use this in your browsers, you can write http://0x7F.0x0.0x0.0x1, you'll get http://127.0.0.1/.

Also http://0x7F000001 is going to be http://127.0.0.1 as well.
πŸ”₯3🀯2
C++23's [[assume(...)]] fallback looks like this.

And it only took me something like 50+ browser tabs to figure this out πŸ˜…

Source on Github
😁1
Web++: A C++ Web Framework
C++23's [[assume(...)]] fallback looks like this. And it only took me something like 50+ browser tabs to figure this out πŸ˜… Source on Github
I updated this just a bit to add constexpr support as well; I WENT OVERBOARD, I think πŸ˜….

P.S.: 30+ more tabs got opened as well to get this update πŸ˜‚

New source code on Github
Test: Godbolt Link
😁1
Updated my C++ implementation of the Javascript encodeURIComponent and decodeURIComponent functions; it's now faster.
πŸ”₯1
Opened up 2 PRs for boost::coroutine and boost::context to fix similar casting warnings in them.
😁3πŸ”₯1
Turns out my IPv6 Parser implementation can correctly parse IPv4s, but it shouldn't, raw valid IPv4s are not valid IPv6s. πŸ˜…
Browsers make mistakes too

There are a few bugs with the current implementation of URL Parser for firefox. (Chromium has them too, but that's another bug).


This URL:
http://127.0.0.1/..//./one/%2E./%2e/two/././././%2e/%2e/.././three/four/%2e%2e/five/.%2E/%2e


Should be equal to this URL (from ada-url):
http://127.0.0.1//three/
| | |
| | `------- pathname_start 16
| | `------- host_end 16
| `---------------- host_start 7
| `---------------- username_end 7
`------------------ protocol_end 5


I'm writing a WHATWG-compliant URL Parser, so that's why I'm noticing these kinda stuff.


It seems like URL parser of Firefox has a bug which doesn't decode the last segment of the path for some reason.

For example,
http://localhost/page/%2e%2e
is just
http://localhost/
YES, my tests are failing successfully; no crashes anymore. 😁
Did you know these two are VALID URLs and are the SAME?

file://C|\windows

file:///C:/windows
😐1
Web++: A C++ Web Framework
Did you know you couldn't use hex numbers as IPv4 octets, but you kinda can? In WHATWG compliant URL Parsers, it's a warning, not an error: Β» http://127.0.0x10.1 is same as: Β» http://127.0.16.1 I don't agree with this decision though, and also it messes…
All of these URLs refer to the same place:

http://127.0.0.1/
http://0x7F.1/
http://0x7F000001
http://0x0000000007F.0X1
http://127.0.0x0.1
http://127.0X0.0x0.1
http://127.0X0.0x0.0x1
http://127.0.0x0.0x0000000000000000000000000000000000000000000000000000000000000001
http://0x7F.0x00000000000000000000000001
http://0x000000000000000007F.0x00000000000000000000000001
http://0x000000000000000007F.0.0x00000000000000000000000001
http://0x7F.0.0.0x1
http://0x7F.0.0x000.0x1
http://2130706433
http://127.1
http://127.0x00.1
http://127.0x000000000000000.0.1

😐😐😐😐😐
πŸ€”1