SSL and Ionics Redirect - Execution Order?

Topics: Developer Forum, Project Management Forum, User Forum
Aug 6, 2009 at 2:27 AM

My question is actually straight forward.

Here is the situation.  I have a web site where two folders (In a virtual directory) need to be run under SSL.  I have figured out how to use a RedirectRule to push people to the "HTTPS" or SSL location of these pages.

But here is the behavior I'm seeing, IIS 6.0

1) SSL certificate is installed on IIS Server, by using the Ionics ISAPI filter I can push people to the "Secure" rendition of the page, if the actual folder does not "require" SSL (check box under Directory Security, Enable SSL)

2) If The folder is REQUIRED to use SSL (check box in directory security is checked) the SSL encryption kicks in before the Ionics ISAPI filter runs and therefore you get the 403.4 forbidden error.

End of the day, this is what I am trying to accomplish.  We have a massive web site with relative urls.  For production, at the present moment we do not want to switch every url to use HTTPS, however we DO WANT these two folders to run under HTTPS.

Therefore, is my only option to NOT require SSL encryption at the folder level (In IIS)? It appears my RedirectRule won't kick off in time.

Or am I maybe doing this wrong?

Is it possible to have required SSL on a folder or virtual directory and then have IONIC redirect a non HTTPS link BEFORE SSL flags this forbidden error?

Thanks

Coordinator
Aug 6, 2009 at 2:42 AM

Hmm, I don't know.

I don't understand where the 403.4 is coming from in step 2.   What does it mean "the SSL encryption kicks in and therefore you get the 403.4".    Does it ever work with an https URL when marked as "Requires SSL" ?  If you turn of IIRF, can you use an https scheme?  then turning on the IIRF, you automatically get a 403.4 ?  Really?

No, there's something I don't understand.  Can you show me the relevant rules?

 

 

Aug 6, 2009 at 3:32 AM
Edited Aug 6, 2009 at 3:37 AM

Cheeso:

Ok let me be more clear and also show you some simple rules too.

On IIS Server - - SSL Certificate is installed.  Default IIS Web Site.  Within "buynow" virtual directory there a "Cart" folder.  Through IIS, I have enabled/required SSL (through right click menu, properties, directory security, Secure Communications, Require Secure Channel (SSL) is checked.

IONIC INI File - - just a very simple example which works ONLY if that Require Secure Channel SSL is UNCHECKED (in step one)

RewriteLog  c:\temp\IONIC.out
RewriteLogLevel 3

RewriteCond %{SERVER_PORT} ^80$
RewriteCond %{HTTP_HOST}   ^development.pia.com$ [I]
RewriteCond %{HTTP_URL}    ^(/buynow/Cart/) [I]
RedirectRule ^/(.*)$        https://development.pia.com/$1 [R]

So baseline if coming through Port 80, this host, this directory, redirect to https: version

http://development.pia.com/buynow/cart/<somepage> -->   https://development.pia.com/buynow/cart/<somepage>

This works when require Secure Channel is unchecked.

When Require Secure Channel is CHECKED, it appears the SSL process occurs before my ISAPI filter and you get the out of the box "this page requires Secure Socket Connection" IE error page. The page request is never logged in my log file, etc.

So unless I am doing this wrong, is this standard behavior/no way around this?

I hope this is more clear

Coordinator
Aug 6, 2009 at 4:54 PM

Very clear.

I don't know if you need IIRF if all you are doing is redirecting for SSL.

Here is a post that solves the same problem in a different way - you may find it just what you need.

Aug 6, 2009 at 5:51 PM

Yep :).

Basically I have presented the client with two different options.  Static enforcement (folders have required SSL encryption) and using the custom 403.4 page approach (I have this working).  OR for dynamic SSL swapping, IONIC and ISAPI.


Quick question for you.  GREAT product by the way.  For the dynamic SSL swapping, can you help me piece together the rules for this:

-If coming from port 80, and page within folder "folder1" or "folder2" redirect to https://......

-If NOT "folder1" or "folder2" and coming from port 443, re-write BACK to standard HTTP.

Make sense? I have a baseline for always redirecting to HTTPs, but I'm running into some issues going back or the other way.  Basically if these two folders and 80, HTTPS, else back to HTTP.

Thanks

Coordinator
Aug 6, 2009 at 7:12 PM

Yes, I think this should work:

