MFC: тип MIME «текст/css» не распознан IInternetProtocolSink

Question

У меня есть управление веб-браузером с подключаемым протоколом на основе интерфейса IInternetProtocol. При загрузке HTML-сайтов все в порядке. Но при загрузке внешней таблицы стилей CSS тип MIME «text/css», сообщаемый в BINDSTATUS_MIMETYPEAVAILABLE и BINDSTATUS_VERIFIEDMIMETYPEAVAILABLE игнорируется.

• если установить FEATURE_BROWSER_EMULATION в реестре 8888 (IE8), внешний CSS правильно оказанной (в папке «Реестр»)
• если установить FEATURE_BROWSER_EMULATION в реестре 11001 (IE11) или что-нибудь, кроме IE 8, внешний CSS игнорируется (в папке «Реестр»)
• Если HTML-сайт содержит метатег IE = край, внешний CSS игнорируется, поскольку это заставляет элемент управления веб-браузером работать в режиме IE11
• если отключить подключаемый протокол, внешний CSS будет отображаться независимо от значения, установленного для FEATURE_BROWSER_EMULATION
• Если я отключу подключаемый протокол и доставляю таблицу стилей CSS с несоответствием неправильного типа MIME с демонстрационного сервера (в папке «Сервер»), поведение подключаемого протокола может быть воспроизведено как в IE, так и в элементе управления веб-браузером
• отчетности заголовки к интерфейсу IHttpNegotiate не имеет никакого эффекта
• любые другие элементы управления набором функций, с CoInternetSetFeatureEnabled не имеют никакого эффекта

Мои выводы до сих пор:

• IE8 и управления веб-браузера в режиме IE8 полностью игнорирует типы MIME и находит его с помощью MIME нюхает
• IE9, а потом потерпеть неудачу, если неправильный тип MIME поставляется
• веб-браузера в управлении режиме IE9 + игнорирует тип MIME "текст/CSS", как и любые другие типы MIME, установленные для CSS стилей

Мои вопросы:

• ли кто-нибудь столкнуться с подобной проблемой с подключаемыми протоколами? Если да, как вы это решили?
• Как правильно загружать и отправлять таблицы стилей CSS на IInternetProtocolSink?

Здесь Вы можете скачать образец проект, который демонстрирует поведение:
https://github.com/elsamuko/SimpleBrowser

Здесь представлены скриншоты различных поведений:
http://imgur.com/a/w3oCv

Ссылка:
http://msdn.microsoft.com/en-us/library/aa752046%28v=vs.85%29.aspx
http://www.codeproject.com/Articles/157329/Http-Monitor-for-Webbrowser-Control
http://www.codeproject.com/Articles/12865/An-Asynchronous-Pluggable-Protocol-Handler-for-dat

Answer 1

У меня была точно такая же проблема, работая над проектом C# в тот же день, когда этот вопрос был отправлен.

Проблема была решена путем сообщения BINDSTATUS_CACHEFILENAMEAVAILABLE к раковине. Конечно, это будет работать, только если у вас есть локальная копия файла. Код приведен в C#, но он дает общее представление о том, как это работает.

Он будет работать даже без BINDSTATUS_MIMETYPEAVAILABLE, но это может вызвать другие проблемы. Поэтому это не рекомендуется.

Надеюсь, что это помогает ...

sink.ReportProgress(UrlMon.BINDSTATUS.BINDSTATUS_MIMETYPEAVAILABLE, mimetype); 
sink.ReportProgress(UrlMon.BINDSTATUS.BINDSTATUS_CACHEFILENAMEAVAILABLE, localfilename); 
sink.ReportData(UrlMon.BSCF.BSCF_DATAFULLYAVAILABLE, 0, 0); 
sink.ReportResult(0, 200, null); 

Добавка:

Вы не могли бы иметь никакого другого выбора, кроме как писать на диск при осуществлении асинхр. подключаемый протокол. Вместе с запросом приходит много дополнительных флагов. Один из этих флагов - флаги BINDF.BINDF_NEEDFILE (первый параметр метода IInternetBindInfo :: GetBindInfo). Эти флаги заставляют вас возвращать файл.

Возможно, это может быть причиной первоначальной проблемы. По какой-то причине (только для Microsoft) Internet Explorer заставляет файл css существовать на диске, добавив BINDF_NEEDFILE. Найдите в Интернете BINDF_NEEDFILE, и вы получите много объяснений.