We have recently improved the the redirection.io rules system by introducing negation support for the "Method" and "Backend Response Status Code" triggers, providing you with greater flexibility and control over rule execution.
In a redirection.io rule, Triggers define the conditions that incoming HTTP requests must meet for the rule to be applied. For example, the "Method" trigger filters requests based on the HTTP method used, while the "Backend Response Status Code" trigger allows you to restrict triggering based on the status code generated by your backend application.
With our latest update, you can now utilize negation for these triggers. For example, you can define rules that trigger when the HTTP method is not GET or POST, or when the backend response status code is not 200 or 301. This new capability enables you to refine your rule logic and execute specific actions based on negated conditions.
To learn more about negation support and explore other features of the redirection.io rules system, refer to our documentation about triggers. We value your feedback and are continuously working to improve our services based on your needs. Thank you for choosing redirection.io as your trusted solution for efficient traffic management!
We have released lately the version 2.7.0 of the redirection.io agent, our software designed for logging HTTP traffic, analyzing requests and performing responses transformations. In this release, we've introduced new configuration directives that further enhance the agent's capabilities. These directives provide greater control and flexibility over the logging of access logs, the utilization of HTTP keep-alive between the agent and the backend, and the configuration of backend request timeouts.
Here are the key additions in version 2.7.0:
keep_alive.enabled: With this directive, you can enable or disable the HTTP keep-alive feature between the agent and the backend. By default, this feature is enabled, ensuring optimal performance. Adjusting this setting allows you to fine-tune the agent's behavior to match your infrastructure needs.
timeout: This directive allows you to configure the timeout duration, in seconds, for backend requests. By default, this feature is disabled, but with this new directive, you can restrict the maximum time a connection will remain opened to your backend. This is particularly useful for optimizing the performance of your infrastructure in case your application suffers performance issues on certain paths.
access_log: This directive allows you to enable or disable the logging of access logs in the specified log locations. By default, access log are disabled, giving you the flexibility to enable it based on your specific requirements.
These new features are documented in the "agent configuration reference" documentation page. To benefit from the improved performance and added functionalities, we encourage all our customers to keep their redirection.io agents up to date. By doing so, you'll always have access to the latest features and enhancements, empowering you to streamline your traffic management and maximize efficiency.
We're pleased to announce the addition of the Aggregated Logs Details Panel to the redirection.io manager. This new feature brings convenience and efficiency to your analysis of HTTP traffic logs, allowing you to delve deeper into your most frequent requests.
In the logs screen of the manager, you can already group requests by various criteria like URL, HTTP method, response status code, and user agent. However, we've now made it even better by enabling the display of details for grouped requests.
For example, if you want to examine the most frequently requested URLs, simply group the requests by URL and click on a specific URL. You'll instantly access a comprehensive list of matching requests, complete with a preview of the most recent ones. You can easily navigate through these requests using the intuitive "next" and "previous" buttons.
This small yet handy feature provides valuable insights into your traffic logs, allowing you to quickly identify any issues or patterns. It's perfect for troubleshooting or conducting in-depth analysis.
We strive to make your experience with the redirection.io manager as seamless as possible, and Aggregated Logs Details is another step towards achieving that goal.
If you have any questions or need assistance, our support team is ready to help!
We are thrilled to announce a new feature in redirection.io that will make managing your sitemap.xml files easier than ever before. Our new "Sitemap management" feature is now available for "Pro" plan subscribers and allows you to define the content of your sitemap files directly within redirection.io.
Creating and managing sitemap files is an essential part of website management. However, it can often be a time-consuming and manual process, especially for larger websites. With our Sitemap management feature, you can avoid the need for developers to deploy a new version of the website every time a sitemap.xml file needs to be updated. This feature is useful in many professional contexts when the sitemap.xml management is not fully automated.
With the new redirection.io Sitemap action, you can easily define the content of your website's sitemap.xml file(s) directly from redirection.io, and serve it at the location specified in the "Source URL" trigger.
By using redirection.io to manage your sitemap files, you can improve your productivity and focus on more important tasks. This feature, combined with the redirection.io crawler, guarantees better reactivity and the ability to cover all the pages of your website, which in turn improves your website's SEO. Additionally, you can configure several sitemaps using this action, which is perfect for larger websites or for keeping sitemaps properly sorted.
To get started with Sitemap management in redirection.io, upgrade to our "Pro" plan today. And as always, let us know your thoughts and feedback! We're excited to see how this feature will help you better manage your website!
We strongly believe that using the redirection.io manager is a nice way to manage the traffic of websites at scale, and that it offers many nice features to create redirects or traffic management rules.
However, there are some cases where you would want to avoid using the graphical interface to create redirection rules:
to create a large number of rules, if the CSV import format is not flexible enough for your requirements;
to create a rule when a given event occurs (for example, when the URL of one page changes in your Content Management System);
when you want a complete control over the created rule (attach many markers, use complex triggers or actions, etc.).
There are indeed many cases where it may be desirable to be able to create rules without human intervention! This is why we have launched, earlier this week, a new version of our public API. In a few words, the newly available API endpoints allow to retrieve the projects of an organization, list both the published and draft rules, create, edit or delete rules (and drafts), publish the draft changes.
The API supports all types of triggers, actions, markers and variables - which means that web traffic automation can be taken to another level!
After growing requests from our customers for an ARM version of the redirection.io agent, we will now propose such ARM builds in our packages repository.
ARM is a processors architecture which can be used as an alternative to the more traditional x86 architecture. Many Cloud providers now propose ARM instances, which can sometimes offer a better price/performance ratio, and can be a good solution to host the redirection.io agent as a reverse proxy.
We do not propose distribution-specific packages for these ARM versions for the moment, so you will have to build your own systemd unit service file to run the agent. However, the agent tar.gz archive contains a redirectionio-agent.service systemd file, that you will usually want to put under /etc/systemd/system/multi-user.target.wants:
As redirection.io is becoming more and more used by large organizations, the roles and permissions orchestration within a project can become quite challenging to set up. Moreover, redirection.io offers a large panel of actions and empowers our customers with many new possibilities towards the traffic of their website... and with great power come a great responsibility π
Some large organizations requested the ability to restrict permissions by path, to prevent customers to manage the traffic outside the site sections under their responsibility. Several use-case were suggested:
in international contexts, it can be desirable that various users of the same project can only manage disjoint parts of the website. For example, the French marketing team should be authorized to manage redirects under /fr, but not under /de or /uk, which should be reserved respectively to the German and British teams
the customers support team of a company should be able to manage the rules under the /faq path, while the /shop part of the website should only be managed by the eCommerce team
etc.
We have therefore introduced a new concept: the project segmentation. From now on, "Pro" plan projects can define segments at the project level, which help organize rules and can be used to restrict the permissions of users within the project.
How to create project segments
Organization and project Administrators can add, edit and delete segments under the "Segments" tab, in the project settings:
In order to add a segment, click on the "Add a segment" button, and fill in the form:
You can add as many conditions as you want: all the rules for which the "Source URL" starts with one of the provided strings will be considered as part of the segment. This means that several segments can share some URLs. It also means that a segment can be a restriction on a given domain, or even on a given protocol (scheme).
How to restrict a member to one or several segments
Once segments have been defined, project members can be attached to one or more segments, to restrict their rules edition permissions. It is even possible to define a segment restriction directly when inviting a user in the project:
Go to the "members" tab, on the project settings screen. Hit the "Invite another user", and choose either the "Contributor" or "Publisher" role. The "Segments restrictions" dropdown appears and lets you choose one or more segments that must be attached to this user once the invitation will be accepted.
The segments are displayed on the members list
A user with segment restrictions will only be allowed to create rules for which the "Source URL" starts with one of its segments contraints.
Segment-restricted users have limited actions:
they cannot create or edit rules for which the Source URL does not match their segment restrictions
they cannot mark for deletion rules that are not part of their segments
a Publisher with segment restriction can only publish rules within their segment. If some draft rules are not part of the Publisher segment(s), they won't be published, and will remain untouched
a Publisher with segment restrictions cannot rollback to a previous version of the ruleset, as this could introduce changes outside his segment restrictions
Bonus: filter the rules based on their segment
Whatever their segment restrictions, all the project members can see the list of all the rules that have been configured in the project. However, as a user it can sometimes be useful to list only the rules that you can edit - so, a new "Segment" filter has been added in the rules list screen. It allows to isolate the rules that are specific to one or more segments:
With this new "segments" feature, redirection.io adds a new layer of fine-grained administration capabilities, to help delegate the traffic management to several entities within large organizations and websites. The feature is available as of today for all the "Pro" organizations!
While the redirection.io logs explorer is snappy and offers many options, it can become annoying to repeat the same filters configuration to get a specific report. For example, if your weekly website monitoring routine includes checking the HTTP errors found by search engines, you could end up being a bit fed up with configuring again and again the "Status code" and "User agent type" filters.
For such cases, we offer the "Logs views" feature. Logs views are a way to save a specific columns, filters and aggregation configuration, and to be able to reload this configuration with as few clicks as possible.
We already several predefined "Logs views" that address common analysis use cases:
All HTTP errors: This report displays the list of all HTTP errors (both 4xx and 5xx). Use this view to spot issues peaks during the last logging period.
Googlebot verified requests: This report lists all the requests that have been performed by Googlebot or any other Google-operated bot. We have validated this request and filtered out third-party bots pretending to be Googlebot.
Googlebot most common errors: This report shows the most common HTTP errors encountered by verified Googlebot on your website. Whenever possible, you should try to solve these issues by setting up a new redirect rule.
Fake Googlebot: Lists all requests that have been sent using the "Googlebot" User-Agent, but that we identified as obviously not initiated by Google services. It may be that these requests are performed by third-party bots that try to scrape some content from your website.
Most common HTTP errors: This report lists the top 100 most common HTTP errors (both 4xx and 5xx), grouped by URL and status code. The errors are sorted by occurrence count.
Top hit pages: Displays the most frequently hit URLs that serve html content.
You can also define your own log views, that will be saved at the project level, so you and your colleagues can use them.
Loading an existing "logs view" is a one-click operation:
Hover the small gear wheel on the top right corner of the filters bar
Then, choose one of the displayed views, or hit the "Load another view" button.
As of today, it is possible to temporarily disable a rule using a new "Enable the rule" switch in the rule edition form. All the pre-existing rules have been let enabled by default, and all future traffic management rules will be enabled by default. Just hit the switch to have the rule be disabled.
π Please note that, after you have enabled or disabled a rule, you still have to publish this change (as any other change you would make in your ruleset) for it to be applied on your production website.
One could wonder why such a feature was not available in the past π€ In fact, it has always been possible to remove a rule and re-enable it later on, by using the rules history mechanism, which allows to restore a past ruleset. This new feature just makes it a lot easier and straightforward to temporarily shutdown one or more rules and still keep them on hand, so it can be re-enabled in a quick way when needed.
On the other side, it may sound weird to want to temporarily disable one or more redirects on your website. This feature has been requested by several customers and can be used in several use cases:
to prepare a set of new rules that will have to be enabled in a few days only;
to execute a rule only during certain periods, and to be able to deactivate it outside these time slots;
to perform A/B tests on redirection targets.
Prepare a set of new redirect rules upfront
Imagine that a new country section is being launched on your website in a few days. The rollout of these country pages will come with a set of new redirects, that you will want to enable only when the new section goes live. Using the "enable / disable" feature, you can now prepare the new rules, and enable these rules when the backend website is ready.
Execute a rule only during certain periods
Imagine that a section of your online store is only opened during event sales, which take place on the first Wednesday of the month. The rest of the time, you prefer a redirect to a specific landing page of your website. Disabling this redirect rule to open the event sales shopping page(s) is a quick way to "open the doors" ππͺ
Run A/B redirect tests
You could also want to test a set of redirects over a certain period of time, measure their effectiveness on your business / revenue, and eventually re-enable those rules if necessary.
redirection.io offers several ways to be notified when things happen on your website or in your project.
We have launched today new "team notifications", to keep your team or coworkers informed of the occurrence of an event in the redirection.io project. For the moment, the notification feature is able to send notifications to Slack channels, email addresses (a mailing-list, for example) or to webhook URLs (for automation).
This feature is available only to "Pro" plans and is designed to keep your colleagues informed that something is happening in the project. This "something" can be an event of different types:
Your browser preferences seem to be set to {targetLanguage}. Would you like to switch to the {targetLanguage} version of this website?No, thanksSwitch to {targetLanguage}