Диссертация Кочарян С.Г — копия (1195360), страница 8
Текст из файла (страница 8)
В ответ на условный GET,тело запрашиваемого ресурса передается только, если он изменялся после57даты, указанной в заголовке «If-Modified-Since». Алгоритм определения этоговключает в себя следующие случаи:если код статуса ответа на запрос будет отличаться от «200 OK», илидата, указанная в поле заголовка «If-Modified-Since» некорректна, ответ будетидентичен ответу на обычный запрос GET;если после указанной даты ресурс изменялся, ответ будет такжеидентичен ответу на обычный запрос GET;если ресурс не изменялся после указанной даты, сервер вернет кодстатуса «304 Not Modified».Использование метода условный GET направлено на разгрузку сети, таккак он позволяет не передавать по сети избыточную информацию.Метод HEAD аналогичен методу GET, за исключением того, что в ответесервер не возвращает «Тело-Ответа».
Метаинформация, содержащаяся вHTTP заголовках ответа на запрос HEAD, должна быть идентичнаинформации HTTP заголовков ответа на запрос GET. Данный метод можетиспользоваться для получения метаинформации о ресурсе без передачи посети самого ресурса. Метод "Условный HEAD", аналогичный условному GET,не определен.Метод POST используется для запроса сервера, чтобы тот принялинформацию, включенную в запрос, как субординантную для ресурса,указанного в Строке Статус в поле URI-Запроса. Метод POST был разработан,чтобы была возможность использовать один общий метод для следующихфункций: аннотация существующих ресурсов; добавление сообщений в группы новостей, почтовые списки илиподобные группы статей; доставка блоков данных процессам, обрабатывающим данные; расширение баз данных через операцию добавления.Реальная функция, выполняемая методом POST, определяется сервером иобычно зависит от URI- Запроса.
Добавляемая информация рассматривается58как субординатная указанному URI в том же смысле, как файл субординатенкаталогу, в котором он находится, новая статья субординатна группе новостей,в которую она добавляется, запись субординатна базе данных.Клиент может предложить URI для идентификации нового ресурса,включив в запрос заголовок "URI". Тем не менее, сервер долженрассматривать этот URI только как совет и может сохранить тело запроса поддругим URI или вообще без него.Если в результате обработки запроса POST был создан новый ресурс, ответдолжен иметь код статуса, равный "201 Created", и содержать URI новогоресурса.Метод PUT запрашивает сервер о сохранении «Тело-Запроса» под URI,равным URI-Запроса.
Если URI-Запроса ссылается на уже существующийресурс, «Тело-Запроса» должно рассматриваться как модифицированнаяверсия данного ресурса. Если ресурс, на который ссылается URI-Запроса несуществует, и данный URI может рассматриваться как описание для новогоресурса, сервер может создать ресурс с данным URI.
Если был создан новыйресурс, сервер должен информировать направившего запрос клиента черезответ с кодом статуса «201 Created». Если существующий ресурс былмодифицирован, должен быть послан ответ «200 OK», для информированияклиента об успешном завершении операции. Если ресурс с указанным URI неможетбытьсозданилимодифицирован,должнобытьпосланосоответствующее сообщение об ошибке.Фундаментальное различие между методами POST и PUT заключается вразличном значении поля URI-Запроса. Для метода POST данный URIуказывает ресурс, который будет управлять информацией, содержащейся втеле запроса, как неким придатком. Ресурс может быть обрабатывающимданные процессом, шлюзом в какой-нибудь другой протокол, или отдельнымресурсом, допускающим аннотации. В противоположность этому, URI длязапроса PUT идентифицирует информацию, содержащуюся в «СодержаниеЗапроса».
Использующий запрос PUT точно знает какой URI он собирается59использовать, и получатель запроса не должен пытаться применить этотзапрос к какому-нибудь другому ресурсу.МетодDELETEиспользуетсядляудаленияресурсов,идентифицированных с помощью URI-Запроса. Результаты работы данногометода на сервере могут быть изменены с помощью человеческоговмешательства (или каким-нибудь другим способом).
В принципе, клиентникогда не может быть уверен, что операция удаления была выполнена, дажеесли код статуса, переданный сервером, информирует об успешномвыполнении действия. Тем не менее, сервер не должен информировать обуспехе до тех пор, пока на момент ответа он не будет собираться стеретьданный ресурс или переместить его в некоторую недостижимую область.Метод LINK устанавливает взаимосвязи между существующим ресурсом,указанным в URI-Запроса, и другими существующими ресурсами. Отличиеметода LINK от остальных методов, допускающих установление ссылокмежду документами, заключается в том, что метод LINK не позволяетпередавать в запросе «Тело-Запроса», и в том, что в результате работы данногометода не создаются новые ресурсы.Метод UNLINK удаляет одну или более ссылочных взаимосвязей дляресурса, указанного в URI- Запроса.
Эти взаимосвязи могут быть установленыспомощьюметодаLINKиликакого-нибудьдругогометода,поддерживающего заголовок «Link». Удаление ссылки на ресурс не означает,что ресурс прекращает существование или становится недоступным длябудущих ссылок.Для обработки HTTP запросов был разработан фильтр, реализованный вфункции FilterHTTP.607 Портирование драйвера на 64-битную системуВ комплект Microsoft Windows DDK включена 64 битная среда сборки,которую можно использовать для написания исходного кода драйвера для 64битной версии Windows.
Эта среда содержит 64-битный компилятор, которыйможно использовать для определения проблем с указателями, неподходящихтипов переменных и других проблем, характерных при компиляции 64битного драйвера.При первом запуске компилятора, генерируется много предупреждений онесоответствии типа, например:«Warning C4311: 'type cast' : pointer truncation from 'unsigned char *' to'unsigned long»Эти предупреждения необходимо использовать в качестве руководства,чтобы сделать код надежнее. Желательно исключить все предупреждения.Например, следующий код может спровоцировать Warning C4311:Buffer = (PUCHAR) srbControl;(ULONG) + = srbControl-> HeaderLength;Чтобы исправить код, необходимо внести следующие изменения:Buffer = (PUCHAR) srbControl;(ULONG_PTR) + = srbControl-> HeaderLength;На рисунке 7.1 показано, что компилятор определяет следующие макросыдля идентификации платформы.Рисунок 7.1 – Макросы для идентификации платформыДрайвера режима ядра должны проверять размер любого буфера вводавывода, переделанного из приложения пользователя.
Если 32-разрядноеприложение передает буфер, содержащий типы данных с указателем точности61на 64-битный драйвер, и не происходит транкинг, драйвер будет ожидать, чтобуфер будет больше, чем есть на самом деле. Это связано с тем, что точностьуказателя составляет 32 бита в 32-битной системе, и 64 бита в 64-битнойсистеме.
Например, рассмотрим следующее определение структуры:typedef struct _DRIVER_DATA{HANDLE Event;UNICODE_STRING ObjectName;} DRIVER_DATA;В 32-битной Windows размер структуры DRIVER_DATA составляет 12байтов (рисунок 7.2).Рисунок 7.2 – Структура DRIVER_DATAВ 64-разрядной версии Windows размер структуры DRIVER_DATAсоставляет 24 байта (рисунок 7.3). (Требуется дополнительные 4 байта, чтобыможно было выровнять по 8-байтовой границе.)Рисунок 7.3 – Структура DRIVER_DATA в 64-битной системеЕсли 64-битный драйвер получает 12 байтов DRIVER_DATA, ожидая приэтом 24 байта, проверка размера не будет выполнена.
Чтобы предотвратитьэто, драйвер должен определить, была ли структура DRIVER_DATA62отправлена 32-битным приложением, если да, то выполнить его надлежащимобразом.Например, приведенная выше структура DRIVER_DATA может бытьопределена следующим образом:Typedef struct _DRIVER_DATA32{VOID * POINTER_32 Event;UNICODE_STRING32 ObjectName;} DRIVER_DATA32;Поскольку в ней содержатся только типы данных с фиксированнойточностью, эта новая структура имеет такой же размер в 32-разряднойWindows и 64-разрядной Windows (Рисунок 7.4).Рисунок 7.4 – Структура DRIVER_DATAСледующий пример показывает, как изменить 32-разрядный драйвер на64-битный, добавив поле 64Bit в управляющий код IOCTL.Пример драйвера для 32-битной системы:Header File#define REGISTER_FUNCTION 0 // Define the IOCTL function code#define IOCTL_REGISTER CTL_CODE(FILE_DEVICE_UNKNOWN, \63REGISTER_FUNCTION, METHOD_BUFFERED, FILE_ANY_ACCESS)typedef struct _IOCTL_PARAMETERS {PVOID Addr;SIZE_T Length;HANDLE Handle;} IOCTL_PARAMETERS, *PIOCTL_PARAMETERS;DeviceControl Dispatch RoutineNTSTATUSTestdrvDeviceControl(IN PDEVICE_OBJECT DeviceObject,IN PIRP Irp){PIO_STACK_LOCATION irpSp;NTSTATUS status;PIOCTL_PARAMETERS params;IOCTL_PARAMETERS LocalParam;PIOCTL_PARAMETERS_32 params32;////Get a pointer to the current parameters for this request.
The//information is contained in the current stack location.//irpSp = IoGetCurrentIrpStackLocation(Irp);//// Case on the device control code//switch (irpSp->Parameters.DeviceIoControl.IoControlCode) {case IOCTL_REGISTER:64params = (PIOCTL_PARAMETERS)(Irp->AssociatedIrp.SystemBuffer);if (irpSp->Parameters.DeviceIoControl.InputBufferLength <sizeof(IOCTL_PARAMETERS)) {status = STATUS_INVALID_PARAMETER;} else {RtlCopyMemory(&LocalParam, params,sizeof(IOCTL_PARAMETERS));/* Handle the ioctl here */status = STATUS_SUCCESS;}Irp->IoStatus.Information = 0;break;//// Unrecognized device control request//default:Irp->IoStatus.Information = 0;status = STATUS_INVALID_PARAMETER;break;}//// If status is pending, mark the IRP pending and start the// request in a cancelable state.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
