%3CLINGO-SUB%20id%3D%22lingo-sub-988719%22%20slang%3D%22en-US%22%3ERe%3A%20IIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-988719%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20followed%20this%20excellent%20guide%2C%20and%20succesfully%20used%20it%20to%20expose%20an%20internal%20webserver%20(akeneo%20pim)%20to%20the%20internet.%3C%2FP%3E%3CP%3EThere%20is%20one%20problem%20that%20I%20have%2C%20images%20are%20not%20shown.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20noticed%20a%20404%20on%20the%20iis%20log%20files%20(of%20the%20reverse%20proxy%20website)%20like%20this%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E2019-11-06%2015%3A52%3A52%20192.168.1.253%20GET%20%2Fmedia%2Fshow%2F1%252Fa%252F0%252F1%252F1a010a9833862e5745c20d12db63f4c3b72f8ff4_VER12220_Pharma_pack_Fles_glas_all_round_bruin_15_ml.jpg%2Fthumbnail_small%20-%20443%20-%2081.241.239.118%20Mozilla%2F5.0%2B(Windows%2BNT%2B10.0%3B%2BWin64%3B%2Bx64)%2BAppleWebKit%2F537.36%2B(KHTML%2C%2Blike%2BGecko)%2BChrome%2F77.0.3865.120%2BSafari%2F537.36%20%3CA%20href%3D%22https%3A%2F%2Fundisclosed.be%2F%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fundisclosed.be%2F%3C%2FA%3E%20404%2011%200%209%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20ideas%20on%20why%20this%20happens%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-992059%22%20slang%3D%22en-US%22%3ERe%3A%20IIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-992059%22%20slang%3D%22en-US%22%3E%3CP%3EHi%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Eto%20add%20in%20the%20debugging%2C%20this%20is%20my%20web.config%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CPRE%3E%26lt%3B%3Fxml%20version%3D%221.0%22%20encoding%3D%22UTF-8%22%3F%26gt%3B%0A%26lt%3Bconfiguration%26gt%3B%0A%20%20%20%20%26lt%3Bsystem.webServer%26gt%3B%0A%20%20%20%20%20%20%20%20%26lt%3Brewrite%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Brules%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Brule%20name%3D%22ReverseProxyInboundRule1%22%20stopProcessing%3D%22true%22%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bmatch%20url%3D%22(.*)%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Baction%20type%3D%22Rewrite%22%20url%3D%22http%3A%2F%2F192.168.1.252%2F%7BR%3A1%7D%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3BserverVariables%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bset%20name%3D%22HTTP_X_ORIGINAL_ACCEPT_ENCODING%22%20value%3D%22%7BHTTP_ACCEPT_ENCODING%7D%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bset%20name%3D%22HTTP_ACCEPT_ENCODING%22%20value%3D%22%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2FserverVariables%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2Frule%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2Frules%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3BoutboundRules%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Brule%20name%3D%22ReverseProxyOutboundRule1%22%20preCondition%3D%22ResponseIsHtml1%22%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bmatch%20filterByTags%3D%22A%2C%20Form%2C%20Img%22%20pattern%3D%22%5Ehttp(s)%3F%3A%2F%2F192.168.1.252%2F(.*)%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Baction%20type%3D%22Rewrite%22%20value%3D%22http%7BR%3A1%7D%3A%2F%2Fake.xxx.be%2F%7BR%3A2%7D%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2Frule%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Brule%20name%3D%22RestoreAcceptEncoding%22%20preCondition%3D%22NeedsRestoringAcceptEncoding%22%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bmatch%20serverVariable%3D%22HTTP_ACCEPT_ENCODING%22%20pattern%3D%22%5E(.*)%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Baction%20type%3D%22Rewrite%22%20value%3D%22%7BHTTP_X_ORIGINAL_ACCEPT_ENCODING%7D%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2Frule%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3BpreConditions%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3BpreCondition%20name%3D%22ResponseIsHtml1%22%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Badd%20input%3D%22%7BRESPONSE_CONTENT_TYPE%7D%22%20pattern%3D%22%5Etext%2Fhtml%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2FpreCondition%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3BpreCondition%20name%3D%22NeedsRestoringAcceptEncoding%22%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Badd%20input%3D%22%7BHTTP_X_ORIGINAL_ACCEPT_ENCODING%7D%22%20pattern%3D%22.%2B%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2FpreCondition%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2FpreConditions%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2FoutboundRules%26gt%3B%0A%20%20%20%20%20%20%20%20%26lt%3B%2Frewrite%26gt%3B%0A%20%20%20%20%20%20%20%20%26lt%3Bcaching%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Bprofiles%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3Badd%20extension%3D%22.jpg%22%20policy%3D%22CacheUntilChange%22%20kernelCachePolicy%3D%22DisableCache%22%20%2F%26gt%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%26lt%3B%2Fprofiles%26gt%3B%0A%20%20%20%20%20%20%20%20%26lt%3B%2Fcaching%26gt%3B%0A%20%20%20%20%26lt%3B%2Fsystem.webServer%26gt%3B%0A%26lt%3B%2Fconfiguration%26gt%3B%3C%2FPRE%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1076719%22%20slang%3D%22en-US%22%3ERe%3A%20IIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1076719%22%20slang%3D%22en-US%22%3E%3CP%3EHello%20TomyVO%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20issue%20here%20is%20plainly%20explained%20in%20the%20status%20code%20that%20IIS%20issues%20when%20handling%20this%20request%3A%20namely%20%3CSTRONG%3E404.11%3C%2FSTRONG%3E.%20Checking%20the%20IIS%20status%20codes%20as%20detailed%20in%20the%20documentation%20(%3CA%20href%3D%22http%3A%2F%2Flinqto.me%2FIISCodes%22%20target%3D%22_self%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttp%3A%2F%2Flinqto.me%2FIISCodes%3C%2FA%3E)%20the%20meaning%20of%20this%20status%20code%20is%3A%20request%20contains%20double%20escape%20sequence.%20The%20sequence%20would%20be%20the%20part%20in%20bold%20in%20the%20request%20excerpt%20you%20pasted%3A%3C%2FP%3E%0A%3CP%3E%3CBR%20%2F%3E2019-11-06%2015%3A52%3A52%20192.168.1.253%20GET%20%2Fmedia%2Fshow%2F%3CSTRONG%3E%3CFONT%20color%3D%22%23FF0000%22%3E1%252Fa%252F0%252F1%252F1a010a9833862e5745c20d12db63f4c3b72f8ff4%3C%2FFONT%3E%3C%2FSTRONG%3E_VER12220_Pharma_pack_Fles_glas_all_round_bruin_15_ml.jpg%2Fthumbnail_small%20-%20443%20-%2081.241.239.118%20Mozilla%2F5.0%2B(Windows%2BNT%2B10.0%3B%2BWin64%3B%2Bx64)%2BAppleWebKit%2F537.36%2B(KHTML%2C%2Blike%2BGecko)%2BChrome%2F77.0.3865.120%2BSafari%2F537.36%20%3CA%20href%3D%22https%3A%2F%2Fundisclosed.be%2F%22%20target%3D%22_blank%22%20rel%3D%22noopener%20nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fundisclosed.be%2F%3C%2FA%3E%20%3CSTRONG%3E404%2011%3C%2FSTRONG%3E%200%209%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EWhat%20we%20would%20have%20to%20ask%20is%3A%20how%20was%20this%20link%20generated%20by%20your%20backend%20server%3F%20Was%20the%20backend%20server%20that%20doubly%20escaped%20the%20file%3F%20If%20so%2C%20the%20problem%20is%20on%20the%20backend%20server.%20If%20not%20what%20you%20can%20try%20and%20do%20is%20gather%20a%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fiis%2Ftroubleshoot%2Fusing-failed-request-tracing%2Ftroubleshooting-failed-requests-using-tracing-in-iis%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%3EFREB%20trace%3C%2FA%3E%20for%20a%20404.11%20status%20code%20and%20see%20if%20the%20url%20that%20is%20requested%20by%20the%20client%20is%20not%20somehow%20rewritten%20by%20url%20rewrite.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1081018%22%20slang%3D%22en-US%22%3ERe%3A%20IIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1081018%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Paul%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFirst%20of%20all%20thank%20you%20for%20this%20excellent%20article.%20Following%20the%20same%20I've%20setup%20a%20reverse%20proxy.%20But%2C%20I'm%20facing%20an%20issue%2C%20after%20getting%20the%20response%20from%20backend%20server.%20The%20URL%20is%20not%20changing%20back%20to%20Web%20Server's%20host%20name.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Efor%20example%2C%20when%20i%20request%20a%20Home.html%20from%20Backend%20server%2C%20the%20URL%20shows%20as%20https%3A%2F%2F%3CSTRONG%3Ebackendserverhostname%3C%2FSTRONG%3E%2FHome.html%20-%20Actually%20it%20should%20rewrite%20as%20https%3A%2F%2F%3CSTRONG%3Ewebserverhostname%3C%2FSTRONG%3E%2FHome.html%20using%20the%20Rules%20i%20mentioned%2C%20but%20this%20is%20not%20happening.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EMy%20web%20and%20app%20servers%20are%20hosted%20in%20Azure%20environment.%20Does%20the%20reverse%20proxy%20you%20suggested%20does%20not%20work%20in%20Azure%20environment%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20let%20me%20know%20if%20you%20need%20any%20further%20information.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThanks%2C%3C%2FP%3E%3CP%3EVenugopal%20Neelakandan%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-846259%22%20slang%3D%22en-US%22%3EIIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-846259%22%20slang%3D%22en-US%22%3E%3CP%3EThis%20is%20the%20second%20article%20in%20a%20three-part%20series%20of%20articles%20dealing%20with%20setting%20up%20IIS%20as%20a%20reverse%20proxy.%20Check%20out%20part%20one%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2FIIS-Support-Blog%2FSetup-IIS-with-URL-Rewrite-as-a-reverse-proxy-for-real-world%2Fba-p%2F846222%23M343%22%20target%3D%22_blank%22%3Ehere%3C%2FA%3E.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ETesting%20this%20new%20setup%20for%20basic%20scenarios%20may%20work%2C%20but%20you%20can%20also%20be%20presented%20with%20a%20couple%20of%20issues.%20The%20first%20one%20is%20that%20you%20may%20have%20500%20status%20codes%20when%20you%20try%20to%20access%20your%20backend%20server.%20If%20you%20do%20FREB%20tracing%2C%20you%20will%20see%20that%20these%20status%20codes%20are%20actually%20logged%20by%20IIS%20and%20URL%20Rewrite%20with%20the%20following%20message%20in%20the%20trace%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOutbound%20rewrite%20rules%20cannot%20be%20applied%20when%20the%20content%20of%20the%20HTTP%20response%20is%20encoded%20(%22gzip%22).%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3EStatus%20code%20for%20this%20is%20500.52.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThis%20is%20because%20the%20responses%20that%20are%20coming%20from%20the%20back-end%20server%20are%20using%20HTTP%20Compression%2C%20and%20URL%20rewrite%20cannot%20modify%20a%20response%20that%20is%20already%20compressed.%20This%20causes%20a%20processing%20error%20for%20the%20outbound%20rule%20resulting%20in%20the%20500.52%20status%20code.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFixing%20the%20500.52%20status%20code%20cause%20by%20compressed%20responses.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EA%20client%20indicates%20to%20the%20server%20that%20it%20is%20willing%20to%20accept%20compressed%20content%20by%20indicating%20this%20in%20the%20http%20headers%20it%20sends%20to%20the%20server%20alongside%20the%20request.%20This%20is%20indicated%20in%20the%20%E2%80%98Accept-Encoding%E2%80%99%20Header.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThere%20are%20two%20ways%20to%20work%20around%20this%3A%20either%20you%20turn%20off%20compression%20on%20the%20backend%20server%20that%20is%20delivering%20the%20HTTP%20responses%20(which%20may%20or%20may%20not%20be%20possible%2C%20depending%20on%20your%20configuration)%2C%20or%20we%20attempt%20to%20indicate%20to%20the%20backend%20server%20the%20client%20does%20not%20accept%20compressed%20responses%20by%20removing%20the%20header%20when%20the%20request%20comes%20into%20the%20IIS%20reverse%20proxy%20and%20by%20placing%20it%20back%20when%20the%20response%20leaves%20the%20IIS%20server.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20will%20only%20detail%20the%20second%20alternative%2C%20with%20regards%20to%20the%20removal%20and%20re-instatement%20of%20the%20HTTP%20header.%20To%20do%20this%2C%20we%20will%20first%20need%20to%20create%20two%20HTTP%20Variables%20in%20URL%20Rewrite.%20After%20selecting%20the%20URL%20Rewrite%20Icon%20and%20double%20clicking%20it%20in%20the%20IIS%20Manager%20Console%2C%20you%20will%20have%20a%20%E2%80%98View%20Server%20Variables%E2%80%99%20action%20button%20on%20the%20right-hand%20side%20pane.%20Click%20this%20button%20to%20be%20able%20to%20add%20new%20server%20variables.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EClick%20the%20%E2%80%98Add%E2%80%99%20button%20on%20the%20right-hand%20side%20pane%20to%20add%20a%20new%20server%20variable.%20We%20will%20need%20to%20add%20two%20variables%20named%20HTTP_ACCEPT_ENCODING%20and%20HTTP_X_ORIGINAL_ACCEPT_ENCODING%20as%20shown%20here%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3EOnce%20this%20is%20complete%2C%20we%20will%20need%20to%20use%20these%20variables%20both%20in%20the%20inbound%20rules%2C%20to%20remove%20the%20Accept-Encoding%20header%20and%20in%20the%20Outbound%20Rules%20to%20place%20this%20header%20back%20again.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EGo%20to%20the%20Inbound%20Rules%20section%20in%20URL%20Rewrite.%20This%20section%20should%20just%20contain%20one%20inbound%20rule%2C%20called%20%E2%80%98Reverse%20Proxy%20Inbound%20Rule%201%E2%80%99.%20Select%20this%20rule%20and%20click%20the%20%E2%80%98Edit%E2%80%99%20action%20link%20on%20the%20right-hand%20side%20panel%20of%20the%20IIS%20Administration%20Console%20to%20be%20able%20to%20edit%20the%20details%20of%20this%20rule.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3E%3CBR%20%2F%3EIn%20the%20%E2%80%98Server%20Variables%E2%80%99%20section%20we%20will%20need%20to%20add%20the%20two%20server%20variables%20that%20we%20have%20declared%20earlier.%20We%20will%20be%20copying%20the%20contents%20of%20the%20HTTP_ACCEPT_ENCODING%20server%20variable%20(which%20captures%20the%20content%20of%20the%20Accept-Encoding%20Header)%20into%20the%20HTTP_X_ORIGINAL_ACCEPT_ENCODING.%20To%20do%20this%2C%20click%20the%20Add%20button%20on%20the%20interface%2C%20and%20then%20chose%20the%20HTTP_X_ORIGINAL_ACCEPT_ENCODING%20from%20the%20dropdown%20list%20that%20appears%20in%20the%20%E2%80%98Set%20Server%20Variables%E2%80%99%20window%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3ESet%20this%20variable%20to%20capture%20the%20value%20of%20HTTP_ACCEPT_ENCODING%20by%20placing%20the%20string%20%7BHTTP_ACCEPT_ENCODING%7D%20in%20the%20Value%20textbox.%20Whenever%20you%20see%20something%20between%20curly%20braces%20%7B%7D%20in%20URL%20Rewrite%2C%20this%20means%20that%20URL%20Rewrite%20will%20use%20the%20value%20of%20whatever%20expression%20is%20inside%20the%20braces%20%E2%80%93%20in%20this%20case%20the%20server%20variable.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENow%20it%20is%20time%20to%20repeat%20the%20process%20for%20the%20HTTP_ACCEPT_ENCODING%20variable%20which%20we%20should%20be%20setting%20to%20empty.%20This%20variable%20will%20be%20used%20by%20URL%20Rewrite%20when%20it%20builds%20the%20request%20to%20forward%20to%20the%20backend%20server.%20So%20if%20we%20do%20not%20wish%20this%20request%20to%20have%20an%20Accept-Encoding%20header%2C%20we%20must%20empty%20its%20value.%20Press%20the%20%E2%80%98Add%E2%80%99%20button%20again%20on%20the%20%E2%80%98Server%20Variables%E2%80%99%20pane%2C%20and%20then%20fill%20in%20the%20%E2%80%98Set%20Server%20Variable%E2%80%99%20window%20as%20follows%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3ENote%20that%20the%20interface%20will%20not%20allow%20you%20to%20set%20the%20variable%E2%80%99s%20value%20to%20empty%2C%20hence%20you%20can%20set%20this%20to%20any%20arbitrary%20string%20(I%20just%20use%20%E2%80%98eee%E2%80%99).%20We%20will%20correct%20this%20manually%20in%20the%20configuration%20files%20afterwards.%20Once%20this%20is%20done%2C%20press%20the%20%E2%80%98Apply%E2%80%99%20button%20to%20save%20the%20configuration%20changes%20to%20the%20IIS%20configuration%20store%20%E2%80%93%20in%20this%20case%20the%20web.config%20of%20your%20website.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EOnce%20the%20changes%20are%20saved%2C%20time%20to%20do%20some%20manual%20tweaking%20using%20Notepad%20or%20Notepad%2B%2B%2C%20or%20any%20other%20XML%20editor%20of%20your%20choice.%20Open%20the%20web.config%20file%20that%20is%20present%20at%20the%20root%20of%20your%20website%2C%20and%20find%20the%20section.%20Here%20you%20should%20find%20the%20InboundReverseProxyRule1%20rule%20definition%20which%20should%20look%20like%20the%20snippet%20below%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CRULE%20name%3D%22%26quot%3BReverseProxyInboundRule1%26quot%3B%22%20stopprocessing%3D%22%26quot%3Btrue%26quot%3B%22%3E%20%3CMATCH%20url%3D%22%26quot%3B(.*)%26quot%3B%22%3E%3C%2FMATCH%3E%20%3CCONDITIONS%20logicalgrouping%3D%22%26quot%3BMatchAll%26quot%3B%22%20trackallcaptures%3D%22%26quot%3Bfalse%26quot%3B%22%3E%3C%2FCONDITIONS%3E%20%3CSERVERVARIABLES%3E%20%3CSET%20name%3D%22%26quot%3BHTTP_X_ORIGINAL_ACCEPT_ENCODING%26quot%3B%22%20value%3D%22%26quot%3B%7BHTTP_ACCEPT_ENCODING%7D%26quot%3B%22%3E%3C%2FSET%3E%20%3CSET%20name%3D%22%26quot%3BHTTP_ACCEPT_ENCODING%26quot%3B%22%20value%3D%22%26quot%3Beee%26quot%3B%22%3E%3C%2FSET%3E%20%3C%2FSERVERVARIABLES%3E%20%3C%2FRULE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20the%20section%2C%20set%20the%20value%20of%20the%20HTTP_ACCEPT_ENCODING%20variable%20to%20empty%20(delete%20the%20value%20that%20is%20between%20the%20quotes).%20The%20new%20line%20of%20configuration%20should%20look%20like%20the%20following%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CSET%20name%3D%22%26quot%3BHTTP_ACCEPT_ENCODING%26quot%3B%22%20value%3D%22%26quot%3B%26quot%3B%22%3E%3C%2FSET%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENote%3A%20if%20you%20cannot%20save%20the%20file%20because%20of%20elevation%20privileges%20requirements%2C%20then%20you%20can%20save%20the%20web.config%20to%20another%20folder%2C%20like%20%E2%80%98My%20Documents%E2%80%99%20and%20then%20copy%20it%20over%20manually%20replacing%20the%20original%20web.config.%20This%20will%20require%20you%20to%20confirm%20the%20replace%20with%20an%20elevated%20prompt%20as%20well%2C%20but%20that%20should%20not%20be%20a%20problem.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENow%20on%20to%20the%20outbound%20rule%20modification.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhen%20we%20receive%20the%20responses%20from%20the%20backend%20server%2C%20we%20need%20to%20forward%20them%20back%20to%20the%20browser.%20To%20be%20able%20to%20correctly%20do%20this%2C%20we%20will%20need%20to%20restore%20the%20value%20of%20the%20HTTP_ACCEPT_ENCODING%20variable%20to%20what%20it%20was%20before%20we%20changed%20it%20to%20empty.%20Create%20a%20new%20Outbound%20Rule%20from%20the%20URL%20Rewrite%20Pane%2C%20by%20clicking%20the%20%E2%80%98Add%20Rule%E2%80%99%20action%20link%20on%20the%20right%20hand%20side%20pane%2C%20and%20then%20selecting%20the%20%E2%80%98Blank%20Rule%E2%80%99%20from%20the%20Outbound%20Rules%20section%20of%20the%20%E2%80%98Add%20Rule(s)%E2%80%99%20Window.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3ECall%20the%20new%20rule%20%E2%80%98RestoreAcceptEncoding%E2%80%99.%20Outbound%20rules%20in%20URL%20Rewrite%20are%20only%20executed%20if%20we%20are%20able%20to%20match%20a%20precondition.%20A%20pre-condition%20is%20a%20check%20we%20will%20be%20running%20on%20the%20response%20to%20determine%20if%20we%20wish%20to%20perform%20an%20action%20or%20not.%20So%2C%20the%20next%20part%20of%20the%20configuration%20will%20be%20to%20create%20a%20new%20pre-condition%20to%20be%20used%20with%20the%20outbound%20rule%20we%20are%20creating.%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3ESelect%20from%20the%20Preconditions%20dropdown%2C%20and%20then%20configure%20the%20precondition%20as%20follows.%20Give%20the%20precondition%20a%20name%20%E2%80%93%20call%20it%20NeedsRestoringAcceptEncoding%2C%20and%20the%20select%20%E2%80%98Regular%20Expression%E2%80%99%20from%20the%20%E2%80%98Using%E2%80%99%20dropdown%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3ESelect%20the%20%E2%80%98Match%20All%E2%80%99%20from%20the%20%E2%80%98Logical%20Grouping%E2%80%99%20dropdown%20list%20and%20proceed%20to%20add%20a%20condition%20by%20pressing%20the%20%E2%80%98Add%E2%80%99%20button.%20The%20condition%20will%20be%20the%20check%20we%20will%20be%20running%20to%20determine%20if%20we%20wish%20to%20apply%20the%20transformation%20which%20will%20be%20detailed%20in%20the%20outbound%20rule.%20We%20can%20have%20several%20conditions%20grouped%20together%20in%20one%20precondition%20clause.%20Configure%20the%20condition%20as%20follows%3A%20set%20the%20%7BHTTP_X_ORIGINAL_ACCEPT_ENCODING%7D%20as%20a%20value%20for%20the%20%E2%80%98Condition%20Input%E2%80%99%20textbox%2C%20select%20the%20%E2%80%98Matches%20the%20Pattern%E2%80%99%20item%20from%20the%20%E2%80%98Check%20if%20input%20String%E2%80%99%20dropdown%2C%20and%20finally%20place%20%E2%80%98.%2B%E2%80%99%20as%20a%20pattern.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3EAfter%20having%20created%20the%20pre-condition%20for%20the%20outbound%20rule%2C%20we%20can%20now%20proceed%20to%20configure%20the%20rule%20itself.%20Select%20%E2%80%98Server%20Variable%E2%80%99%20from%20the%20Matching%20Scope%20dropdown%20and%20place%20the%20HTTP_ACCEPT_ENCODING%20variable%20name%20in%20the%20%E2%80%98Variable%20Name%E2%80%99%20textbox.%20Select%20%E2%80%98Matches%20the%20Pattern%E2%80%99%20in%20the%20Variable%20Value%20dropdown%20and%20the%20%E2%80%98Regular%20Expressions%E2%80%99%20in%20the%20Using%20dropdown%2C%20and%20place%20the%20following%20pattern%20%E2%80%98%5E(.*)%E2%80%99%20in%20the%20Pattern%20textbox%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3EIn%20the%20%E2%80%98Actions%E2%80%99%20pane%2C%20select%20%E2%80%98Rewrite%E2%80%99%20as%20an%20action%20from%20the%20%E2%80%98Action%E2%80%99%20dropdown%2C%20and%20place%20the%20%7BHTTP_X_ORIGINAL_ACCEPT_ENCODING%7D%20value%20in%20the%20%E2%80%98Value%E2%80%99%20textbox.%20Check%20the%20%E2%80%98Replace%20Existing%20Server%20variable%20value%E2%80%99%20checkbox.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3C%2FP%3E%3CP%3EClick%20the%20%E2%80%98Apply%E2%80%99%20button%20to%20save%20the%20changes%20entered%20by%20this%20rule%20to%20the%20IIS%20configuration%20store.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EBy%20configuring%20the%20Inbound%20and%20Outbound%20rules%2C%20we%20are%20now%20able%20to%20mitigate%20the%20500.52%20status%20code%20if%20our%20backend%20server%20was%20compressing%20the%20responses%20as%20a%20result%20of%20the%20client%20browser%20sending%20%E2%80%98Accept-Encoding%E2%80%99%20headers%20in%20the%20incoming%20requests.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EIn%20%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2FIIS-Support-Blog%2FIIS-and-Url-Rewrite-rewriting-the-outbound-response-contents%2Fba-p%2F846351%23M345%22%20target%3D%22_blank%22%3Ethe%20next%20part%3C%2FA%3E%2C%20we%20will%20look%20at%20configuring%20more%20outbound%20rules%20to%20deal%20with%20complex%20scenarios%20of%20JavaScript%20encoded%20data.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3Ewritten%20by%3A%20%3CA%20href%3D%22http%3A%2F%2Flinqto.me%2Fabout%2Fpcociuba%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%20noopener%20noreferrer%22%20target%3D%22_blank%22%3EPaul%20Cociuba%3C%2FA%3E%3CBR%20%2F%3Ereviewed%20by%3A%20Muna%20AlHasan%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-TEASER%20id%3D%22lingo-teaser-846259%22%20slang%3D%22en-US%22%3E%3CP%3EWhen%20setting%20up%20a%20reverse%20proxy%20rule%20with%20IIS%20and%20url-rewrite%2C%20you%20may%20hit%20some%20real%20world%20problems%20when%20enabling%20the%20configuration.%20Here%20is%20how%20to%20deal%20with%20the%20first%20of%20them%20500.52%20status%20codes%20because%20of%20backend%20compression%20of%20responses.%3C%2FP%3E%3C%2FLINGO-TEASER%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1576474%22%20slang%3D%22en-US%22%3ERe%3A%20IIS%20acting%20as%20reverse%20proxy%3A%20Where%20the%20problems%20start%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1576474%22%20slang%3D%22en-US%22%3E%3CP%3EHi%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20getting%20following%20error%20after%20configuring%20URL%20Rewrite.%20I%20am%20forwarding%20request%20from%20default%20port%2080%20to%20%3CA%20href%3D%22https%3A%2F%2F127.0.0.1%3A165%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2F127.0.0.1%3A165%3C%2FA%3E.%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CH2%20id%3D%22toc-hId-1820230995%22%20id%3D%22toc-hId-1820230995%22%3E502%20-%20Web%20server%20received%20an%20invalid%20response%20while%20acting%20as%20a%20gateway%20or%20proxy%20server.%3C%2FH2%3E%3CH3%20id%3D%22toc-hId--928439471%22%20id%3D%22toc-hId--928439471%22%3EThere%20is%20a%20problem%20with%20the%20page%20you%20are%20looking%20for%2C%20and%20it%20cannot%20be%20displayed.%20When%20the%20Web%20server%20(while%20acting%20as%20a%20gateway%20or%20proxy)%20contacted%20the%20upstream%20content%20server%2C%20it%20received%20an%20invalid%20response%20from%20the%20content%20server.%3C%2FH3%3E%3C%2FLINGO-BODY%3E
Microsoft

