Ошибка регистрации на облачном Push server, Регистрация на облачном сервере: Ошибка: Site URL is too long (100).
|
Подскажите, пожалуйста, где и что можно проверить: в модуле Push&Pull после смены лицензии ошибка при регистрации на облачном сервере «1С-Битрикс»
|
|||
|
Подскажите, в чем была проблема? |
|
|
Удалось решить проблему? У меня такая же беда. |
|
|
Пользователь 113480 Эксперт Сообщений: 438 |
#4 14.08.2021 12:00:43
мне кажется, что эту проблему нужно решать через оф. ТП битрикса. |
||||
|
Пользователь 2090153 Постоянный посетитель Сообщений: 190 |
#5 23.06.2022 15:09:55 Проблема в том, что настройках ключа лицензии указано слишком много тестовых доменов, идет проверка именно по этому полю. Нам помогло уменьшить их количество. |
Written by Marc Agate
Updated over a week ago
What Does «URL Too Long» Mean?
A URL is considered too long if it is longer than 100 characters.
Why It’s Important
An overly long URL can cause both usability and search engine issues:
-
Any potential benefit you may have by including keywords in the URL will be diluted since it’s such a small percentage of the total URL text.
-
Longer URLs are truncated by search engines, in web browsers, and many other areas
-
Visitors like to see clean, human-readable URLs since it makes them easy to read, remember, and type. A long, unwieldy URL can be a usability issue. It could potentially also lead to lower click-through rates on the SERP.
-
Very long URLs are often a symptom of other issues, such as having too many parameters in the URL, which can lead to other problems
How To Fix
There are several things that you can do to avoid URLs that are too long:
-
If using dynamic URLs with URL parameters, use server-side URL rewrites to convert them into static, human-readable URLs
-
Try to minimize the number of parameters in the URL whenever possible
-
If using URL rewrites, consider truncating them at a maximum length. This is especially important if you’re rewriting them programmatically using page data such as page title — long titles will result in very long URLs.
A Word of Caution
When making changes to many URLs of existing pages on your site, it’s important to remember that this process can be tricky and potentially risky if not done correctly. If the changes are not made correctly, it could result in the de-indexation or lower ranking of pages on your site. Therefore, the relatively small benefits that come from undertaking these changes may or may not be worth it for your site.
The process for fixing URLs on your site depends on multiple factors and is too detailed to list here. Instead, remember a few important principles when updating many or all of the URLs on your site:
-
Create a 301 redirect from the old URL to the new one for every page that is being updated
-
Be sure to update all links on your site to point to the new URLs instead of the old ones.
-
Test extensively before rolling out the change on your production server.
-
Update and submit your XML sitemap.
This error is actually thrown from http.sys, not from IIS. The error gets thrown before the request is passed along to IIS in the request-handling pipeline.
- To verify this, you can check the Server header value in the HTTP response headers, as per https://stackoverflow.com/a/32022511/12484.
To get https.sys to accept longer request URLs without throwing the HTTP 414 error, in the Windows Registry on the server PC, at ComputerHKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesHTTPParameters, create a DWORD-type value with name MaxFieldLength and value sufficiently large, e.g. 65535.
- Reference: Http.sys registry settings for Windows
If you decide to make this change, then obviously it’ll need to be made in all environments (including all production server(s)) — not just on your local dev PC.
Also, whatever script and/or documentation your team uses to set up new server instances will need to be updated to include this registry setting, so that your team doesn’t forget to apply this setting 18 months from now when setting up a new production server.
Finally, be aware making this change could have adverse security consequences for all applications running on your server, as a large HTTP request submitted by an attacker won’t be rejected early in the pipeline as it would normally.
As an alternative to making this change to bypass the http.sys security, consider changing the request to accept HTTP POST instead of HTTP GET, and put the parameters into the POST request body instead of into a long URL. For more discussion on this, see question Design RESTful GET API with a long list of query parameters.