Server statiske ressurser med våren

1. Oversikt

Denne artikkelen utforsker hvordan betjene statiske ressurser med våren - bruker både XML- og Java-konfigurasjon.

2. Bruke vårstøvel

Spring Boot kommer med en forhåndskonfigurert implementering av ResourceHttpRequestHandler for å lette servering av statiske ressurser.

Som standard serverer denne behandleren statisk innhold fra hvilken som helst av / statisk, / offentlig, / ressurser, og / META-INF / ressurser kataloger som er på klassestien. Siden src / main / resources er vanligvis på klassestien som standard, kan vi plassere noen av disse katalogene der.

For eksempel hvis vi setter en om.html filen inne i / statisk -katalogen i klassestien vår, så kan vi få tilgang til filen via //localhost:8080/about.html. På samme måte kan vi oppnå det samme resultatet ved å legge til filen i andre nevnte kataloger.

2.1. Egendefinerte banemønstre

Som standard serverer Spring Boot alt statisk innhold under rotdelen av forespørselen, det vil si /**. Selv om det ser ut til å være en god standardkonfigurasjon, vi kan endre det via spring.mvc.static-path-mønster konfigurasjonsegenskap.

For eksempel hvis vi vil ha tilgang til den samme filen via //localhost:8080/content/about.html, vi kan si det i vår application.properties:

spring.mvc.static-path-pattern = / content / **

I WebFlux-miljøer bør vi bruke spring.webflux.static-path-pattern eiendom.

2.2. Egendefinerte kataloger

I likhet med banemønstre, det er også mulig å endre standardressursstedene via spring.resources.static-locations konfigurasjonsegenskap. Denne egenskapen kan akseptere flere komma-atskilte ressurslokasjoner:

spring.resources.static-locations = classpath: / files /, classpath: / static-files

Her serverer vi statisk innhold fra / filer og / statiske filer kataloger inne på klassestien. Videre Spring Boot kan servere statiske filer utenfor klassestien:

spring.resources.static-locations = file: / opt / files 

Her bruker vi filressurssignaturen, fil:/, for å servere filer fra vår lokale disk.

3. XML-konfigurasjon

Hvis du trenger å gå på gammeldags måte med XML-basert konfigurasjon, kan du gjøre god bruk av mvc: ressurser element for å peke på plasseringen av ressurser med et bestemt offentlig URL-mønster.

For eksempel - følgende linje vil tjene alle forespørsler om ressurser som kommer inn med et offentlig URL-mønster som “/ ressurser / **”Ved å søke i“ /ressurser /”-Katalogen under rotmappen i applikasjonen vår.

Nå kan vi få tilgang til en CSS-fil som på følgende HTML-side:

Eksempel 3.1.

 Hjem 

4. Den ResourceHttpRequestHandler

Vår 3.1. introduserte ResourceHandlerRegistry å konfigurere ResourceHttpRequestHandlers for å betjene statiske ressurser fra klassestien, WAR eller filsystemet. Vi kan konfigurere ResourceHandlerRegistry programmatisk innenfor vår nettkontekstkonfigurasjonsklasse.

4.1. Betjener en ressurs lagret i krigen

For å illustrere dette, bruker vi samme URL som før for å peke på myCss.css, men nå vil den faktiske filen ligge i WAR webapp / ressurser mappe, som er der statiske ressurser skal plasseres når du distribuerer Spring 3.1+ applikasjoner:

Eksempel 4.1.1.

@Configuration @EnableWebMvc public class MvcConfig implementerer WebMvcConfigurer {@Override public void addResourceHandlers (ResourceHandlerRegistry registry) {registry .addResourceHandler ("/ resources / **") .addResourceLocations ("/ resources /"); }}

La oss analysere eksemplet. Først konfigurerer vi den URI-banen som vender utover, ved å legge til definere en ressursbehandler. Deretter kartlegger vi den utvendige URI-banen internt til den fysiske banen der ressursene faktisk ligger.

Vi kan selvfølgelig definere flere ressursbehandlere ved hjelp av denne enkle, men fleksible API-en.

Nå - følgende linje i en html siden vil gi oss myCss.css ressurs inne i webapp / ressurser katalog:

4.2. Serverer en ressurs som er lagret i filsystemet

La oss si at vi vil tjene en ressurs som er lagret i / opt / filer / katalog når det kommer inn en forespørsel om den offentlige URL-en som samsvarer med mønsteret: / filer / **. Vi konfigurerer bare URL-mønsteret og kartlegger det til den aktuelle plasseringen på disken:

Eksempel 4.2.1.

@Override public void addResourceHandlers (ResourceHandlerRegistry registry) {registry .addResourceHandler ("/ files / **") .addResourceLocations ("file: / opt / files /"); }

* (For Windows-brukere: Argumentet ble sendt til addResourceLocations for dette eksemplet ville være “fil: /// C: / opt / filer /“).

Når vi har konfigurert ressursplasseringen, kan vi bruke det tilordnede URL-mønsteret i vårt hjem.html til laste inn et bilde som er lagret i filsystemet som følger:

Eksempel 4.2.2.

 Hjem 

4.3. Konfigurere flere steder for en ressurs

Hva om vi vil se etter en ressurs på mer enn ett sted?

Vi kan inkludere flere steder med addResourceLocations metode. Listen over steder vil bli søkt i rekkefølge til ressursen er funnet. La oss se på eksempel 3.3.1.

Eksempel 4.3.1

@Override public void addResourceHandlers (ResourceHandlerRegistry registry) {registry .addResourceHandler ("/ resources / **") .addResourceLocations ("/ resources /", "classpath: / other-resources /"); }

Følgende curl-forespørsel vil vise Hei.html siden som er lagret i enten applikasjonens webappp / ressurser eller andre ressurser mappen i klassestien.

krøll -i //localhost:8080/handling-spring-static-resources/resources/Hello.html

5. Det nye ResourceResolvers

Vår 4.1. gir - med det nye Ressurser Løsere - forskjellige typer ressursoppløsere som kan brukes til å optimalisere nettleserens ytelse når du laster inn statiske ressurser. Disse resolverne kan lenkes og caches i nettleseren for å optimalisere håndtering av forespørsler.

5.1. De PathResourceResolver

Dette er den enkleste løseren, og formålet er å finne en ressurs gitt et offentlig URL-mønster. Faktisk, hvis ikke ResourceResolver er lagt til ResourceChainRegistration, dette er standardoppløseren.

La oss se et eksempel:

@Override public void addResourceHandlers (ResourceHandlerRegistry registry) {registry .addResourceHandler ("/ resources / **") .addResourceLocations ("/ resources /", "/ other-resources /") .setCachePeriod (3600) .resourceChain (true). addResolver (ny PathResourceResolver ()); }

Ting å legge merke til:

  • Vi registrerer PathResourceResolver i ressurskjeden som eneste ResourceResolver i det. Se avsnitt 4.3. for å sjekke hvordan du kan kjede mer enn en ResourceResolver.
  • Ressursene som serveres lagres i nettleseren i 3600 sekunder.
  • Kjeden er endelig konfigurert med metoden resourceChain (true).

Nå - HTML-koden som, i forbindelse med PathResourceResolver, lokaliserer foo.js skript i enten webapp / ressurser av webapp / andre ressurser mappe:

5.2. De EncodedResourceResolver

Denne løseren prøver å finne en kodet ressurs basert på Godta-koding forespørsel om topptekstverdi.

Vi kan for eksempel trenge å optimalisere båndbredden ved å betjene den komprimerte versjonen av en statisk ressurs ved hjelp av gzip innholdskoding.

For å konfigurere en EncodedResourceResolver, vi trenger bare å konfigurere det i ResourceChain akkurat som vi konfigurerte PathResourceResolver, som i følgende kodelinje:

registry .addResourceHandler ("/ other-files / **") .addResourceLocations ("file: / Users / Me /") .setCachePeriod (3600) .resourceChain (true) .addResolver (new EncodedResourceResolver ());

Som standard er EncodedResourceResolver er konfigurert til å støtte br og gzip kodinger.

Så, følgende krølle forespørsel vil få den glidelåste versjonen av Hjem.html filen som ligger i filsystemet i Brukere / meg / katalog:

krøll -H "Godta-koding: gzip" //localhost:8080/handling-spring-static-resources/other-files/Hello.html

Legg merke til hvordan vi setter overskriften "Godta-koding”Verdi til gzip - dette er viktig fordi denne bestemte løseren bare vil sparke inn hvis gzip-innholdet er gyldig for svaret.

Til slutt, vær oppmerksom på at den komprimerte versjonen, som før, forblir tilgjengelig i tidsperioden den er hurtigbufret i nettleseren - som i dette tilfellet er 3600 sekunder.

5.3. Kjetting ResourceResolvers

For å optimalisere ressurssøk, ResourceResolvers kan delegere håndtering av ressurser til andre resolvere. Den eneste løseren som ikke kan delegere til kjeden er PathResourceResolver som skal legges til på slutten av kjeden.

Faktisk, hvis resourceChain er ikke satt til ekte, så som standard bare a PathResourceResolver vil bli brukt til å betjene ressurser. I eksempel 4.3.1. vi lenker PathResourceResolver for å løse ressursen hvis GzipResourceResolver mislykkes.

Eksempel 5.3.1.

@Override public void addResourceHandlers (ResourceHandlerRegistry registry) {registry .addResourceHandler ("/ js / **") .addResourceLocations ("/ js /") .setCachePeriod (3600) .resourceChain (true) .addResolver (new GzipResourceResolver () addResolver (ny PathResourceResolver ()); }

Nå som vi har lagt til / js / ** mønster til ResourceHandler, la oss inkludere foo.js ressurs lokalisert i webapp / js / katalog i vår hjem.html side som i eksempel 4.3.2.

Eksempel 5.3.2.

 Hjem 

Det er verdt å nevne at, fra og med Spring Framework 5.1, har GzipResourceResolver har blitt avskrevet til fordel for EncodedResourceResolver. Derfor bør vi unngå å bruke den i fremtiden.

6. Ekstra sikkerhetskonfigurasjon

Hvis du bruker Spring Security - er det viktig å gi tilgang til statiske ressurser. Vi må legge til de tilsvarende tillatelsene for å få tilgang til ressurs-URL: en:

7. Konklusjon

I denne artikkelen har vi illustrert forskjellige måter en Spring-applikasjon kan tjene statiske ressurser på.

Den XML-baserte ressurskonfigurasjonen er et "arv" -alternativ som vi kan bruke hvis vi ikke kan gå ned Java-konfigurasjonsruten ennå.

Vår 3.1. kom ut med et grunnleggende programmatisk alternativ gjennom sitt ResourceHandlerRegistry gjenstand.

Og til slutt - det nye ut av esken ResourceResolvers og ResourceChainRegistration gjenstand levert med våren 4.1. tilby funksjoner for optimalisering av ressurslasting som hurtigbuffering og ressurshåndteringskæding for å forbedre effektiviteten i servering av statiske ressurser.

Som alltid er hele eksemplet tilgjengelig på Github. I tillegg er Spring Boot-relaterte kildekoder også tilgjengelig i dette prosjektet.


$config[zx-auto] not found$config[zx-overlay] not found