perché i collegamenti in Excel/Word sembrano causare il mascheramento del mio browser non IE come MSIE 7.0?

Question

Quando si fa clic su un collegamento in Excel/Word e tale collegamento porta a un sito che ispeziona l'agente utente per determinare se è supportato o meno, il sito potrebbe erroneamente presumere che si stia utilizzando MSIE 7.0 quando in realtà si sta utilizzando qualcos'altro, diciamo Chrome.

Durante l'ispezione dell'Utente utente inviato insieme alla richiesta, indica che la richiesta proviene da MSIE 7.0 - quando dal punto dell'utente, MSIE 7.0 non viene utilizzato in modo chiaro.

Cosa sta succedendo qui? Come posso smettere di mostrare agli utenti il ​​messaggio sbagliato?

Answer 1

Il problema sembra essere che Excel/Word tenta di precaricare il collegamento quando viene fatto clic. Se viene caricato correttamente, aprirà il browser predefinito con il link specificato. Tuttavia, seguirà anche i reindirizzamenti 302 quando precarichi il collegamento. Se il sito non supporta MSIE7 (che sta diventando piuttosto comune), molto probabilmente ti reindirizzerà a una pagina di informazioni/errori. La routine di pre-caricamento aprirà quindi questa pagina nel tuo browser piuttosto che nel link originale, dando come risultato un messaggio che probabilmente spiega perché MSIE 7.0 non è supportato, ma confondendo l'utente che può vedere chiaramente che la pagina è stata caricata utilizzando Chrome.

C'è un modo consigliato di codificare in tutto questo?

Se è già stata data una risposta, per favore fatemelo sapere. Spero che aiuti qualcuno.

Answer 2

La soluzione più semplice consiste nel posizionare un controllo del browser sulla "Pagina non supportata di IE 7". Il programma Office, dopo aver seguito i reindirizzamenti (in base alla stringa di agente utente errata che invia) caricherà la pagina di errore, riceverà una risposta HTTP 200 e POI lancerà il collegamento al browser predefinito. Il browser richiede quindi la pagina stessa, con la sua stringa di user agent appropriata.

1. richieste di processo Office "example.com/example.html" con User Agent "compatible; MSIE 7.0"
2. rendimenti server HTTP reindirizzamento 302 per example.com/notsupported.html~~V~~singular~~3rd
3. richieste di processo Office " example.com/notsupported.html "con User Agent "compatible; MSIE 7.0"
4. Server restituisce HTTP 200 Trovato + example.com/notsupported.html
5. processo Ufficio passa collegamento al browser predefinito
6. richieste del browser di default" example.co m/notsupported.html" con User Agent "qualunque sia l'agente del browser è"
7. Server restituisce HTTP 200 Trovato + example.com/notsupported.html

Quindi una volta che il browser richiede la pagina è possibile utilizzare l'utente agente stringa per vedere se davvero vuoi inviare una pagina "non supportata" o reindirizzare la richiesta al contenuto reale.

Ciò tuttavia solleva il problema di trovare l'URL originale che è stato reindirizzato. Ci sono problemi con le sessioni di condivisione tra il processo di Office che originariamente richiede la pagina e il browser che alla fine viene passato l'URL del punto finale. Una soluzione alternativa sarebbe includere l'URL della richiesta originale come parametro della stringa di query nella risposta di reindirizzamento alla pagina "Non supportato".