Purge Single URL doesn't work

[Yerri Naidu Pasela]

I am running this curl command line on my dev server. i did change a color property in css file and tried purging this css using
curl --request PURGE"http://10.28.8.000/preview/69580/58612/1036/index.htm/mediahandler/mediakit/79026/DefaultT1T2/style.css" and i got the PURGE successful message. But my changes aren't getting reflected. Any kind of leads would be really helpful.

[Otto van der Schaaf]

Hi, 

To me 10.28.8.000 looks like a weird ip-address/notation. Could that be related?

Otto

[Yerri Naidu Pasela]

Hi,

I have changed the domain name intentionally for security reasons, that's the reason why it looks weird. My issue here is, i was not able to purge the individual URL, where as entire cache purge is working fine on Admin site GUI as well as bu running curl command line. I have no clue where what i am missing :(

[Otto van der Schaaf]

So one thing that strikes me is that the url involves casing. Let me double check we ignore casing in places relevant to this issue.

Meantime, can you try if an all lowercase test does actually work as expected to rule out system specific issues?

Otto

[Otto van der Schaaf]

I tried, but I haven't been able to reproduce a problem yet with purging using curl..

(Please note that case sensitivity is important, it should match the way the css file is referenced)

Not sure if it is helpful, but the module is able to directly load static files from disk:

https://www.modpagespeed.com/doc/domains#ModPagespeedLoadFromFile

With that it will immediately reflects changes to files.

Otto

 

[Saumin Patel]

Thanks, Otto!
We have made sure that proper casing is in place. However, it is not working. To confirm, we are purging the actual file and not the rewritten (or new) URL that IISpeed has.

Also, we are not able to use LoadFromFile as these files are stored in DB and not on the file system.

Please let us know.

Thanks!
Saumin

[Otto van der Schaaf]

Hi Saumin,

I'm still a bit puzzled, but one other thing popped up:

Is there any url rewriting going on before the urls for static files

are mapped to the database?

If so, could it be that that happens before the pagespeed module runs?

That could explain it, because then you would have to either move

the pagespeed module to run in front, or purge a different url (the one

the pagespeed module observes).

Otto

[Yerri Naidu Pasela]

Hi Otto,

      Yes you are right, we are doing Url rewriting. We tested purging on a test application(No url rewriting) where it is working fine. As suggested by you we are running pagespeed module before the rewrite module, but still there is no luck. Could you please suggest what would be the next resort in order to get this working. 

  Thanks,

   Yerri 

[Otto van der Schaaf]

Copying my earlier reply  from a 1:1 conversation in this thread with Saumin:

It would probably be best to run pagespeed post url-rewrite.
(The module makes a lot of efforts to be the first module to see the pristine / unmodified url, but it is possible that another module
beats it to that and changes it if module ordering is an issue. It's never come up as an issue before though).

Having said that, the url that should be purged is the url that pagespeed "observes" as it comes in on the webserver.
It's not possible for me to figure out what that looks like from here, and looking at the output of the server will not help
either.

Capturing a trace with DebugView may also be helpful, to see what the world looks like from pagespeed's perspective:
https://www.iiswebspeed.com/documentation/diagnostics

Otto

[Yerri Naidu Pasela]

Hi Otto,

Thanks for your response. I will send you DebugView results shortly. To add details, we are not using IIS URL Rewrite module, but we are leveraging .net route module (which is part of .net MVC framework). So the pagespeed module does need to be after this. However, once this URL is created by .net route module, it is not changed. So shouldnt be pagespeed caching this URL?
Please let me know.

Thanks!

Yerri

[Yerri Naidu Pasela]

Hi Otto,

Please find the attached Debug view results.

Thanks,

Yerri 

[Otto van der Schaaf]

(Sending again with the proper cc list)

So Is there a mention in the log of a resource that got stale and should be updated?  One observation is that all the references to 

http(s)://10.23.6.113 get permission denied, which very probably means that the html got served from a different domain. Is that as expected? those resources are not even touched by the module in the attached trace. 

Otto

[Saumin Patel]

Hi Otto,
I am not sure why we are getting permission denied as that IP (.113), in fact, does serve the html. So that is not as expected. What could be the reason for this? I did ask Yerri to re run the trace after refreshing the browser couple of times. He will send the results soon on this.
Any other troubleshooting that we can do?

Thanks!
Saumin

[Otto van der Schaaf]

Let's continue figuring this out in the private thread.

Otto

[Yerri Naidu Pasela]

Hi Otto,

I have attached the debug results after refreshing the site for couple of time just to make sure all the resources are getting cached. But i could still see permission denied messages in the log. i am working on to troubleshoot the issue today and try to purge one of the assets and will update you in the private thread. So that i could schedule a meeting with you to resolve this issue.

Thanks,

Yerri