SharePoint 2007 и VML

Някъде наскоро нашият SharePoint 2007, хостван на сървър на Windows 2003, започна да дава на нашите потребители грешки като „Internet Explorer не може да покаже уеб страницата“ за htm или html документи, създадени в Word, и не позволява на потребителите да редактират документите, тъй като те винаги се отварят като „ Само за четене".

Открих, че проблемът възниква само когато следното е част от html:

<html xmlns:v="urn:schemas-microsoft-com:vml"
 xmlns:o="urn:schemas-microsoft-com:office:office"
 xmlns:w="urn:schemas-microsoft-com:office:word"
 xmlns:m="http://schemas.microsoft.com/office/2004/12/omml"
 xmlns="http://www.w3.org/TR/REC-html40">

Ако или запазя документа като „уеб страница, филтрирана“, или ръчно изтрия пространствата от имена, документите ще се показват добре, те също ще се отварят за редактиране, вместо да останат в режим само за четене.

Трябва да прегледаме ръчно много документи и да ги редактираме всички в този филтриран режим, бих искал да накарам SharePoint да разпознава файловете, както използва.

Това е скорошна промяна, тъй като потребителите използват, за да нямат проблеми с тези документи в нашия SharePoint. Някой знае ли за някакви настройки или регистрационни файлове, които мога да прегледам, за да определя какво се е променило?

РЕДАКТИРАНЕ: Открих, че всяка страница, включително .aspx страници, ако включват VML: xmlns:v="urn:schemas-microsoft-com:vml" Няма да успее да се зареди.


person Bazooka_Duke    schedule 10.01.2014    source източник


Отговори (1)


След много повече отстраняване на неизправности, след това малко дискусия с мрежовия администратор, открихме, че актуализация на нашата система за предотвратяване на проникване причинява отпадане на VML документи.

Проблемът се проявява с грешки като „Страницата не може да се покаже“ за определени .aspx и .htm файлове. Освен това ще принуди всеки .htm файл да премине в режим само за четене, когато редактирате документа в Word (основният начин, по който нашите потребители редактират документите). Опитът за отваряне на файла с друг софтуер обикновено просто би умрял с различни грешки в зависимост от софтуера.

Fiddler показваше, че това е грешка на сървъра 500, но сървърът нямаше регистрационни файлове, показващи грешки. Накрая пуснах wireshark както на машината, така и на сървъра. Това беше трикът, който ме доведе до отговора. Открих, че клиентската машина получава пакети за нулиране на TCP точно след изпращането на частта от документа с VML, в която се казва, че сървърът нулира връзката. Сървърът обаче получаваше пакети за нулиране на TCP, в които се казваше, че клиентът нулира връзката. Вглеждайки се по-внимателно в пакетите, открих, че MAC адресът, който изпращаше пакета, всъщност беше нашата система за предотвратяване на проникване. Това доведе до дискусия с мрежовия администратор, който потвърди, че нашият IPS има известно филтриране за VML документи.

person Bazooka_Duke    schedule 10.02.2014
comment
Може би бихте могли да добавите някои подробности? Така че други хора, които се озовават тук чрез търсачките, биха могли да се възползват, изглежда, че са ви отнели 4 години, за да разрешите това (?!), може би това ще спести на някой друг много главоболие. - person Martin Tournoij; 11.02.2014
comment
Не минаха 4 години, бяха само няколко месеца. Надяваме се, че описанието по-горе ще изясни какво открихме. - person Bazooka_Duke; 11.02.2014
comment
Ack, мислех, че „10 януари“ означава януари 2010 г., а не 10 януари. - person Martin Tournoij; 11.02.2014