#  if coming from port 80, and page within folder "folder1" or "folder2" redirect to https://......
# This rule uses a choice: (a|b).  The replacement uses $0, which means "the entire incoming URL", 
# including the folder name. 
RewriteCond %{SERVER_PORT} ^80$
RedirectRule ^/(folder1|folder2)/(.*)$        https://development.pia.com/$0 

# If NOT "folder1" or "folder2" and coming from port 443, re-write BACK to standard HTTP.
# This uses a negative-lookahead (?!foo).  
RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/(?!(folder1|folder2))([^/]+)/(.*)$        http://development.pia.com/$0 

With the latest build, you don't need the [R] at the end.

Test carefully.

Aug 6, 2009 at 9:56 PM

Cheeso:

Thanks! But I am seeing something, very, very bizarre.  Here is the current ini (and I did get the newest version)

RewriteLog  c:\temp\Log.out
RewriteLogLevel 3
RewriteFilterPriority HIGH
IterationLimit 2
MaxMatchCount 4

RewriteCond %{SERVER_PORT} ^80$
RedirectRule ^/buynow/f1/(Cart|Security)/(.*)$   https://development.pia.com$0 [I]

RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/buynow/f1/(?!(Cart|Security))([^/]+)/(.*)$  http://development.pia.com$0 [I]

I am using [I] for case insensitive searching, and the full urls are (obviously) http://development.pia.com/buynow/f1/Cart, etc, I realize /buynow/f1 can be handled as a cleaner expression (2 folders before condition) but I doubt that has to do with the problem.  The folders will change when we go to production but thats not relevant

It works great besides one thing.  And I cleared all my temporary files and cache to verify I wasn't going crazy but here is what is happening

FireFox: works great

