Abbiamo un'applicazione Java in esecuzione su Tomcat come AppServer & Apache come server Web.
Attualmente, stiamo gestendo richieste malformate nell'applicazione stessa. Tuttavia, mi chiedevo se fosse meglio gestirlo in Apache scrivendo qualche mod o usando qualche mod esistente.
Qual è la pratica standard per questo?
La pratica standard è non di tentare di cambiare ciò che altrimenti sarebbe considerato una richiesta valida attraverso il modding.
L'intero scopo dell'utilizzo di un contenitore web è che può ospitare l'applicazione in modo uniforme senza richiedere realmente delle dipendenze tra l'applicazione e l'hosting effettivo. In caso contrario, devi necessariamente utilizzare Tomcat come piattaforma. Naturalmente non c'è nulla che ti impedisca di farlo, sebbene non sia l'ideale.
La pratica comune è controllare se stessi i parametri passati nella richiesta e, nel caso in cui non sia una richiesta valida per qualsiasi motivo, viene generata un'eccezione e la si cattura a livello Servlet e si risponde con un codice http appropriato. Oltre a questo, dichiari una pagina di errore web.xml per errori generici o per codici http specifici per una risposta relativamente pulita per una chiamata non valida.
Puoi raccogliere le richieste in diversi punti prima che raggiungano l'endpoint (e la tua applicazione). Se vuoi una singola classe che gestirà tutte le richieste in arrivo, allora definisci un filtro e gestirlo lì, se stai cercando qualcosa di più globale, diciamo per tutte le tue intere applicazioni Tomcat, prova a scrivere un Valve .
Se ho capito bene, hai davanti un Apache HTTPD, che trasmette alcune richieste a un Tomcat. Destra? Non è molto chiaro dalla descrizione.
Le "richieste completamente malformate" saranno già gestite da link e "la richiesta ha un percorso / argomento errato" sarà gestita dall'app di Tomcat. Fin qui, tutto bene.
... la domanda è: perché vorresti cambiarlo ?! In tal modo, avresti due posizioni da mantenere e da mantenere sincronizzate. La mod di HTTPD / config / qualunque sia e la webapp di Tomcat stessa. Questo non mi sembra un buon affare.
Questo dipende interamente dal livello in cui stai cercando di fare qualcosa.
Se si desidera indirizzare il traffico HTTP al traffico HTTPS, ciò dovrebbe essere fatto a livello del server Web (IIS, Apache, Nginx). L'ispezione delle intestazioni può essere eseguita anche a questo livello, come il blocco di specifici programmi utente dall'accesso alla tua applicazione o la garanzia che uno dei tuoi header personalizzati sia presente.
Mi sconsiglia di ispezionare la maggior parte degli altri casi a livello di server Web, per esempio dovresti convalidare il contenuto dei parametri URL a livello di applicazione; come verificare che un valore sia all'interno di un intervallo specificato. Ciò al fine di evitare lo splicing nella logica non necessaria nel server Web ma anche di creare una migliore gestione dei messaggi di errore. Potresti anche volere che la tua applicazione esegua determinate cose in caso di errore, un classico sta semplicemente registrando l'errore in questione.
L'unico consiglio che posso dare è quello di verificare le cose al livello appropriato, ma ci sono un bel po 'troppi casi e combinazioni per dare una semplice linea guida per tutte le richieste che potrebbero essere malformate.
My question is [...] about [...] whether it makes sense to do it anywhere other than in the application? - user93353
Mi fiderò di te per non portarmi letteralmente. Dai un'occhiata a questo:
Ora non stiamo parlando dei tuoi pacchetti qui. Stiamo parlando di richieste malformate. Ma la somiglianza è che malformato è qualcosa di definito in modo diverso a ogni livello del tuo stack.
Se è malformato in un modo in cui nessuna applicazione potrebbe mai utilizzarlo, sono sorpreso che Apache non lo stia già gestendo. Se non lo sono forse dovresti creare una correzione e offrirla a tutti.
Se qualcosa è malformato in un modo che è particolare per la tua applicazione, non avrebbe molto senso gestirlo a livello di server (Apache). Se stai disperdendo la manipolazione nella tua applicazione, hai un problema diverso. Dovresti creare un posto unico per gestirlo e dirigere il lavoro lì. Non c'è motivo per cui un singolo luogo non possa essere nella tua app.
Se è malformato in un modo in cui altre app potrebbero essere corretti e sono sicuri che OGNI APP che MAI ESEGUI sotto questo server ha bisogno di questa correzione esatta con niente di particolare per loro allora forse hai un motivo per fare una strana usanza correzione ad Apache. Se si può predire il futuro così bene perché perdere tempo a scrivere software? Vai a giocare nel mercato azionario.
Se pensi che potresti avere alcune app che hanno bisogno di questa correzione e altre che non lo fanno, allora connetti quelle che ne hanno bisogno attraverso un proxy. Se questo è troppo lontano per te, allora vivi con il codice duplicato.
Qualcosa che anche io e il mio team siamo riusciti a risolvere, senza nemmeno renderci conto che si trattava di un problema.
Abbiamo avuto un server proxy inverso che ha filtrato le richieste e reindirizzato al rispettivo vms che ha eseguito alcuni server in cui è stata distribuita la nostra app. Se la richiesta è arrivata sul server che è l'ultimo della catena che elaborerà la richiesta , sapevamo che qualunque sia stato il percorso fornito dalla richiesta lo aveva inserito nel suo URL.
Un url avrebbe logicamente due parti path_to_the_resource e data, secondo me il percorso della risorsa dovrebbe essere controllato / filtrato dal server / proxy dove la richiesta atterra ovviamente e la parte dati deve essere gestita dall'applicazione che sa quale tipo di dati richiede e quindi può filtrare le richieste desiderate da quelle indesiderate .
Questo approccio distribuirebbe anche il carico tra il filtro del server e l'app, questo approccio sarebbe anche migliore nella maggior parte dei casi in quanto si tratta di contesti separati e in base al contesto l'entità filtrante può avere più regole per filtrare la richiesta ben formata dal malformato.