12 years ago I asked on Stack Overflow: Are HTTP GET requests allowed to have request bodies?. This got a 2626 upvotes and a whopping 1.6 million views, so clearly it’s something lots of people are still curious about, and in some cases disagree with the accepted answer.
Because it keeps popping up in my Stack Overflow notifications (and I compulsively visit the site), the question has lived in my head rent-free. I keep adding context in my head, and I’ve been meaning to write some of this down for a few years now and hopefully evict it.
Anyway, if you’re just looking for a quick answer, it’s ‘No, you shouldn’t do
this.’, you should probably use QUERY.
A number of people (most famously ElasticSearch) have gotten this wrong, but why? I think it’s because of this sentence in the HTTP Spec:
A payload within a GET request message has no defined semantics
That sentence could easily suggest that there’s no specific behavior associated
to request bodies with GET requests, and that the behavior is left up to the
implementor.
The reality is that this is more like Undefined behavior from languages like C/C++. My understanding is that leaving certain aspects of the C language undefined (instead of for example requiring an error to be thrown) leaves room for compiler implementations to make certain optimizations. Some compilers also have fun with this; GCC hilariously starts a video game in a specific case of undefined behavior which really brings home this point.
If you were to write a C program that relies on how a compiler dealt with specific undefined behavior, it means your program is no longer a portable C program, but it’s written in variant of C that only works on some compilers.
The same applies for HTTP as well. It’s true that undefined behavior means that you as a server developer can define it, but you are not an island!
When working with HTTP, there’s servers but also load balancers, proxies,
browsers and other clients that all need to work together. The behavior isn’t
just undefined server-side, a load balancer might choose to silently drop
bodies or throw errors. There’s many real-world examples of this. fetch()
for example will throw an error.
This hasn’t stopped people from doing this anyway. OpenAPI removed
support for describing GET request bodies in version 3.0 (and DELETE,
which has the same issue!), but was quitely added back in 3.1 to not
prevent people from documenting their arguably broken APIs.
The best source I have is this quote from Roy Fielding in 2007. Roy Fielding coined REST is and is one of the main authors of the HTTP/1.1 RFCs.
Yes. In other words, any HTTP request message is allowed to contain a message body, and thus must parse messages with that in mind. Server semantics for GET, however, are restricted such that a body, if any, has no semantic meaning to the request. The requirements on parsing are separate from the requirements on method semantics. So, yes, you can send a body with GET, and no, it is never useful to do so. This is part of the layered design of HTTP/1.1 that will become clear again once the spec is partitioned (work in progress).
….Roy
(His message was originally sent to the now-dead rest-discuss group on Yahoo Groups, but I found an archive in JSON format)
However, I always found this answer unsatisfying. I understand that you might want a low-level protocol design that just passes messages containing headers, bodies,
Truncated by Planet PHP, read more at the original (another 9288 bytes)
Git Cheat Sheet (50 commands + Free PDF and poster) – This handy reference contains plenty of common Git commands spanning a variety of categories.
Spatial Web Browsing – A look at browsing apps that arrange objects in space to create groupings, indicate relationships, and build hierarchies.
Animate Anything Along an SVG Path – This tutorial will show you how to create animations using SVG paths and the getPointAtLength() function.
50 Free High-Resolution Photoshop Brushes for 2022 – Add these amazing brushes to your Photoshop toolkit.
Shapefest – Grab this library of 160k+ transparent PNG shapes.
Crafting Component Libraries: The Elements – Learn the process for crafting the foundational elements that make up a component library.
An Introduction to WordPress Block Themes – Block themes are set to become the future of WordPress. Here’s a look at how they compare and contrast with “classic” themes.
The breakpoints we tested in 2021, and the ones to test in 2022 – Choosing the right breakpoints for effective responsive design.
Hoosierland – FREE FONT – Get your copy of this free decorative font for use in your projects.
Why ‘Grumpy Designer’ Is the Only Title I Want – How to stop worrying about job titles and focus on what matters.
Frontend Predictions for 2022 – A look at some not-so-obvious trends for the new year.
Scenarios Where the WordPress Gutenberg Block Editor Replaces Custom Code – Why the need for custom code has been greatly reduced by the block editor.
DevToys – An offline Windows app that helps developers in daily tasks.
The Podcast Font – A collection of font icons geared towards podcasters.
10 Free Syntax Highlighter WordPress Plugins – Display and edit code beautifully with these handy plugins.
The post Weekly News for Designers № 628 appeared first on Speckyboy Design Magazine.
WordPress offers plenty of content creation capabilities out-of-the-box. The Gutenberg block editor is a big help when it comes to layouts, but still lacks some more advanced items. That’s where the vast library of available plugins comes to the rescue.
No matter what type of site you’re running, there’s bound to be a plugin to enhance your ability to add and edit content more powerfully. That results in content that fits your specific needs but doesn’t require you to jump through hoops.
Here’s a look at 10 free plugins that will help you create better and more complex content.
If you’re selling products or services through your website, pricing tables are a must. However, they’re not a design feature that’s easily built in a default WordPress installation.
That’s where Easy Pricing Tables comes in handy. It’s built for the block editor and provides a visual UI for creating attractive, easy-to-read tables. A premium version adds more bells and whistles – including premade table themes.
Cool Timeline offers an interesting way to arrange a given set of posts. Turn them into an attractive timeline, complete with dates and featured images.
Colors can be tweaked to match your site’s look. Plus, the plugin works via both the block and classic editors.
PDF files are a staple of the web. Yet, WordPress doesn’t offer dead-simple ways to embed or link to them. Embed PDF Viewer makes it easy, with a custom block built just for this purpose.
Even better is that it works with any valid PDF URL – whether it’s hosted directly on your website or not.
Sometimes, standard text hyperlinks don’t provide enough context. Visual Link Preview offers a social-media-like means to preview links.
The plugin lets you create a custom link preview template that uses images and descriptive text. It’s perfect for showcasing affiliate links or other important resources.
The WordPress Classic Editor uses an open-source software package called TinyMCE. Advanced Editor Tools is an all-around powerhouse – allowing you to add/remove/rearrange toolbar icons, utilize TinyMCE features that aren’t available in the standard WordPress install (like creating tables), along with some other advanced options.
It’s a great way to customize WP’s visual editor to fit the tasks you do the most. Even better is that it also enhances the Gutenberg block editor as well.
If you need to create complex, feature-packed HTML tables, check out TablePress. Its editor is reminiscent of a spreadsheet, making the chore of adding or editing content simple.
You can even import data from several sources. Best of all, some JavaScript magic allows users to sort and filter tables.
The standard WordPress Text Widget is not so user-friendly. Replace it with Widget Content Blocks, which will let you create widgets with WYSIWYG – the same way you already create pages and posts.
A custom post type is added to WordPress, where you can create and edit “widget blocks.” Format text, add images – basically anything you can do with a page or post. When done, head over to the Appearance > Widgets screen to add your new widgets to a sidebar.
While you can already use WordPress oembed to add YouTube videos to your site, the YouTube Embed Plugin adds further capabilities. The plugin adds a visual search for YouTube videos, channels, and playlists.
You can then easily embed them into any page or post. There are also several useful features, like volume initialization, iOS playback settings, and HTTPS support.
A well-made post excerpt is now within your reach with Advanced Excerpt. You’ll be able to control the length of auto-generated excerpts, retain HTML formatting, and more.
Editing code in the WordPress text editor leaves a lot to be desired. Using HTML Editor Syntax Highlighter will result in a much better UI for code editing.
Code is highlighted, indented, and is a lot easier to browse than the default setup.
The backend of a WordPress website should enable you to work the way you want. Instead of learning to deal with any shortcomings, it’s important to set up a work environment that requires as few workarounds as possible.
With the plugins mentioned above, you’ll have the power to make content creation more efficient and fun.
The post 10 Free Plugins to Help Improve WordPress Content Creation appeared first on Speckyboy Design Magazine.
In this episode of "PHP Internals News" I chat with Tim Düsterhus (GitHub) about the "Redacting Parameters in Back Traces" RFC.
The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode's MP3 file, and it's available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news
Before we start with this episode, I want to apologize for the bad audio quality. Instead of using my nice mic I managed to use to one built into my computer. I hope you'll still enjoy the episode.
Hi, I'm Derick. Welcome to PHP internals news, a podcast dedicated to explaining the latest developments in the PHP language. This is episode 97. Today I'm talking with Tim Düsterhus about Redacting Parameters in Backtraces RFC that he's proposing. Tim, would you please introduce yourself?
Hi, Derick, thank you for inviting me. I am Tim Düsterhus, and I'm a developer at WoltLab. We are building a web application suite for you to build online communities.
Thanks for coming on this morning. What is the problem that you're trying to solve with this RFC?
If everything is going well, we don't need this RFC. But errors can and will happen and our application might encounter some exceptional situation, maybe some request to an external service fails. And so the application throws an error, this exception will bubble up a stack trace and either be caught, or go into a global exception handler. And then basically, in both cases, the exception will be logged into the error log. If it can be handled, we want to make the admin side aware of the issues so they can maybe fix their networking. If it is unable to be handled because of a programming error, we need to log it as well to fix the bug. In our case, we have the exception in the error log. And what happens next? In our case, we have many, many lay person administrators that run a community for their hobby, they're not really programmers with no technical expertise. And we also have a strong customers help customers environment. What do those customers do? They grab their error log and post it within our forums in public. Now in our forum, we have the error log with the full stack trace, including all sensitive values, maybe user passwords, if the Authentication Service failed, or something else, that should not really happen. In our case, it's lay person administrators. But I'm also seeing that experienced developers can make this mistake. I am triaging issues with an open source software written in C. And I've sometimes seeing system administrators posting their full core dump, including their TLS certificates there, and they don't really realize what they have just done. That's really an issue that affects laypersons, and professional administrators the same. In our case, our application attempts to strip those sensitive information from this backtrace. We have a custom exception handler that scans the full stack face, tries to match up class names and method names e.g. the PDO constructor to scrub the database password. And now recently, we have extended this stripping to also strip anything from parameters that are called password, secret, or something like that. That mostly works well. But in any case, this exception handler will miss sensitive information because it needs to basically guess what parameters are sensitive values and which don't. And also our exception handler grew very complex because to match up those parameters, it needs to use reflection. And any failures within the exception handler cannot really be recovered from, if the exception handler fails, you're out of luck.
Truncated by Planet PHP, read more at the original (another 17418 bytes)