IE: as you swap between, HTTP pages show the graphics fine, when you swap to HTTPS (the Cart and Security folder) the images do not render.  This is baffling me :(.  All images are relative urls and the browser is literally now not finding them, I'm at a loss.  All images are stored in the standard App Themes/Images folder.

I have checked over and over to validate its not consistent, but only IE, when swapping seems to lose the ability to show the images in HTTPS mode.

Any ideas?  Using my old clunky method (shown the second thread) when I went to HTTPS I know I didn't lose the images, now its almost like it gets crossed up and can't resolve the images folder...

Thoughts?

Aug 6, 2009 at 10:08 PM
Edited Aug 6, 2009 at 10:08 PM

OK, another tid-bit of information, off localhost, the problem occurs less frequently (which is fine, off local host makes no difference to me).  And it appears, if you refresh the page (F5) the image will appear.  But even off the server it seems to happen. Before I started using the ISAPI approach this didn't happen.  Bizarre....

Thanks for any feedback or ideas.

Coordinator
Aug 6, 2009 at 10:20 PM

I suspect it is something having to do with "Mixed Content". 

http://www.bing.com/search?q=IE+"mixed+content"&FORM=QBHP

http://blogs.msdn.com/askie/archive/2009/05/14/mixed-content-and-internet-explorer-8-0.aspx

I understand you said all your images and themes are relative URLs.

To troubleshoot this, I would look into the IIRF log for the requests for images, and the result of those requests (rewrite, no rewrite).  Also, connect a debugging HTTP proxy to IE, something like Fiddler2, and you will very clearly be able to see each HTTP GET that goes out of your browser, and the response it receives.

 

Aug 6, 2009 at 11:40 PM

Cheeso:

Mmmmmmm...well I'm not sure if that is case and unfortunately if it is, it  has to do with this ISAPI flipping.  End of the day, a relative path that comes from an HTTPS-requested page will use the same protocol.  Therefore when the request comes from port 443, relative urls are also run from the location.  From port 80, they come from port 80.  Use strict SSL (at the folder level) and a custom 403.4 redirect page I do not have this problem. I would assume this is because my custom script in this page makes a full location replace or redirect, reloading the page in HTTPS.

I know FireFox and IE handle "Mixed" content prompting differently but typically I receive the annoying IE warning about "mixed" content and do I want to continue. I use Fiddler all the time and I can look at what happening, but ths must be a direct relation to how we are trying to do this.  The issue is mixed context, at the time of evaluating the request, the request is still in Port 80, which doesn't make a lot of sense, unless the Images are being evaluated first by IIRF, then the page, the page is pushed, but the browser engine (IE in this case) still tries to pull the images from port 80...

Is there a way do an AND OR in IIRF?

If I add this to the condition: RedirectRule ^/buynow/f1/(Cart|Security|App Themes)/(.*)$

and starts working again, not saying it will, this completely puzzles me.

Aug 6, 2009 at 11:59 PM

Cheeso:

Thanks for your continued help on this, I think I see it, within the log

Thu Aug 06 19:46:00 -  5016 - EvaluateRules: Rule 1 : -1 (No match)
Thu Aug 06 19:46:00 -  5016 - EvaluateRules: Rule 2 : 4 matches
Thu Aug 06 19:46:00 -  5016 - EvalCondition: ts1 '443'
Thu Aug 06 19:46:00 -  5016 - ApplyCaseConversion: after  '443'
Thu Aug 06 19:46:00 -  5016 - EvalCondition: checking '443' against pattern '^443$'
Thu Aug 06 19:46:00 -  5016 - EvalCondition: match result: 1 (match)
Thu Aug 06 19:46:00 -  5016 - EvalCondition: returning TRUE
Thu Aug 06 19:46:00 -  5016 - EvalConditionList: rule 2, TRUE, Rule will apply
Thu Aug 06 19:46:00 -  5016 - ApplyCaseConversion: after  'http://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG'

It appears the SECOND rule is running and pushing it BACK to http:

After the first redirect wouldn't it stop running, it appears it flags the two directories, pushes to https but then checks patten 443 and sends the images back again

I notice all this occurs after the SSL Page to be moved is flagged:

Thu Aug 06 19:46:00 -  5016 - DoRewrites: Redirect (code=302) Url to: 'https://development.pia.com/buynow/f1/Cart/MyShoppingCart.aspx'....

Why would this be happening?

Coordinator
Aug 7, 2009 at 12:33 AM
Edited Aug 7, 2009 at 12:36 AM

Well, hard to say.  What does the incoming URL look like?  If it is like this;

https://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG

Then, sure, of course the 2nd rule will match.  It uses port 443, so the RewriteCond returns TRUE.  It has buynow/f1 as the first 2 segments in the URL path.  The next segment is neither Cart nor Security.  Therefore, it gets redirected.  The filter is doing EXACTLY what the rule says to do, which as far as I can tell, is EXACTLY what you described you wanted.

You asked: 'after the first redirect, wouldn't it stop running?"    And I think you mean, for the first request, after RedirectRule #1 matches, won't IIRF stop processing rules?  And the answer is YES, for that request, IIRF will stop processing rules.  But a redirect is a message back to the browser, which usually results in a new request from the browser, to the redirected URL.  In this case the redirected URL (from the first rule) is on the same server, and so IIRF is activated again, with a new URL.  And there's a rule that matches the new URL, rule #2.  And because it matches, IIRF returns a redirect. 

If you think it's the right thing to do, you could exclude JPG and CSS from rule #2.  It would look like this:

RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/buynow/f1/(?!(Cart|Security))([^/]+)/(.*)(?!<(JPG|CSS)$  http://development.pia.com$0 [I]

It uses a negative-lookbehind in the regex to say "anything except an URL that ends in JPG or CSS" (case insensitive). But you have to decide if that's really what you want.

Aug 7, 2009 at 1:01 AM

Thank you Cheeso, I understand now.  Please have some patience with me, I'm knew to IONIC and the regular expression syntax it use.

This is my final question, given your last RedirectRule

RedirectRule ^/buynow/f1/(?!(Cart|Security))([^/]+)/(.*)(?!<(JPG|CSS)$

Does this mean the following:

If port 443 (which means you are only in the Cart and Security sub folders) JPG and CSS will not be re-written to HTTP

ELSE everything, including CSS and JPG will be rendered as HTTP.

End of the day, if I am not in the Cart and Security folders I do not want the CSS and JPG to always pull from HTTPS.  They should only pull from HTTPS if within these sub folders or the request itself is coming from HTTPS.  So when I change pages, all references are back to HTTP.

Is this the case?

Thanks, you are amazing

Coordinator
Aug 7, 2009 at 1:36 AM

OK hang on.  the RedirectRule, by itself, does not specify port 443 or 80 or anything.  The port condition is specified in the attached RewriteCond, which you did not include.  I'm going to assume you are interested in the rule and its condition as I wrote it, like this:

RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/buynow/f1/(?!(Cart|Security))([^/]+)/(.*)(?!<(JPG|CSS)$  http://development.pia.com$0 [I]

ok, now... in English, it says:

  1. if the SERVER_PORT is 443, which implies HTTPS/SSL
  2. and if the URL path starts with /buynow/f1
  3. and if there is another URL path segment and that segment is neither "Cart" nor "Security"  (case-insensitive)
  4. and if the final part of the URL ends in something that is neither JPG nor CSS (Case-insensitive)

...then redirect it to an http address of EXACTLY the same form. 

If the incoming URL does not satisfy any of those conditions, then no redirect happens, with that rule.

Example:  if the URL begins with /specials, then no redirect.  It doesn't satisfy #2. 

If the port is 80, no redirect.  (stipulation #1) .    If the URL path begins: /buynow/f1/Cart , then no redirect (reason #3).  If the URL is 'https://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG', then no redirect (reason #4).

For other URLs you have to test it.  You can reason about it all you want, but you need to test it to be sure.

 

Aug 7, 2009 at 2:00 AM
Edited Aug 7, 2009 at 2:01 AM

"If the incoming URL does not satisfy any of those conditions, then no redirect happens, with that rule."

Got it.  Thanks again.  I'm really not *that* slow just trying to understand the expression. Again, this part:

https:// at the time of the request will dictate where relative urls are resolved (remove IONIC from the equation completely for a second), the rule(s) in turn must be properly configured to not go against this standard.  If the page request was https://development.pia.com/buynow/f1/Cart/APage.aspx relative images, js whatever would not be mixed content at all, they come from HTTPS.  If the page request was http://development.pia.com/buynow/f1/NotSSL/APage2.aspx relative images, js whatever would be resolved from port 80.

Just trying to gage since I was using ISAPI to re-write that I would be doing it properly and not violating this, stepping on myself.

Again, I appreciate your time.

Coordinator
Aug 7, 2009 at 7:02 PM

yes, that all sounds right to me.

 

Aug 8, 2009 at 6:45 PM

Returning to the topic, enable "Require Secure Channel (SSL)" setting when using IIRF for HTTP->HTTPS redirection is not a bad idea, i think. As Cheeso already wrote, we don't really need IIRF if all we are doing is redirecting for SSL. Of course, i mean setup where IIRF also performs many other tasks like HTTPS->HTTP redirection, rewriting urls and so on. Let me explain advantage of this setting.

Clearly, we must restrict access to "secure areas" (or rather sensitive information) over non-secure channel without fail. I think you agree with this. Therefore require SSL in IIS on folder/file level can treat as additional protection and may help in the following situation. For example, we really can make a mistake in the complicated RedirectRule (or/and RewriteCond) expression, uncovered by our test unit (TestDrive). This mistake can lead to lack of redirect and thus become a security threat if we don't use this setting.

Unfortunately, as far as i can understood (i am almost don't know neither C nor ISAPI), currently this setting not applicable due IIRF design. (bits of tech info below) IIRF is doing rewrites on SF_NOTIFY_AUTH_COMPLETE event. But before this event, IIS has already processed metabase properties (including AccessSSLFlags of course) and  block non-secure requests to secured location with 403.4 error. IIRF can't use SF_NOTIFY_PREPROC_HEADERS as "single rewrite event" because at this stage not enough information for evaluate some rules (physical path info, for example). Perhaps, mix of above events can be used as a solution, but i doubt that it is worth the time.

architecture
Aug 8, 2009 at 8:55 PM

Norst:

Thank you for your comments and I do agree with you.  This was basically a test driver or review of the options I was going to have.  I absolutely, positively agree that the 403.4 redirect and letting IIS push this is the better solution for HTTP->HTTPS.  However, the original application deployment "idea" raised focused on "application level", for example ASP.net Master Page handling of when to rewrite to HTTPS and no folder level security settings in IIS at all, just the SSL cert was installed. 

I immediately balked at this configuration because I believe in application transparency and I didn't want any higher level aspect (Java, Cold Fusion, PHP, ASP.net, you name it) checking urls and redirecting to HTTPS.  When a real enterprise level application goes from local development to shared development to production there should be no application level "checks" which push pages to HTTPS.  Either before production hard wire your HTTPS access urls (you will have potentially mulitple copies of your application depending on the architecture and deisgn, test environments should also use test SSL to validate all test cases), use IIS Custom Redirect and let IIS do this for you at the folder level, OR I was investigating the abilities of IIRF to do this swapping, transparent to the application level.

Right now my development server is doing both (custom 403.4 redirect/IIS handling and ISAPI), or I've been swapping between approaches and testing.  After a day or two of playing with IONIC I did get the rewritecond and expressions correct, Cheeso started me off, I got rid of the check for extensions and such, basically following the logic of the standard IIS pipeline, page request, then secondary relative aspects come in, css, jpg, js, etc.  I have tested both (ISAPI swapping and IIS Custom Redirect) and both are working under all use cases I have set forth: (query strings at end of urls, folder names, etc.)

Thanks for your input and I do realize that IIS has already processed the AccessSSLFlags before IIRF kicks in, that was the firs thing I was trying to verify with this thread and it was verified for me.

Thanks for everyone's interest.

Sep 8, 2009 at 1:19 AM
Cheeso wrote:

OK hang on.  the RedirectRule, by itself, does not specify port 443 or 80 or anything.  The port condition is specified in the attached RewriteCond, which you did not include.  I'm going to assume you are interested in the rule and its condition as I wrote it, like this:

RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/buynow/f1/(?!(Cart|Security))([^/]+)/(.*)(?!<(JPG|CSS)$ http://development.pia.com$0 [I]

ok, now... in English, it says:

  1. if the SERVER_PORT is 443, which implies HTTPS/SSL
  2. and if the URL path starts with /buynow/f1
  3. and if there is another URL path segment and that segment is neither "Cart" nor "Security"  (case-insensitive)
  4. and if the final part of the URL ends in something that is neither JPG nor CSS (Case-insensitive)

...then redirect it to an http address of EXACTLY the same form. 

If the incoming URL does not satisfy any of those conditions, then no redirect happens, with that rule.

Example:  if the URL begins with /specials, then no redirect.  It doesn't satisfy #2. 

If the port is 80, no redirect.  (stipulation #1) .    If the URL path begins: /buynow/f1/Cart , then no redirect (reason #3).  If the URL is 'https://development.pia.com/buynow/f1/App_Themes/Images/New_Cart_icon.JPG', then no redirect (reason #4).

For other URLs you have to test it.  You can reason about it all you want, but you need to test it to be sure.

 

I'm using this rule but seems not to function well it does not filter the (.*) everything but (?!<(JPG|CSS) extensions, i have this:

RewriteCond %{SERVER_PORT} ^80$
RedirectRule ^/(priv)/(.*)$        https://www.mysite.com$0 [I]

RewriteCond %{SERVER_PORT} ^443$
RedirectRule ^/(?!(priv))([^/]+)/(.*)(?!<(JPG|PNG|CSS|JS))$  http://www.mysite.com$0 [I]

Where my secure folder is priv, someone has a solution to this mixed content problem?

I've tried several regex's:

^/(?!(priv))([^/]+)/(.*\.(jpg|gif|js))$
^/(?!(priv))([^/]+)/(.*(?<!\.(jpg|gif|js))$

In a regex editor it works but in the ini file reports an error,

Thanks

Coordinator
Sep 8, 2009 at 9:02 AM

Are you going to share the error, or is it a secret?

It's available in the log file.

 

Sep 9, 2009 at 6:20 PM
Edited Sep 9, 2009 at 8:20 PM

Basically the problem is the same the last rule returns to http, when you're not in the ssl folder, now if you're in ssl theres som relative paths included in the folder /include, but the rule only sets https to folder /priv.

In detail when you´re https, and theres a link to include menu.js in the path /include/menu.js, the last rule returns it to http beause it isnt in the priv folder and gives you a mixed content.

Now i want to ignore this include/*.css, *.jpg and *.js when it's on ssl don't change it to regular http.

 

Log:
--------------------------------------------
Mon Sep 07 15:58:01 -  3696 - LogFile re-opened.
Mon Sep 07 15:58:01 -  3696 - AwaitIniChangeAndReinit: Detected change in the  ini file 'C:\WINDOWS\system32\inetsrv\IIRF\IsapiRewrite4.ini'
Mon Sep 07 15:58:01 -  3696 - AwaitIniChangeAndReinit: Ionic ISAPI Rewriting Filter (IIRF) v1.2.16 R7
Mon Sep 07 15:58:01 -  3696 - ReadConfig
Mon Sep 07 15:58:01 -  3696 - LogFile re-opened.
Mon Sep 07 15:58:01 -  3696 - ReadConfig: new log file name: 'C:\Temporales\iirfLog.out.4420.log'
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line 9: RewriteLogLevel 3
Mon Sep 07 15:58:01 -  3696 - ReadConfig: setting LogLevel to 3
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line 13: StatusUrl /iirfStatus
Mon Sep 07 15:58:01 -  3696 - ReadConfig: StatusUrl is enabled for local requests only.
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  16: RewriteRule (rule 1)  '^/gcWsInterfazPub2/(.*)$'  '/gcWsInterfazPub2/$1'    [I,L]
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  19: RewriteRule (rule 2)  '^/NeatUpload/(.*)$'  '/NeatUpload/$1'    [I,L]
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  22: RewriteCond %{HTTP_HOST}                                   ^(?!www\.mysite\.com)                
Mon Sep 07 15:58:01 -  3696 - ParseCondModifierFlags: '[I]'
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  23: RedirectRule (rule 3)  '^(.*)$'  'http://www.mysite.com$1'  [R=301]
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  28: RewriteCond %{SERVER_PORT}                                 ^80$                                      
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  29: RedirectRule (rule 4)  '^/(priv)/(.*)$'  'https://www.mysite.com$0'      [I]
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  33: RewriteCond %{SERVER_PORT}                                 ^443$                                     
Mon Sep 07 15:58:01 -  3696 - ReadConfig: line  34: RedirectRule (rule 5)  '^/(?!(priv))([^/]+)/(.*)(?!<(jpg|gif|png|css|js|bmp))$'  'http://www.mysite.com$0'      [I]
Mon Sep 07 15:58:01 -  3696 - ReadConfig: Done reading, found 5 rules (0 errors, 0 warnings) on 37 lines

--------------------------------------------
Mon Sep 07 15:58:05 -  1584 - DoRewrites: Url: '/include/menu.dom.js'
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: depth=0
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Rule 1 : -1 (No match)
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Rule 2 : -1 (No match)
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Rule 3 : 2 matches
Mon Sep 07 15:58:05 -  1584 - EvalCondition: ts1 'www.mysite.com'
Mon Sep 07 15:58:05 -  1584 - ApplyCaseConversion: after  'www.mysite.com'
Mon Sep 07 15:58:05 -  1584 - EvalCondition: checking 'www.mysite.com' against pattern '^(?!www\.mysite\.com)'
Mon Sep 07 15:58:05 -  1584 - EvalCondition: match result: -1 (No match)
Mon Sep 07 15:58:05 -  1584 - EvalCondition: returning FALSE
Mon Sep 07 15:58:05 -  1584 - EvalConditionList: rule 3, FALSE, Rule does not apply
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Rule 4 : -1 (No match)
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Rule 5 : 4 matches
Mon Sep 07 15:58:05 -  1584 - EvalCondition: ts1 '443'
Mon Sep 07 15:58:05 -  1584 - ApplyCaseConversion: after  '443'
Mon Sep 07 15:58:05 -  1584 - EvalCondition: checking '443' against pattern '^443$'
Mon Sep 07 15:58:05 -  1584 - EvalCondition: match result: 1 (match)
Mon Sep 07 15:58:05 -  1584 - EvalCondition: returning TRUE
Mon Sep 07 15:58:05 -  1584 - EvalConditionList: rule 5, TRUE, Rule will apply
Mon Sep 07 15:58:05 -  1584 - ApplyCaseConversion: after  'http://www.mysite.com/include/menu.dom.js'
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: Result (length 46): http://www.mysite.com/include/menu.dom.js
Mon Sep 07 15:58:05 -  1584 - EvaluateRules: returning 302
Mon Sep 07 15:58:05 -  1584 - DoRewrites: Redirect (code=302) Url to: 'http://www.mysite.com/include/menu.dom.js'
Mon Sep 07 15:58:05 -  3640 - HttpFilterProc: SF_NOTIFY_URL_MAP
Mon Sep 07 15:58:05 -  3640 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE
Mon Sep 07 15:58:05 -  3640 - DoRewrites
Mon Sep 07 15:58:05 -  3640 - DoRewrites: Url: '/include/menu.dom.js'
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: depth=0
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: Rule 1 : -1 (No match)
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: Rule 2 : -1 (No match)
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: Rule 3 : 2 matches
Mon Sep 07 15:58:05 -  3640 - EvalCondition: ts1 'www.mysite.com'
Mon Sep 07 15:58:05 -  3640 - ApplyCaseConversion: after  'www.mysite.com'
Mon Sep 07 15:58:05 -  3640 - EvalCondition: checking 'www.mysite.com' against pattern '^(?!www\.mysite\.com)'
Mon Sep 07 15:58:05 -  3640 - EvalCondition: match result: -1 (No match)
Mon Sep 07 15:58:05 -  3640 - EvalCondition: returning FALSE
Mon Sep 07 15:58:05 -  3640 - EvalConditionList: rule 3, FALSE, Rule does not apply
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: Rule 4 : -1 (No match)
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: Rule 5 : 4 matches
Mon Sep 07 15:58:05 -  3640 - EvalCondition: ts1 '80'
Mon Sep 07 15:58:05 -  3640 - ApplyCaseConversion: after  '80'
Mon Sep 07 15:58:05 -  3640 - EvalCondition: checking '80' against pattern '^443$'
Mon Sep 07 15:58:05 -  3640 - EvalCondition: match result: -1 (No match)
Mon Sep 07 15:58:05 -  3640 - EvalCondition: returning FALSE
Mon Sep 07 15:58:05 -  3640 - EvalConditionList: rule 5, FALSE, Rule does not apply
Mon Sep 07 15:58:05 -  3640 - EvaluateRules: returning 0
Mon Sep 07 15:58:05 -  3640 - DoRewrites: No Rewrite
Mon Sep 07 15:58:05 -  5852 - HttpFilterProc: SF_NOTIFY_URL_MAP
Mon Sep 07 15:58:05 -  5852 - HttpFilterProc: SF_NOTIFY_AUTH_COMPLETE

Thanks for your support.

 

Coordinator
Sep 10, 2009 at 4:22 AM

I'm not able to understand what you are saying.  I can read the words, but I don't understand what you mean.

I think you are lacking some punctuation.   It would be helpful if you gave me some examples, instead of the description, or in addition to the description.

What does it mean when you say: "the problem is the same the last rule returns to http, when you're not in the ssl folder,"   Can you give me an example of that?  What URL do you send in, and what URL do you get out?  And what do you expect to get out, and how are the two different ?  IF you can be vevry explicit with me, I'm sure I'll understand better.

I have the same questions around this statement:  "now if you're in ssl theres som relative paths included in the folder /include, but the rule only sets https to folder /priv."   I think that is a separate statement, but I'm not sure because it was attached to the prior statement.  But here again, if it is a separate observation, you need to give me a concrete example:  what URL do you send in, what results do you see, what results do you expect, and how do they differ?

 

Sep 10, 2009 at 11:53 AM

"Now i want to ignore this include/*.css, *.jpg and *.js when it's on ssl don't change it to regular http."

I think you are confusing a few things.  End of the day, are you swapping between https and http for all pages, certain folders, etc? I think the dicussion we had earlier in this thread where we talked about whether to use rewrite at all, or just IE SSL enforcement is good to review again.

You need to look at this as where is the parent request coming from - - port 443 or port 80. In theory, if you have developed with relative urls you should NEVER been trying to swap your images, javascript or anything of the like in the first place.

-MyRandomPage.Aspx - Top Request

  -favicon.ico -  - subsequent request

  -folder\TheScript.js - - subsequent request

  -MyImage.jpeg - - subsequent request

And all other components until everything on "MyRandomPage.aspx" is completed.

Therefore you want to check first what port you are coming from.  Then if within some folder (if you have that condition) and request file name  ends with /or file extension ends with (x) but also optionally contains query strings redirect.  Where (x) in this case is .html, .aspx whatever.  Now all subsequent requests after (your icos, scripts within that page) are already being pushed through the 443 port, so you don't do anything with them.  To go back to HTTP its again similar but now your check is if PORT 443.  You need to get the top of the request chain and swap, from there, all the subsequent requests are already on port 80 or port 443

I have used IONIC IIRF for swapping between SSL and port 80 for specific folders and I'm also using the IE Enforcement approach. Either should work for you, just re-evaluate what you are trying to do.

Hope it helps