Доброго всем времени суток!
Я хочу использовать Client Application Services, для этого решил ознакомиться и попробовать пройти примеры из этой ссылки: http://msdn.microsoft.com/en-us/library/bb546195(v=VS.90).aspx
Поначалу все было хорошо. Но теперь все время выскакивает ошибка — Базовое соединение закрыто: Непредвиденная ошибка при приеме. При вызове метода:
bool isAuthorized = false; try { // Call ValidateUser with empty strings in order to display the // login dialog box configured as a credentials provider. isAuthorized = Membership.ValidateUser( String.Empty, String.Empty); // <--- ЗДЕСЬ ошибка } catch (System.Net.WebException) { if (DialogResult.OK == MessageBox.Show( "Unable to access the authentication service." + Environment.NewLine + "Attempt login in offline mode?", "Warning", MessageBoxButtons.OKCancel, MessageBoxIcon.Warning)) { ConnectivityStatus.IsOffline = true; isAuthorized = Membership.ValidateUser( String.Empty, String.Empty); } } if (!isAuthorized) { MessageBox.Show("Unable to authenticate.", "Not logged in", MessageBoxButtons.OK, MessageBoxIcon.Error); Application.Exit(); } return isAuthorized; }
Подскажите что случилось с вэб сервисом?
P.S. Когда вэб-сервис работал, через профайлер sql сервера я видел обращения к базе. Сейчас же никаких обращений нет.
Дополнение: VS 2008 SP1 .NET 3.5 Windows XP
Используется внутренний вэб сервер студии — ASP.NET Development Server
Во время возникновения ошибки с Событиях Windows появляются следующие сообщения:
Код события: 3005
Сообщение о событии: Возникло необработанное исключение.
Время события: 26.10.2010 13:21:55
Время события (UTC): 26.10.2010 9:21:55
Идентификатор события: 249a08db8bee4c059cbb12343a99ff13
Последовательность событий: 2
Появление события: 1
Код подробностей события: 0
Сведения о приложении:
Домен приложения: 7b2c11fe-1-129325585149428287
Уровень доверия: Full
Виртуальный путь к приложению: /ProfitWeb
Путь к приложению: E:WIN_DEVELOPProfitAuthServiceProfitWeb
Имя компьютера: PORAA
Сведения о процессе:
Идентификатор процесса: 3740
Имя процесса: WebDev.WebServer.exe
Имя учетной записи: ID_BLABLAporaa
Сведения об исключении:
Тип исключения: HttpException
Сообщение об исключении: После передачи заголовков HTTP перенаправление невозможно.
Сведения о запросе:
URL запроса: http://localhost:55555/ProfitWeb/Authentication_JSON_AppService.axd/Login
Путь запроса: /ProfitWeb/Authentication_JSON_AppService.axd/Login
Адрес узла пользователя: 127.0.0.1
Пользователь:
Проверка подлинности: False
Тип проверки подлинности:
Имя учетной записи потока: ID_BLABLAporaa
Сведения о потоке:
Идентификатор потока: 4
Имя учетной записи потока: ID_BLABLAporaa
Выполняется олицетворение: False
Трассировка стека: в System.Web.HttpResponse.Redirect(String url, Boolean endResponse)
в System.Web.Security.FormsAuthenticationModule.OnLeave(Object source, EventArgs eventArgs)
в System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
в System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
Подробности пользовательского события:
Дополнительные сведения можно найти в центре справки и поддержки, в «http://go.microsoft.com/fwlink/events.asp».
«Базовое соединение закрыто: непредвиденная ошибка при передаче.». Почтальон идет нормально с теми же заголовками
сценарий
- Win10 x64
- VS2013
Я пытаюсь сделать WebRequest, но я получаю следующую ошибку:
базовое соединение закрыто: непредвиденная ошибка при передаче.
копаясь во внутреннем исключении, я получил:
«Не удается прочитать данные из транспортного соединения: существующее соединение было принудительно закрыто удаленный хост.»
код, который выполняет запрос, следующий:
private static Hashtable exec (String method, String uri, Object data, String contentType) {
Hashtable response;
HttpWebRequest request = (HttpWebRequest)WebRequest.Create (API_BASE_URL + uri);
request.UserAgent = "MercadoPago .NET SDK v"+MP.version; //version resolves to 0.3.4
request.Accept = MIME_JSON; // application/json
request.Method = method; //GET
request.ContentType = contentType; //application/json
setData (request, data, contentType); //setData in this case does nothing.
String responseBody = null;
try {
HttpWebResponse apiResult = (HttpWebResponse)request.GetResponse (); //Error throws here
responseBody = new StreamReader (apiResult.GetResponseStream ()).ReadToEnd ();
response = new Hashtable();
response["status"] = (int) apiResult.StatusCode;
response["response"] = JSON.JsonDecode(responseBody);
} catch (WebException e) {
Console.WriteLine (e.Message);
}
}
что я уже сделал:
- сделал запрос через консольное приложение и контроллер приложений MVC. Оба выбрасывают одно и то же исключение
- вызвал API через Postman с точно такими же заголовками, что приносит мне контент правильно.
эти запросы работали нормально через c# около 4 дней назад, и я внезапно начал проблемы, но учитывая тот факт, что он хорошо реагирует на Postman, я не могу понять, в чем проблема.
вот ответ

EDIT: сделал оба запроса с прослушиванием скрипача. Результат для Postman показывает прямой запрос к API с HTTPS. При попытке с моим ConsoleApplication он показывает HTTP-запрос, который делает туннель к конечной точке API, порту 443.

TextView от Fiddler для запроса туннеля говорит следующее:

Я заметил поле «время», которое относится к очень старой дате, но я не знаю, что это значит.
5 ответов
вы можете попробовать код ниже:
string url = ""; // url of the endpoint
WebClient client = new WebClient();
ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
client.Encoding = Encoding.UTF8;
client.Headers.Add("content-type", "application/json"); // same as other parameters in the header
var data = client.DownloadString(url);
это своего рода плохая практика, чтобы включить Tls12, как это —
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
в будущем, если вам нужно будет использовать более высокую версию TLS, вам придется обновить свой код.
Если вы используете более старую версию .NET, вы можете просто переключить ее более высокую версию, в которой tls12 включен по умолчанию.
например, это простое изменение в вашей сети.config автоматически включит Tls12 —
<httpRuntime targetFramework="4.6.1"/>
(в качестве ссылки для других, у кого такая же проблема) это также может быть результатом Двойной Прыжок проблема , где вы должны передать зачисленного пользователя (в пуле) на проходящий сервер или из одной среды в другую , в противном случае пользователь установлен в «анонимный/пользователь», и вы получите «существующее соединение было принудительно закрыто удаленным хостом.- Ошибка!—3—>
разобрался. Мне нужно было включить использование TLS1.2.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
2
автор: undefined is our god
Я нашел ту же ошибку, просто упомяну
запрос.UserAgent = «все, что вы хотите»;
Все для эффективного участия в торгах
Получить бесплатный доступ
или
заказать обратный звонок
![]()
Попробовать бесплатно
Обратный звонок
![]()
Главная/FAQ/База знаний/Seldon 1.7: Ошибка: Базовое соединение закрыто: Непредвиденная ошибка при приеме
Ошибка: Базовое соединение закрыто: Непредвиденная ошибка при приеме
Дата публикации: 22.10.2021
![]()
Устранение ошибки: Базовое соединение закрыто: Непредвиденная ошибка при приеме
Если при установки выходит ошибка, связанная с блокировкой сервера, то нужно скорректировать настройки КриптоПРО.
Например:
- Базовое соединение закрыто: Непредвиденная ошибка при приеме
Решение:
1. Необходимо проверить настройки подключения

2. Данная ошибка возникает при установленном КриптоПРО. В данном случае в настройках необходимо указать:
- «Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети» — Отключить
- «Установить уровень шифрования клиентских подключений» — Включить — Низкий

Copyright © 2008 — 2023 Ваши данные конфиденциальны и служат только для связи с менеджером!
I have been testing a vendors webservice for the past month which was working fine. Then one day it started timing out. After setting the timeout property higher I started getting this response back. I was told that no changes were made on their side and that they could not recreate my issue. I was also told that there was no changes made on our network.
I have been searching around for a day or two here but have proved fruitless on my attempts to get closer to a solution. At this point I truly believe it is on their end but my question is, is there a way to prove more definitively where the issue is short of having their server logs? The other wrinkle here which makes me feel it is their problem is that they have another webservice which I can still get valid responses back from.
I use fiddler2 but I don’t know if I can test a webservice with the request builder, it doesn’t seem to work.
My setup is as follows I am using visual studio 2008 C# asp.net project with a web reference to this service.
Thank you very much in advance for your help
asked Nov 17, 2010 at 17:43
2
Use Wireshark to get network traces. It’ll be tricky to diagnose if you’re using HTTPS, but it’s lower-level than Fiddler, which means they won’t be able to claim that the proxying is causing problems.
Basically, you need to make sure that the request really is being sent, and that you’re not getting a response back in time.
answered Nov 17, 2010 at 17:46
Jon SkeetJon Skeet
1.4m850 gold badges9042 silver badges9132 bronze badges
5
I have been testing a vendors webservice for the past month which was working fine. Then one day it started timing out. After setting the timeout property higher I started getting this response back. I was told that no changes were made on their side and that they could not recreate my issue. I was also told that there was no changes made on our network.
I have been searching around for a day or two here but have proved fruitless on my attempts to get closer to a solution. At this point I truly believe it is on their end but my question is, is there a way to prove more definitively where the issue is short of having their server logs? The other wrinkle here which makes me feel it is their problem is that they have another webservice which I can still get valid responses back from.
I use fiddler2 but I don’t know if I can test a webservice with the request builder, it doesn’t seem to work.
My setup is as follows I am using visual studio 2008 C# asp.net project with a web reference to this service.
Thank you very much in advance for your help
asked Nov 17, 2010 at 17:43
2
Use Wireshark to get network traces. It’ll be tricky to diagnose if you’re using HTTPS, but it’s lower-level than Fiddler, which means they won’t be able to claim that the proxying is causing problems.
Basically, you need to make sure that the request really is being sent, and that you’re not getting a response back in time.
answered Nov 17, 2010 at 17:46
Jon SkeetJon Skeet
1.4m850 gold badges9042 silver badges9132 bronze badges
5
Кто-нибудь знает эту проблему:
«Базовое соединение было закрыто: при получении произошла непредвиденная ошибка».?
Как решить эту проблему?
4 ответа
Я увеличил время выключения в пуле приложений, и теперь все работает нормально.
1
tiny
12 Июн 2009 в 07:23
Да, «основное соединение было закрыто», или, точнее, браузер был закрыт до загрузки страницы.
Всегда есть вероятность, что это реальная ошибка на уровне сети (т. е. плохой прокси-сервер), но вы не предоставляете достаточно подробностей.
0
SpliFF
11 Июн 2009 в 13:51
Поиск в Google по запросу «Базовое соединение было закрыто: при приеме произошла непредвиденная ошибка». выдает эти результаты.
Отсюда этот пост:
… Я добавил следующий код в свой файл reference.cs (который необходимо делать каждый раз, когда я обновляю ссылку на веб-сервис), чтобы присвоить значение проверки активности false, чтобы разрешить закрытие и повторное открытие соединения.
protected override WebRequest GetWebRequest(Uri uri) { HttpWebRequest webRequest = (HttpWebRequest) base.GetWebRequest(uri); webRequest.KeepAlive = false; webRequest.ProtocolVersion=HttpVersion.Version10; return webRequest; } I have also added a reference to System.Net via a using statement toимпортировать пространство имен HttpWebRequest.
0
eKek0
12 Июн 2009 в 07:30
Это общая ошибка, которая может быть вызвана чем угодно (в моем случае некоторые изображения tiff вызывали ошибку gdi+ в службе wcf).
Начните с проверки:
- Файлы журналов IIS
- Файлы журнала приложений (т. е. включите ведение журнала службы, если вы используете службы)
- Разрешения и безопасность
0
Goran
25 Окт 2009 в 11:31