When I googled I found out that the reason for 0302 could be any of the following:
1) DBKEY may have a wrong value, nulls, zero, or overlaid working storage 2) Record name is incorrect 3) Wrong Subschema 4) DBKEY is outside of page range for Area
As restarting solves the issue, I eliminated points 2 and 3 above. Also as I am not using explicit use of the DB-KEY (Usages like, moving a working storage variable to the DBKEY and then CALCing the IDMS record based on that key, OBTAIN CALC ) in the module I don’t think point 1 also may be a possibility. So I suppose it may be point 4 above I don’t exactly understand what the issue means in terms of program code.
Joined: 09 Mar 2011 Posts: 7310 Location: Inside the Matrix
I can’t understand this «toss it in again and see if it works» after a failure, but there we go.
Is your step doing updates (I’m guessing not, but have to ask, but also thinking it would provide a reason)?
When it happens next, solve it, don’t just bung it in.
Joined: 27 Oct 2009 Posts: 2478 Location: Netherlands, Amstelveen
ibmmainframes.com/about49713.html
Joined: 09 Mar 2011 Posts: 7310 Location: Inside the Matrix
If a job «falls over» and you chuck it in again with everything the same, it will «fall over» again. It is a computer, that is what happens.
So, something is different.
Is there anything different when you re-run? Exactly what do you do to effect the re-run? Is there a possibiity that it is running alongside something which is doing updates (related to your locking question)?
Joined: 28 Aug 2007 Posts: 1693 Location: Tiruppur, India
Hello, I have not worked on DB2 or have much knowledge on it, but have encountered a similar situation in which a failed job ran successfully upon restart. The issue was resolved after increasing the REGION parameter on the job card. ibmmainframes.com/viewtopic.php?t=54162&highlight=
Joined: 09 Mar 2011 Posts: 7310 Location: Inside the Matrix
Is there a possibility that you are running alongside something doing updates? Then we have a change, because the state of the database has changed (like no longer being updated).
Joined: 20 Oct 2006 Posts: 6967 Location: porcelain throne
restart and rerun are two different things.
rerun implies that the run-unit is ‘started’ again, and it performs the same processing.
restart implies that the run-unit is ‘started’ again, but the run-unit determines that processing should start not at the beginning but at a later point (e.g. input record 97), finds that point, and then starts processing.
Joined: 23 Nov 2006 Posts: 19245 Location: Inside the Matrix
Hello,
Joined: 09 Mar 2011 Posts: 7310 Location: Inside the Matrix
If something else updates the database while you are reading it, then your little wander through the database has the potential to loose its way (some sort of position information that you are using is now changed, so when you try to continue from it you get a big bang).
I’d suggest 1) try to establish which other jobs are running when a few examples of your job fails, looking for something common. 2) talk to production control/scheduling people to find out which jobs are updating the database you are using (they must know for restarts in the case of failures).
Again, I will boldly state,
if a job fails, it will fail again if re-submitted with no changes of any type.
If you are not making changes of any type and your step now succeeds, then the change that must be happening must be happening external to your processing.
Что такое ошибка HTTP 302 и как ее исправить? [4 протестированных метода объяснено]
Вот некоторые из вопросов:
В этой статье я отвечу на все эти вопросы, чтобы у вас было больше ясности в каждом конкретном случае.
Что такое редирект 302?
Code 302 indicates a temporary redirection. One of the most notable features that differentiate it from a Переадресация 301 в том, что в случае 302 перенаправлений сила SEO не переносится на новый URL.
Это связано с тем, что это перенаправление было разработано для использования в тех случаях, когда необходимо перенаправить контент на страницу, которая не будет окончательной. Таким образом, после устранения перенаправления исходная страница не потеряет свое положение в поисковой системе Google. Несмотря на то, что мы не очень часто нуждаемся в перенаправлении 302, в некоторых случаях этот параметр может быть очень полезным. Это наиболее частые случаи:
Для чего нужен редирект 302?
Редирект 302 служит, например, для того, чтобы иметь несколько версий домашней страницы на разных языках. The main one can be in English, but if the visitors come from other countries then this system automatically redirects them to a page in their language.
Таким образом, мобилизация Веб-трафик достигается, но в то же время влияние на уровне SEO главной страницы не ослабляется. Это продолжает расти, несмотря на то, что передача власти не происходит, как мы объясняли ранее.
Пример перенаправления HTTP 302
The most common HTTP 302 redirect example case is Google. Независимо от страны, в которую вы входите, если вы введете https://www.google.com/, you will be redirected to the Google version in the language/country that corresponds to you.
В случае Германии 302 автоматически доставит нас к https://www.google.de/ так что мы можем искать контент на немецком языке. Порталы успешных компаний, таких как Coca-Cola или даже Fujitsu, также используют эту систему для перенаправления трафика туда, где они считают наиболее удобным.
What causes HTTP 302 error?
Here are some of the most common reasons for the 302 redirect error:
How to identify HTTP 302 error?
Проверка того, что 301 и 302 перенаправить настройки верны очень легко. When entering into the address bar of the old address, we observe what is happening. The change of address indicates that everything is fine with the redirect. The address remains the same – you need to look for the source of the problem, but first, we advise you to clean the cache and try again.
How to fix HTTP 302 error?
Способ 1: проверьте конфигурацию сервера
Приложение может работать на сервере, который использует одну из этих двух наиболее распространенных программ веб-сервера, Nginx или Apache. На эти два веб-сервера приходится более 84 процентов глобальной программы веб-сервера! Therefore, the first step in determining the 302 response code is checking the mandatory redirect instructions in the webserver program configuration file.
Для веб-сервера Apache
Шаг 2: Найдите директивы mod_rewrite
Обратите внимание на дополнительный баннер в нижней части RewriteRule, который ясно показывает, что код ответа должен быть 302, показывая агенту браузера, что это временное перенаправление.
Для веб-сервера Nginx
Шаг 1: Откройте файл nginx.conf
Если ваш веб-сервер работает на Nginx, вам следует искать совершенно другой файл конфигурации. Этот файл указан как nginx.conf по умолчанию и находится в одном из общих каталогов, перечисленных ниже:
/ usr / local / nginx / conf, / etc / nginx или, / usr / local / etc / nginx.
Шаг 2: Перепишите директивы в файле nginx.conf
После обнаружения откройте файл nginx.conf в текстовом редакторе и найдите директивы перезаписи, относящиеся к индикатору перенаправления.
Например, это простая директива блока (объявленная как набор операторов), которая устанавливает виртуальный сервер путем создания временного перенаправления с abc.com на временный-abc.com:
Nginx переписывает директивы параллельно с Apache RewriteRule и RewriteCond, потому что они обычно содержат более сложные текстовые шаблоны поиска.
Шаг 3: Проверьте политику замены файла nginx.conf
В любом случае проверьте файл nginx.conf для политики замены исключений, которая содержит флаг перенаправления (другой код ответа возврата постоянного ключа 301).
Обратите внимание на любые исключения перед перезагрузкой сервера, чтобы проверить, решена ли проблема.
Способ 2: поиск устаревшего программного обеспечения
В документе спецификации RFC для HTTP 1.0 говорится, что цель кода ответа «302 найдено» предназначена для указания того, что клиент должен выполнить временное перенаправление.
However, many new browsers will process the code 302 received through the POST request as an invalid GET request. This has triggered snags and confusion with particular web server programs that attempt to force the browser to perform the right work when it needs to be redirected temporarily. Чтобы решить эту проблему, документ спецификации RFC HTTP 1.1 возвратил 303 кода ответа, еще 307 временных перенаправлений, что является понятным способом управления POST-to-GET или временными переходными ответами.
Метод 3: Очистка бревен
Почти все веб-приложения хранят записи на сервере. Журнал приложения обычно представляет историю приложения, например, какие страницы, серверы были запрошены и подключены, которые были получены из предоставленной базы данных и т. Д.
Журналы сервера подключены к текущему устройству, на котором запускаются программы, и обычно содержат информацию о состоянии и работоспособности всех подключенных служб и даже информацию о сервере. Запишите Google [PLATFORM_NAME] в CMS или используйте [PROGRAMMING_LANGUAGE], чтобы зарегистрироваться и зарегистрировать [OPERATING_SYSTEM] при запуске пользовательского приложения для получения дополнительной информации для получения этих записей.
Способ 4: исправить код приложения
В случае сбоя всех описанных выше способов проблема может заключаться в коде пользователя приложения, вызвавшего проблему.
Попробуйте определить причину проблемы, вручную обнаружив приложение и проанализировав его в файлах журнала сервера и приложений. Рекомендуется скопировать полное приложение на локальный компьютер для разработки и пройти по нему, чтобы точно узнать, что происходит с 302 сканированием, и увидеть код для каждого приложения.
Заключение
Наконец, как вы видели, нам не нужно сильно бояться ошибок перенаправления HTTP 302. Не углубляясь в это, они представляют собой фантастический способ избежать потери трафика на наших веб-страницах с неизбежными изменениями, которые возникают в течение многих лет. I hope that, after reading this article, you will not get chills every time about how do I fix the 302 moved temporarily error. Если вы хотите внести свой вклад в сообщение, или если у вас есть вопрос или просто хотите высказать свое мнение, не стесняйтесь комментировать ниже!
Uncaught InstagramScraper\Exception\InstagramException: Response code is 302. Body: Something went wrong #811
Comments
alabamaster commented Nov 9, 2020
Fatal error: Uncaught InstagramScraper\Exception\InstagramException: Response code is 302. Body: Something went wrong. Please report issue. in /home/web/. /vendor/raiym/instagram-php-scraper/src/InstagramScraper/Instagram.php:426 Stack trace: #0 /home/web/. /tests/index.php(10): InstagramScraper\Instagram->getAccount(‘alabamaster1337’) #1thrown in /home/web/. /vendor/raiym/instagram-php-scraper/src/InstagramScraper/Instagram.php on line 426
this from example getAccountByUsername.php
The text was updated successfully, but these errors were encountered:
Theder-old commented Nov 10, 2020
It seems, that you ip is not allowded to check instagram account without authorization. You can authorize to scrape accounts or change ip.
restyler commented Dec 4, 2020 •
Just changing ip to another one in the datacenter may fail, since Instagram blocked datacenter ip ranges a long time ago. Even residential proxies are actively banned by Instagram every day. Try your residential network to make sure that it’s not an issue in the scraper code. If you still need to run your scraper in datacenter, take a look at https://github.com/restyler/instagram-php-scraper which is the proxified version of this scraper, it uses smart proxy network and handles retries and response quality control for you.
stale bot commented Jun 9, 2021
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Unfortunately, it can be difficult to differentiate between all the possible HTTP response codes and determine the exact cause of errors like the 302 Found code. There are dozens of possible HTTP status codes used to represent the complex relationship between the client, a web application, a web server, and the multitude of third-party web services that may be in use, so determining the cause of a particular status code can be challenging. In this article we’ll examine the 302 Found code by looking at a few troubleshooting tips, along with some potential fixes for common problems that might be causing this issue within your own web applications, so let’s get to it!
The Problem is Server-Side
However, it’s important to keep in mind that the 302 Found response code is used for completely different purposes than the 301 Moved Permanently we looked at last week. In the case of the former, the redirection should be temporary (i.e. just for the current, single request) — the browser should “remember” the original URI and process any future requests using that same URI. However, with a 301 Moved Permanently code the browser is being told that the original URI is no longer valid, so all future requests should use the new URI provided by the Location header.
Since the 302 Found indicates that something has gone wrong within the server of your application, we can largely disregard the client side of things. If you’re trying to diagnose an issue with your own application, you can immediately ignore most client-side code and components, such as HTML, cascading style sheets (CSS), client-side JavaScript, and so forth. This doesn’t apply solely to web sites, either. Many smart phone apps that have a modern looking user interface are actually powered by a normal web application behind the scenes; one that is simply hidden from the user. If you’re using such an application and a 302 Found occurs, the issue isn’t going to be related to the app installed on your phone or local testing device. Instead, it will be something on the server-side, which is performing most of the logic and processing behind the scenes, outside the purview of the local interface presented to the user.
If your application is generating unexpected 302 Found response codes there are a number of steps you can take to diagnose the problem.
Start With a Thorough Application Backup
As with anything, it’s better to have played it safe at the start than to screw something up and come to regret it later on down the road. As such, it is critical that you perform a full backup of your application, database, and so forth, before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application onto a secondary staging server that isn’t “live,” or isn’t otherwise active and available to the public. This will give you a clean testing ground with which to test all potential fixes to resolve the issue, without threatening the security or sanctity of your live application.
Diagnosing a 302 Found Response Code
A 302 Found response code indicates that the requested resource should temporarily be accessed at a different URI. However, it’s entirely possible that the server is misconfigured, causing it to improperly respond with 302 Found codes, instead of the standard and expected 200 OK code of a normal, functional request. Thus, a large part of diagnosing the issue will be going through the process of double-checking what resources/URLs are generating 302 Found response codes and determining if these codes are appropriate or not.
Troubleshooting on the Server-Side
Here are some additional tips to help you troubleshoot what might be causing the 302 Found to appear on the server-side of things:
Confirm Your Server Configuration
For example, here is a simple RewriteCond and RewriteRule combination that matches all incoming requests to example.com and establishes a temporarily redirection to that same URI on the temporary-example.com domain instead:
Check for Outdated Software
The RFC specification document for HTTP 1.0 stated that the purpose of a 302 Found response code was to indicate the client should perform a temporary redirection. However, many newer browsers would process a 302 code received via a POST request as an erroneous GET request instead, which caused problems and confusion for some web server softwares trying to get browsers to perform the proper task when temporary redirection was required. To resolve this the HTTP 1.1 RFC specification document added the 303 See Other and 307 Temporary Redirect response codes, which are explicit means of handling POST-to-GET and temporary direct responses, respectively.
Scour the Logs
Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself. Google “logs [PLATFORM_NAME]” if you’re using a CMS, or “logs [PROGRAMMING_LANGUAGE]” and “logs [OPERATING_SYSTEM]” if you’re running a custom application, to get more information on finding the logs in question.
Debug Your Application Code
If all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from through manually debugging your application, along with parsing through application and server logs. Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 302 Found occurred and view the application code at the moment something goes wrong.
No matter what the cause, the appearance of a 302 Found within your own web application is a strong indication that you may need an error management tool to help you automatically detect such errors in the future. The best of these tools can even alert you and your team immediately when an error occurs. Airbrake’s error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.
Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!
Monitor Your App Free for 30 Days
Discover the power of Airbrake by starting a free 30-day trial of Airbrake. Quick sign-up, no credit card required. Get started.
Импортировал записи, кстати, тоже не без косяков. Дело в том, что вести своего «хомячка» я начал с 16-го октября. А на лиру экспорт сейчас делается «блоками» по три месяца. И вот осень 2008-го года у меня была в подвешенном состоянии, т.к. часть постов нужно было вырезать ручками. Таки шо я сделал? На локалхосте у меня установлен WordPress. Импортировал в него лирушечные посты за осень 2008-го года, порезал всё ненужное, экспортировал оставшееся. И этот остаток уже импортировал на dandr.su. Всё логично, НО! Когда проводил последний импорт, машинально тыцнул на инструмент импорта для ЛиРу и понял это, лишь когда увидел посты в битой кодировке (ЛиРу выдаёт в windows-1251, а WordPress — в UTF-8). Пришлось руками удалять всё, что только что добавил. И вот на последнем десятке удаляемых постов получил сообщение:
Почему-то мне вспомнилось, что при тестировании ХостерТестера у меня один раз было превышение допустимого количества записей в БД. И я наивно предположил, что сейчас аналогичная проблема. Что делать? Ждать час? Целый час. Когда победа так близко? Да и спать хочется уже… Оставлять назавтра тоже ломает. Стучусь в саппорт (кстати, тут уместно в очередной раз пропиарить Эскхостинг: в любое время суток можно получить поддержку через чат), объясняю, что я дебил и малость накосячил. Скидываю тескт ошибки. Вобщем, гуглили с саппортом параллельно, поскольку оказалось, что MySQL тут совершенно не при чём. А прикол в том, что я с давних пор зеркалил блог с ЛиРу на ЖЖ, а в WordPress’е у меня установлин плагин для кросспостинга на ЖЖ. Видимо, импортированные только что посты распознились по id на ЖЖ и плагин кросспостинга не давал их удалить из-за какого-то там конфликта с самим ЖЖ. Вобщем, дело мутное, но решается банальным отключением плагина кросспостинга на время удаления и добавления постов. ЗЫ Кстати, про ХостерТестер: Эскхостинг благополучно рвёт конкурентов в своей ценовой категории. Сравним разве что с Хостфабрикой, но та раза в 4 дороже. Выводы делаем сами)))
Parser called. Parsing argument ’16-го октября’, 1 => », 2 => ‘http://www.dandr.su/2008/10/16/on-skazal-poexali/’, 3 => », 4 => ’16-го октября’, )> Against link Checking link «http://www.dandr.su/2008/10/16/on-skazal-poexali/» VS exclusion list ‘http://www.dandr.su’, 1 => ‘https://www.dandr.su’, 2 => ‘javascript’, 3 => ‘mailto’, 4 => ‘skype’, 5 => ‘/’, 6 => ‘#’, 7 => ‘0’, )> In exclusion list (http://www.dandr.su), not masking. Parser called. Parsing argument ‘ХостерТестера’, 1 => », 2 => ‘http://tools.blogocms.ru/’, 3 => », 4 => ‘ХостерТестера’, )> Against link Checking link «http://tools.blogocms.ru/» VS exclusion list ‘http://www.dandr.su’, 1 => ‘https://www.dandr.su’, 2 => ‘javascript’, 3 => ‘mailto’, 4 => ‘skype’, 5 => ‘/’, 6 => ‘#’, 7 => ‘0’, )> Not in exclusion list, masking. Parser called. Parsing argument ‘Эскхостинг’, 1 => », 2 => ‘http://www.eskhosting.ru/?rb=9295’, 3 => », 4 => ‘Эскхостинг’, )> Against link Checking link «http://www.eskhosting.ru/?rb=9295» VS exclusion list ‘http://www.dandr.su’, 1 => ‘https://www.dandr.su’, 2 => ‘javascript’, 3 => ‘mailto’, 4 => ‘skype’, 5 => ‘/’, 6 => ‘#’, 7 => ‘0’, )> Not in exclusion list, masking. Parser called. Parsing argument ‘ХостерТестер’, 1 => », 2 => ‘http://tools.blogocms.ru/’, 3 => », 4 => ‘ХостерТестер’, )> Against link Checking link «http://tools.blogocms.ru/» VS exclusion list ‘http://www.dandr.su’, 1 => ‘https://www.dandr.su’, 2 => ‘javascript’, 3 => ‘mailto’, 4 => ‘skype’, 5 => ‘/’, 6 => ‘#’, 7 => ‘0’, )> Not in exclusion list, masking. Parser called. Parsing argument ‘Эскхостинг’, 1 => », 2 => ‘http://www.eskhosting.ru/?rb=9295’, 3 => », 4 => ‘Эскхостинг’, )> Against link Checking link «http://www.eskhosting.ru/?rb=9295» VS exclusion list ‘http://www.dandr.su’, 1 => ‘https://www.dandr.su’, 2 => ‘javascript’, 3 => ‘mailto’, 4 => ‘skype’, 5 => ‘/’, 6 => ‘#’, 7 => ‘0’, )> Not in exclusion list, masking. 5 replacements done. Filter returned:
Импортировал записи, кстати, тоже не без косяков. Дело в том, что вести своего «хомячка» я начал с 16-го октября. А на лиру экспорт сейчас делается «блоками» по три месяца. И вот осень 2008-го года у меня была в подвешенном состоянии, т.к. часть постов нужно было вырезать ручками. Таки шо я сделал? На локалхосте у меня установлен WordPress. Импортировал в него лирушечные посты за осень 2008-го года, порезал всё ненужное, экспортировал оставшееся. И этот остаток уже импортировал на dandr.su. Всё логично, НО! Когда проводил последний импорт, машинально тыцнул на инструмент импорта для ЛиРу и понял это, лишь когда увидел посты в битой кодировке (ЛиРу выдаёт в windows-1251, а WordPress — в UTF-8). Пришлось руками удалять всё, что только что добавил. И вот на последнем десятке удаляемых постов получил сообщение:
Почему-то мне вспомнилось, что при тестировании ХостерТестера у меня один раз было превышение допустимого количества записей в БД. И я наивно предположил, что сейчас аналогичная проблема. Что делать? Ждать час? Целый час. Когда победа так близко? Да и спать хочется уже… Оставлять назавтра тоже ломает. Стучусь в саппорт (кстати, тут уместно в очередной раз пропиарить Эскхостинг: в любое время суток можно получить поддержку через чат), объясняю, что я дебил и малость накосячил. Скидываю тескт ошибки. Вобщем, гуглили с саппортом параллельно, поскольку оказалось, что MySQL тут совершенно не при чём. А прикол в том, что я с давних пор зеркалил блог с ЛиРу на ЖЖ, а в WordPress’е у меня установлин плагин для кросспостинга на ЖЖ. Видимо, импортированные только что посты распознились по id на ЖЖ и плагин кросспостинга не давал их удалить из-за какого-то там конфликта с самим ЖЖ. Вобщем, дело мутное, но решается банальным отключением плагина кросспостинга на время удаления и добавления постов. ЗЫ Кстати, про ХостерТестер: Эскхостинг благополучно рвёт конкурентов в своей ценовой категории. Сравним разве что с Хостфабрикой, но та раза в 4 дороже. Выводы делаем сами)))
Checking post for meta. Filter will be applied Processing text:
Импортировал записи, кстати, тоже не без косяков. Дело в том, что вести своего «хомячка» я начал с 16-го октября. А на лиру экспорт сейчас делается «блоками» по три месяца. И вот осень 2008-го года у меня была в подвешенном состоянии, т.к. часть постов нужно было вырезать ручками. Таки шо я сделал? На локалхосте у меня установлен WordPress. Импортировал в него лирушечные посты за осень 2008-го года, порезал всё ненужное, экспортировал оставшееся. И этот остаток уже импортировал на dandr.su. Всё логично, НО! Когда проводил последний импорт, машинально тыцнул на инструмент импорта для ЛиРу и понял это, лишь когда увидел посты в битой кодировке (ЛиРу выдаёт в windows-1251, а WordPress — в UTF-8). Пришлось руками удалять всё, что только что добавил. И вот на последнем десятке удаляемых постов получил сообщение:
Почему-то мне вспомнилось, что при тестировании ХостерТестера у меня один раз было превышение допустимого количества записей в БД. И я наивно предположил, что сейчас аналогичная проблема. Что делать? Ждать час? Целый час. Когда победа так близко? Да и спать хочется уже… Оставлять назавтра тоже ломает. Стучусь в саппорт (кстати, тут уместно в очередной раз пропиарить Эскхостинг: в любое время суток можно получить поддержку через чат), объясняю, что я дебил и малость накосячил. Скидываю тескт ошибки. Вобщем, гуглили с саппортом параллельно, поскольку оказалось, что MySQL тут совершенно не при чём. А прикол в том, что я с давних пор зеркалил блог с ЛиРу на ЖЖ, а в WordPress’е у меня установлин плагин для кросспостинга на ЖЖ. Видимо, импортированные только что посты распознились по id на ЖЖ и плагин кросспостинга не давал их удалить из-за какого-то там конфликта с самим ЖЖ. Вобщем, дело мутное, но решается банальным отключением плагина кросспостинга на время удаления и добавления постов. ЗЫ Кстати, про ХостерТестер: Эскхостинг благополучно рвёт конкурентов в своей ценовой категории. Сравним разве что с Хостфабрикой, но та раза в 4 дороже. Выводы делаем сами)))
