Co to jest prosta / minimalna Browserconfig.xml dla witryny internetowej

Nie chcę robić nic specjalnego lub trudnego w odniesieniu do systemu Windows 8 i przypinania, po prostu nie chcę widzieć komunikatów 404 Not Found, ponieważ IE szuka browserconfig.xmlprzewijania w moich plikach dziennika.

Czy istnieje trywialny browserconfig.xmlplik, który mogę umieścić w swoim katalogu głównym, który zadowoli IE i będzie dobrym zastępcą, jeśli w przyszłości powinienem zdecydować się na lepszą obsługę systemu Windows 8?

Dodałem kod meta do mojej głowy, ale nadal otrzymuję również żądania browsererconfig.xml.

Myślę więc, że najlepszym sposobem jest; według nich: http://msdn.microsoft.com/browserconfig.xml

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
    <msapplication>
    </msapplication>
</browserconfig>

Przykład znajduje się na stronie Microsoft w opisie schematu konfiguracji przeglądarki MSDN .

Umieszczasz browserconfig.xmlplik w folderze głównym serwera WWW.

Możesz również dołączyć:

<meta name="msapplication-config" content="none"/>

w kodzie HTML, aby IE nie szukał tego pliku, jeśli jest to opcja dla Ciebie, która również może działać.

Najłatwiejszym rozwiązaniem jest po prostu użycie oficjalnego kreatora plików Microsoft Browserconfig.xml: http://www.buildmypinnedsite.com

Możesz zbudować pełny plik xml i otrzymać wszystkie rozmiary swojego logo w zaledwie 3 krokach. Właśnie zrobiłem to dla mojej witryny i zajęło to tylko 2 minuty.

Wygeneruje pełny plik browsererconfig.xml i dostarczy wszystkie zatytułowane obrazy w jednym pliku zip.

Edycja 08.01.2015: Właśnie znalazłem inną opcję: http://realfavicongenerator.net/

Zaletą tej strony są generatory twojej browsererconfig.xml ORAZ wszystkie twoje ikony apple-touch- *, favicon itp. Zasadniczo jedna strona internetowa do generowania wszystkiego raz.

Dodanie metatagu może działać lub nie. Dodaliśmy ten tag, ale wciąż otrzymywaliśmy błędy 404 dotyczące browserconfig.xmlżądań. Na koniec zdecydowaliśmy się zrobić prosty xml.

Nasz browserconfig.xmlwygląda tak i po prostu mówi, gdzie znajdują się 4 obrazy.

<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
    <msapplication>
        <tile>
        <square70x70logo src="/mstile-70x70.png"/>
        <square150x150logo src="/mstile-150x150.png"/>
        <wide310x150logo src="/mstile-310x150.png"/>
        <square310x310logo src="/mstile-310x310.png"/>
        <TileColor>#8bc53f</TileColor>
        <TileImage src="/mstile-150x150.png" />
        </tile>
    </msapplication>
</browserconfig>

I umieść to w swoim html:

<meta name="msapplication-config" content="/browserconfig.xml" />

A teraz jest w porządku

Równie dobrze możesz po prostu dodać go do kodu HTML i ustawić konfigurację na „none” w następujący sposób:

<meta name="msapplication-TileColor" content=" #009900" />
<meta name="msapplication-square70x70logo" content="images/smalltile.png" />
<meta name="msapplication-square150x150logo" content="images/mediumtile.png" />
<meta name="msapplication-wide310x150logo" content="images/widetile.png" />
<meta name="msapplication-square310x310logo" content="images/largetile.png" />
<meta name="msapplication-config" content="none"/>

Źródła:

http://samples.msdn.microsoft.com/iedevcenter/PinnedSites/scenario1.html https://msdn.microsoft.com/library/dn320426

Istnieje trzeci sposób zapobiegania browserconfig.xmlzapełnianiu plików dziennika błędami 404. Możesz zwrócić wartość null (444) z serwera i wyłączyć rejestrowanie tylko dla tej lokalizacji. Jest to istotne, ponieważ favicon.ico robi to samo, ignorując znaczniki meta head i wywołującą je przeglądarkę (również generuje 404). Problem jest większy niż tylko ten jeden niechciany plik.

Jeśli chodzi o Twoje konkretne pytanie dotyczące zapobiegania błędom 404 w dziennikach na browser.xml - w przypadku NGINX możesz utworzyć nowy plik w, /etc/nginx/snippets/a następnie #includeten plik w swoim /etc/nginx/sites-available/example.orgpliku wewnątrz bloku serwera.

Przykład: /etc/nginx/snippets/block-known-errors.confma następującą zawartość:

location ~* /(favicon.ico|browserconfig.xml)$
   { access_log off; log_not_found off; return 444; }

Następnie w swojej konfiguracji dodałbyś /etc/nginx/sites-available/example.org:

include /etc/nginx/snippets/block-known-errors.conf;

Uwaga w specyfikacji lokalizacji w NGINX używa wyrażenia regularnego i nie uwzględnia wielkości liter . A ponieważ jest locationto, musi znajdować się w serverspecyfikacji.

W praktyce faktycznie zagnieżdżamy nasze /etc/nginx/snippets/dołączenia w folderze i mamy jedno globalne dołączenie i inne dołączenia dla określonych witryn, w zależności od wymagań bezpieczeństwa / technologii. Dzięki temu nasze punkty końcowe niemal natychmiast rozwiązują globalny problem, dodając jeden plik lub edytując istniejący plik w celu zarządzania naszymi dziennikami.

Jest tylko tyle okrucieństwa, które możesz przejrzeć dzięki OSSEC i stosowi ELK.

Jestem pewien, że mod_rewrite w Apache również mógłby to zrobić.