This is the second article in a three-part series of articles dealing with setting up IIS as a reverse proxy. Check out part one here.

 

Testing this new setup for basic scenarios may work, but you can also be presented with a couple of issues. The first one is that you may have 500 status codes when you try to access your backend server. If you do FREB tracing, you will see that these status codes are actually logged by IIS and URL Rewrite with the following message in the trace:

 

Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded ("gzip").

clipboard_image_0.png

Status code for this is 500.52.

 

This is because the responses that are coming from the back-end server are using HTTP Compression, and URL rewrite cannot modify a response that is already compressed. This causes a processing error for the outbound rule resulting in the 500.52 status code.

 

Fixing the 500.52 status code cause by compressed responses.

 

A client indicates to the server that it is willing to accept compressed content by indicating this in the http headers it sends to the server alongside the request. This is indicated in the ‘Accept-Encoding’ Header.

 

There are two ways to work around this: either you turn off compression on the backend server that is delivering the HTTP responses (which may or may not be possible, depending on your configuration), or we attempt to indicate to the backend server the client does not accept compressed responses by removing the header when the request comes into the IIS reverse proxy and by placing it back when the response leaves the IIS server.

 

I will only detail the second alternative, with regards to the removal and re-instatement of the HTTP header. To do this, we will first need to create two HTTP Variables in URL Rewrite. After selecting the URL Rewrite Icon and double clicking it in the IIS Manager Console, you will have a ‘View Server Variables’ action button on the right-hand side pane. Click this button to be able to add new server variables.

 

