இருக்கும் NGINX HTTP அனுப்பும் பாதையில் குறியாக்கப்பட்ட பாதைகளைப் பாதுகாக்கவும்

அனுப்பும் ஒப்பந்தத்திற்கு அசல் பாதையும் வினவலும் தேவைப்படும்போது request_uri பயன்படுத்தி, இருக்கும் இலக்கு சரிபார்ப்பைத் தக்கவைக்கவும்.

$uri இலிருந்து கட்டப்பட்ட பாதை வாடிக்கையாளர் வழங்கியதிலிருந்து வேறுபட்ட பாதையை அனுப்பலாம். http://service.example/files/a%2Fb?view=raw க்கு, தப்பிக்கப்பட்ட சாய்வுக்கோடு அந்த அசல் எழுத்துப்பிழையின் பகுதியாகும்.

மாறிபிரதிநிதித்துவம்
$uriதற்போதைய இயல்பாக்கப்பட்ட URI, இது உள் செயலாக்கத்தின் போது மாறலாம்
$request_uriஅசல் கோரிக்கை URI, அதன் வினவல் வாதங்கள் உட்பட

இலக்கு அதிகாரத்தை ஏற்கனவே தேர்ந்தெடுத்து சரிபார்க்கும் இருக்கும் HTTP அனுப்பும் ப்ராக்ஸி அமைப்பில், அசல் பாதையும் வினவலும் இவ்வாறு பாதுகாக்கப்படலாம்:

proxy_pass http://$http_host$request_uri;

$http_host இந்த அமைப்பில் தேர்ந்தெடுக்கப்பட்ட Host தலைப்பு அதிகாரத்தை வழங்குகிறது. கேட்பவரின் வாடிக்கையாளர் கட்டுப்பாடுகள், இலக்குக் கொள்கை மற்றும் பெயர் தீர்வு உள்ளமைவைத் தக்கவைக்கவும்.

$uri$is_args$args ஐ இந்த வெளிப்பாட்டுடன் மாற்றுவது அனுப்பப்படும் பிரதிநிதித்துவத்தை மாற்றுகிறது; முந்தையது இயல்பாக்கப்பட்ட பாதையையும் தற்போதைய வாதங்களையும் பயன்படுத்துகிறது. முடிவுப் புள்ளி ஒப்பந்தத்தின்படி தேர்ந்தெடுக்கவும், குறிப்பாக தப்பிக்கப்பட்ட பிரிப்பான்கள் முக்கியமானதாக இருக்கும்போது அல்லது கையொப்பம் அசல் இலக்கை உள்ளடக்கும்போது. வேண்டுமென்றே பாதையை மீண்டும் எழுதுவதற்கு வேறு தேவை உள்ளது.

இது தெரியும் HTTP கோரிக்கைக்குப் பொருந்தும். HTTPS CONNECT சுரங்கப்பாதை பிந்தைய கோரிக்கையை TLS உள்ளே எடுத்துச் செல்கிறது, மேலும் அதற்கு அதன் சொந்த ஆதரவு கையாளுதல் தேவை.

தொடர்புடைய கட்டுரைகள்