Abuso di 302 Reindirizzamento temporaneo

0

Quindi sono un programmatore junior e ho appena iniziato a lavorare con .net webforms poco più di sei mesi fa. Ho studiato SEO e sto cercando di ottimizzare le migliori pratiche con uno sviluppatore senior. Mi sento come 302s o in. Netto webforms response.redirect è abusato molto. Potrebbe essere solo il flusso logico di elaborazione del nostro team. Tuttavia, con il modo in cui le webform gestiscono lo stato come con Server.Transfer, controlli, viewstate e il ciclo di vita della pagina, mi sembra che questo non sia vero. Mi sento come se fossimo costretti in qualche modo a semplificare la programmazione per usare Response.Redirect. Stiamo cercando il modo migliore per gestire Response.Redirect e sentirci come se potessimo abusarne. Forse questo è importante solo per le pagine pubbliche considerando che i motori di ricerca divideranno il posizionamento delle pagine tra due pagine se viene utilizzato un Response.Redirect. Nel complesso vogliamo avere le migliori pratiche e stabilire i migliori principi per il nostro team.

Scenario 1: Usa evento collegato a un controllo casella di controllo, quando l'utente fa clic su un postback viene eseguito. In caso di codice interno, creiamo la querystring in base alla selezione della casella di controllo e facciamo un Response.Redirect alla stessa pagina. Alla prima pagina, controlla le querystring e mostra i risultati.

  1. Mi sembra che non sia un reindirizzamento temporaneo. Il contenuto potrebbe cambiare ma nel complesso la pagina di quell'URL sarà sempre lì. Non è nemmeno una nuova pagina. Quella casella di controllo andrà sempre a quell'URL. Non dovrebbe essere solo una richiesta di ottenere. Per me invece di fare solo un Response.Redirect sarebbe meglio cambiare semplicemente i risultati in base alla selezione. Creazione di una singola funzione riutilizzabile per questo flusso logico.

Scenario 2. Abbiamo una pagina di amministrazione con una griglia che mostra righe di informazioni relative a particolari entità. Ogni riga ha un pulsante corrispondente a una pagina di dettagli per la modifica dell'entità. Quando l'utente fa clic su un pulsante all'interno di una riga sulla griglia, viene eseguito un postback, un token crittografato viene creato in base all'elemento selezionato. Response.Redirect viene eseguito per passare alla pagina dei dettagli con il token passato come parametro querystring.

  1. Non mi sembra un reindirizzamento temporaneo. Ogni volta che fai clic su quel pulsante, verrà visualizzata la pagina dei dettagli di tali elementi. L'unica soluzione alternativa che potrei ottenere è quella di creare l'URL di ogni riga con il token, al primo caricamento della pagina. Invece di fare un post, reindirizzare, ottenere, sarà solo un get.

Questo è solo due scenari in cui usiamo Response.Redirect. Probabilmente potremmo mostrare da 10 a 15 casi di uso comune che usiamo per Response.Redirect, e tutti sembrano abusati a mio parere. Questo è solo il modo migliore di fare le cose nello stack webforms? In che modo un'applicazione MVC gestirà gli scenari 1 e 2, si preferirebbe un reindirizzamento? Mi sento come se ognuno dei nostri casi di utilizzo debba essere esaminato e determinare il miglior approccio per evitare Response.Redirect. Lo sviluppatore principale del progetto è alla ricerca di un'unica soluzione per gestire tutti gli scenari di utilizzo per semplicità, meno ore di programmazione e senza importanti cambiamenti architettonici. Non sono stato in grado di sviluppare una soluzione che soddisfi le sue esigenze.

Nota: aggiunto il tag MVC perché forse uno degli sviluppatori senior che ha lavorato con entrambi gli stack (webform e mvc) può rispondere meglio alle domande / ai dubbi.

    
posta Grim 23.03.2018 - 13:55
fonte

2 risposte

2

Post, reindirizza, ottieni è un modello standard utilizzato per evitare invii di moduli duplicati. Non mi è chiaro perché consideri questo abuso. Il reindirizzamento è temporaneo in quanto un reindirizzamento permanente può essere memorizzato nella cache dagli indicizzatori e stai dicendo loro che l'URL è stato reindirizzato dal suo allontanamento e non considerarlo nuovamente in futuro. Questo non suona come quello che vuoi in entrambi gli scenari.

link
link

    
risposta data 27.05.2018 - 21:49
fonte
0

Seguo la tua opinione; in entrambi gli scenari un reindirizzamento non è giustificato.

Questo è principalmente negativo per le prestazioni; ciascuna di queste azioni colpisce il server web due volte e l'intero ciclo di vita della pagina Web coinvolta viene eseguito due volte. Questo vale anche per le dipendenze secondarie come l'autenticazione, l'autorizzazione, ecc.

Sono d'accordo sul fatto che una squadra deve applicare un qualche tipo di modo comune di fare le cose, ma questo deve essere basato sulle migliori pratiche generali e non su un unico approccio per tutti.

    
risposta data 27.05.2018 - 00:13
fonte

Leggi altre domande sui tag