clipboard_image_1.png

 

Click the ‘Add’ button on the right-hand side pane to add a new server variable. We will need to add two variables named HTTP_ACCEPT_ENCODING and HTTP_X_ORIGINAL_ACCEPT_ENCODING as shown here:

 

clipboard_image_2.png

Once this is complete, we will need to use these variables both in the inbound rules, to remove the Accept-Encoding header and in the Outbound Rules to place this header back again.

 

Go to the Inbound Rules section in URL Rewrite. This section should just contain one inbound rule, called ‘Reverse Proxy Inbound Rule 1’. Select this rule and click the ‘Edit’ action link on the right-hand side panel of the IIS Administration Console to be able to edit the details of this rule.

 

clipboard_image_3.png


In the ‘Server Variables’ section we will need to add the two server variables that we have declared earlier. We will be copying the contents of the HTTP_ACCEPT_ENCODING server variable (which captures the content of the Accept-Encoding Header) into the HTTP_X_ORIGINAL_ACCEPT_ENCODING. To do this, click the Add button on the interface, and then chose the HTTP_X_ORIGINAL_ACCEPT_ENCODING from the dropdown list that appears in the ‘Set Server Variables’ window:

 

clipboard_image_4.png

Set this variable to capture the value of HTTP_ACCEPT_ENCODING by placing the string {HTTP_ACCEPT_ENCODING} in the Value textbox. Whenever you see something between curly braces {} in URL Rewrite, this means that URL Rewrite will use the value of whatever expression is inside the braces – in this case the server variable.

 

