417 Expectation Failed

На днях потребовалось научить одну .net-программулину работать через прокси. Быстренько были внесены изменения в интерфейс настроек, заполнено свойство Proxy объекта класса HttpWebRequest. Но тут что-то пошло не так. Страничка в Firefox открывалась, а вот при попытке выполнить запрос через софтину мы получали ответ от сервера 417 Expectation Failed. После прочтения материала и просмотра заголовков, отправляемых приложением, стало понятно, что объект HttpRequest при отправке POST-запроса автоматически добавляет заголовок Expect. А прокси-сервер Squid3 по умолчанию отвергает такие запросы с кодом ошибки 417:

#  TAG: ignore_expect_100       on|off

#       This option makes Squid ignore any Expect: 100-continue header present

#       in the request. RFC 2616 requires that Squid being unable to satisfy

#       the response expectation MUST return a 417 error.

#

#       Note: Enabling this is a HTTP protocol violation, but some clients may

#       not handle it well..

#Default:

#ignore_expect_100 off

Хотя правильнее отключить применение этого заголовка при работе через прокси:

         string postData = String.Format("lg={0}&pw={1}", login, pass);

            HttpWebRequest request = (HttpWebRequest)WebRequest.Create(LOGIN_URL);

            request.Proxy = proxy;

            request.CookieContainer = new CookieContainer();

            request.CookieContainer.Add(cookie);

            request.Method = WebRequestMethods.Http.Post;

            request.AllowWriteStreamBuffering = true;

            request.ProtocolVersion = HttpVersion.Version11;

            request.AllowAutoRedirect = true;

            request.ContentType = "application/x-www-form-urlencoded";

            request.Timeout = REQTIMEOUT;

            request.ServicePoint.Expect100Continue = proxy == null; 

 

Тернарный оператор на python

Нравилась мне эта конструкция в .net. Её аналог в мире python:

i = 5 if a > 7 else 0

Если верить этому, то транслируется в:

if a > 7:
   i = 5
else:
   i = 0

Долго выполняется .GetRequestStream()

Во время отладки случайно заметил, что для пустого метода POST создание запроса выполняется очень долго. Поход в гугл выдал это.

Как оказалось, HttpWebRequest по-умолчанию настроен на автоопределение настроек прокси-сервера, что есть очень медленно. Чтобы этого не происходило, при инициализации HttpWebRequest необходимо:

<HttpWebRequest>.Proxy = null;

Еще один любопытный момент проявляется при использовании опции:

 <HttpWebRequest>.AllowAutoRedirect = true;

При редиректе на страницу авторизации, которая устанавливает куку, эту куку из response мы получить не сможем, потому что ее там просто нет. Так что этот параметр в false и ручками. 

UPDATE FROM SELECT в PostgreSQL

В процессе изучения PostgreSQL столкнулся со странным поведением оного при попытке выполнить подобный запрос:

UPDATE
    Table
SET
    Table.col1 = other_table.col1,
    Table.col2 = other_table.col2
FROM
    Table
INNER JOIN
    other_table
ON
    Table.id = other_table.id

Все записи перезаписывались первой записью из результата INNER JOIN. Зато отлично сработал такой код:

     UPDATE  user u
     SET     balance = balance + p.amount
     FROM    (
        SELECT  user_id, SUM(amount) AS amount
        FROM    payment
        WHERE   id IN (36, 38, 40)
        GROUP BY
                user_id
      ) p 

      WHERE u.id = p.user_id 

Сброс автоинкремента в MS SQL

Для того, чтобы установить текущее значение автоинкремента в MS SQL необходимо выполнить:

DBCC CHECKIDENT ('[DBName].[dbo].[TableName]', RESEED, startValue)

Где startValue соответствует значению, с которого + 1 начнется нумерация при выполнении следующей INSERT.

Жизнь давно подсказывала, что пора бы завести место для записей, отличное от разрозненных клочков бумаги. В очередной раз наступив на грабли и потирая ушибленные места решил воплотить в жизнь сие устремление.

Понедельник, 18 февраля 2013 года. Несколько дней ломал голову над ошибкой при подключении к SQL Server 2012: "невозможно создать контекст sspi". Все бы ничего, но приложения от учетных записей простых пользователей легко подключались к серваку и писали в базу данных, что несколько сбило меня с толку и вместо того, чтобы искать, чего такого необычного на моём компе, я начал гуглить в направлении политик безопасности при подключении пользователей с правами администратора.

Гугл выдавал целый ворох тем и постов с аналогичным сообщением об ошибке, но в основном они указывали на мануал от МС http://support.microsoft.com/kb/811889/ru, который к моему случаю не имел никакого отношения. Верный ответ оказался здесь: http://forum.ixbt.com/topic.cgi?id=14:56395-58#1861. Собака порылась в рабочем интернете, раздаваемом через VPN, для которого используются доменные учетные данные, но не соответствующие тем, что принадлежат основной учётке (Всегда, блин, считал, что раздавать интернет через VPN - дурная затея))). Соответственно, management studio, да и любой другой софт, который пытался подключиться к серверу, представлялся не теми учетными данными. Откуда и грабли.

Напоследок, рецепт:

Чтобы это исправить, нужно подправить файл
C:\Users\Pupkin\AppData\Roaming\Microsoft\Network\Connections\Pbk\rasphone.pbk
заменив параметр UseRasCredentials с 1 на 0