Now it is time to repeat the process for the HTTP_ACCEPT_ENCODING variable which we should be setting to empty. This variable will be used by URL Rewrite when it builds the request to forward to the backend server. So if we do not wish this request to have an Accept-Encoding header, we must empty its value. Press the ‘Add’ button again on the ‘Server Variables’ pane, and then fill in the ‘Set Server Variable’ window as follows:

 

clipboard_image_5.png

Note that the interface will not allow you to set the variable’s value to empty, hence you can set this to any arbitrary string (I just use ‘eee’). We will correct this manually in the configuration files afterwards. Once this is done, press the ‘Apply’ button to save the configuration changes to the IIS configuration store – in this case the web.config of your website.

 

Once the changes are saved, time to do some manual tweaking using Notepad or Notepad++, or any other XML editor of your choice. Open the web.config file that is present at the root of your website, and find the section. Here you should find the InboundReverseProxyRule1 rule definition which should look like the snippet below:

 

 

<rule name="ReverseProxyInboundRule1" stopProcessing="true">
     <match url="(.*)" />
     <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
     <serverVariables>
         <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING"    value="{HTTP_ACCEPT_ENCODING}" />
         <set name="HTTP_ACCEPT_ENCODING" value="eee" />
     </serverVariables>
</rule>

 

 

In the section, set the value of the HTTP_ACCEPT_ENCODING variable to empty (delete the value that is between the quotes). The new line of configuration should look like the following:

 

 

<set name="HTTP_ACCEPT_ENCODING" value="" />

 

 

Note: if you cannot save the file because of elevation privileges requirements, then you can save the web.config to another folder, like ‘My Documents’ and then copy it over manually replacing the original web.config. This will require you to confirm the replace with an elevated prompt as well, but that should not be a problem.

 

Now on to the outbound rule modification.

 

When we receive the responses from the backend server, we need to forward them back to the browser. To be able to correctly do this, we will need to restore the value of the HTTP_ACCEPT_ENCODING variable to what it was before we changed it to empty. Create a new Outbound Rule from the URL Rewrite Pane, by clicking the ‘Add Rule’ action link on the right hand side pane, and then selecting the ‘Blank Rule’ from the Outbound Rules section of the ‘Add Rule(s)’ Window.

 

clipboard_image_6.png

Call the new rule ‘RestoreAcceptEncoding’. Outbound rules in URL Rewrite are only executed if we are able to match a precondition. A pre-condition is a check we will be running on the response to determine if we wish to perform an action or not. So, the next part of the configuration will be to create a new pre-condition to be used with the outbound rule we are creating.

clipboard_image_7.png

Select from the Preconditions dropdown, and then configure the precondition as follows. Give the precondition a name – call it NeedsRestoringAcceptEncoding, and the select ‘Regular Expression’ from the ‘Using’ dropdown:

 

clipboard_image_8.png

Select the ‘Match All’ from the ‘Logical Grouping’ dropdown list and proceed to add a condition by pressing the ‘Add’ button. The condition will be the check we will be running to determine if we wish to apply the transformation which will be detailed in the outbound rule. We can have several conditions grouped together in one precondition clause. Configure the condition as follows: set the {HTTP_X_ORIGINAL_ACCEPT_ENCODING} as a value for the ‘Condition Input’ textbox, select the ‘Matches the Pattern’ item from the ‘Check if input String’ dropdown, and finally place ‘.+’ as a pattern.

 

clipboard_image_9.png

After having created the pre-condition for the outbound rule, we can now proceed to configure the rule itself. Select ‘Server Variable’ from the Matching Scope dropdown and place the HTTP_ACCEPT_ENCODING variable name in the ‘Variable Name’ textbox. Select ‘Matches the Pattern’ in the Variable Value dropdown and the ‘Regular Expressions’ in the Using dropdown, and place the following pattern ‘^(.*)’ in the Pattern textbox:

 

clipboard_image_10.png

In the ‘Actions’ pane, select ‘Rewrite’ as an action from the ‘Action’ dropdown, and place the {HTTP_X_ORIGINAL_ACCEPT_ENCODING} value in the ‘Value’ textbox. Check the ‘Replace Existing Server variable value’ checkbox.

 

clipboard_image_11.png

Click the ‘Apply’ button to save the changes entered by this rule to the IIS configuration store.

 

By configuring the Inbound and Outbound rules, we are now able to mitigate the 500.52 status code if our backend server was compressing the responses as a result of the client browser sending ‘Accept-Encoding’ headers in the incoming requests.

 

In the next part, we will look at configuring more outbound rules to deal with complex scenarios of JavaScript encoded data.

 

written by: Paul Cociuba
reviewed by: Muna AlHasan

 

5 Comments
Visitor

Hello,

 

I have followed this excellent guide, and succesfully used it to expose an internal webserver (akeneo pim) to the internet.

There is one problem that I have, images are not shown.

 

I noticed a 404 on the iis log files (of the reverse proxy website) like this:

 

2019-11-06 15:52:52 192.168.1.253 GET /media/show/1%2Fa%2F0%2F1%2F1a010a9833862e5745c20d12db63f4c3b72f8ff4_VER12220_Pharma_pack_Fles_glas_all_round_bruin_15_ml.jpg/thumbnail_small - 443 - 81.241.239.118 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.120+Safari/537.36 https://undisclosed.be/ 404 11 0 9

 

Any ideas on why this happens?

 

Visitor

Hi,

 

to add in the debugging, this is my web.config:

 

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
                    <match url="(.*)" />
                    <action type="Rewrite" url="http://192.168.1.252/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="{HTTP_ACCEPT_ENCODING}" />
                        <set name="HTTP_ACCEPT_ENCODING" value="" />
                    </serverVariables>
                </rule>
            </rules>
            <outboundRules>
                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
                    <match filterByTags="A, Form, Img" pattern="^http(s)?://192.168.1.252/(.*)" />
                    <action type="Rewrite" value="http{R:1}://ake.xxx.be/{R:2}" />
                </rule>
                <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
                </rule>
                <preConditions>
                    <preCondition name="ResponseIsHtml1">
                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
                    </preCondition>
                    <preCondition name="NeedsRestoringAcceptEncoding">
                        <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
                    </preCondition>
                </preConditions>
            </outboundRules>
        </rewrite>
        <caching>
            <profiles>
                <add extension=".jpg" policy="CacheUntilChange" kernelCachePolicy="DisableCache" />
            </profiles>
        </caching>
    </system.webServer>
</configuration>
Microsoft

Hello TomyVO,

 

The issue here is plainly explained in the status code that IIS issues when handling this request: namely 404.11. Checking the IIS status codes as detailed in the documentation (http://linqto.me/IISCodes) the meaning of this status code is: request contains double escape sequence. The sequence would be the part in bold in the request excerpt you pasted:


2019-11-06 15:52:52 192.168.1.253 GET /media/show/1%2Fa%2F0%2F1%2F1a010a9833862e5745c20d12db63f4c3b72f8ff4_VER12220_Pharma_pack_Fles_glas_all_round_bruin_15_ml.jpg/thumbnail_small - 443 - 81.241.239.118 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/77.0.3865.120+Safari/537.36 https://undisclosed.be/ 404 11 0 9

 

What we would have to ask is: how was this link generated by your backend server? Was the backend server that doubly escaped the file? If so, the problem is on the backend server. If not what you can try and do is gather a FREB trace for a 404.11 status code and see if the url that is requested by the client is not somehow rewritten by url rewrite.

Occasional Visitor

Hi Paul,

 

First of all thank you for this excellent article. Following the same I've setup a reverse proxy. But, I'm facing an issue, after getting the response from backend server. The URL is not changing back to Web Server's host name.

 

for example, when i request a Home.html from Backend server, the URL shows as https://backendserverhostname/Home.html - Actually it should rewrite as https://webserverhostname/Home.html using the Rules i mentioned, but this is not happening.

 

My web and app servers are hosted in Azure environment. Does the reverse proxy you suggested does not work in Azure environment?

 

Please let me know if you need any further information.

 

Thanks,

Venugopal Neelakandan

Occasional Visitor

Hi 

I am getting following error after configuring URL Rewrite. I am forwarding request from default port 80 to https://127.0.0.1:165.

502 - Web server received an invalid response while acting as a gateway or proxy server.

There is a problem with the page you are looking for, and it cannot be displayed. When the Web server (while acting as a gateway or proxy) contacted the upstream content server, it received an invalid response from the content server.