ipro & https: Cannot fetch url 'https://192.168.185.100/mps/': as https is not supported #799
Comments
Hi oschaaf, your post sounds like you know this problem. We've just built nginx (ver. 1.6) with ngx_pagespeed (ver. 1.9), the pages are https only and when the pagespeed is on the content is not served. Everything is fine when the pagespeed is off. I see the same message as you |
@nataluang At the time I noticed these messages, pages were being served OK (but the log messages made me suspect that in place rewriting was not being executed for https). Are you saying that with https your site is completely broken when To work around, you could try if
|
@oschaaf Yes, the site is completely broken when pagespeed is on. Browser gives me this error "The connection to the server was reset while the page was loading.". Setting the 2014/09/24 11:38:26 [notice] 15361#0: start worker processes I would really appreciate any help or even hint where to look for the problem. |
@nataluang Could you run |
@oschaaf The log with 2014/09/24 12:43:02 [notice] 25610#0: signal 17 (SIGCHLD) received |
@nataluang thanks. the backtrace isn't as helpful as I hoped for, as it mentions addresses instead of function names. It is hard for me to translate those. Could you post the output of this?:
|
@oschaaf Here it is: |
@nataluang Are you actively using SSI includes? The crash path seems to be that the SSI module calls ngx_pagespeed via [1], and subsequently the crasher occurs when It is also worth noting that earlier in the trace the gunzip module seems to be returning [1] https://github.com/nginx/nginx/blob/1fdff008eae31a85e7575079a43f1419aba9ba9b/src/http/modules/ngx_http_ssi_filter_module.c#L408 |
@oschaaf From what I know we did use it (SSI) for something, but unclear if it's still necessary. I'm going to try to rebuild without it and see if that will help. |
@nataluang Sorry - I was more or less thinking aloud. I suspect there's a compatibility problem with one of the modules you are using. SSI / gunzip are candidates, but I can't be sure because of the way nginx works. SSI is suspect because of earlier trouble. Gunzip is suspect because that would potentially be linked to the fact that we gunzip our inputs as well and the involved code is actually mentioned in the backtrace. There's also the sticky module which I've never tested with. |
@oschaaf emailed you my config. |
@oschaaf The ngx_http_ssi_module was not included into the build, so that is confusing as it shouldn't be there. |
@oschaaf I rebuilt nginx without ssi module and without gunzip (I don't think we've been using either). And here is log output: 2014/09/24 17:27:55 [notice] 24276#0: signal 17 (SIGCHLD) received |
@nataluang I've made a first attempt at reproducing, which regrettably failed. I'm going to try again with redhat and gcc 4.1 |
@oschaaf Thank you Otto! I rebuilt with the gcc 4.4.7 and now I don't have the problem anymore. |
I moved the gcc 4.1.2 issue to a separate issue to track it: #813 |
The original issue was that I thought I saw IPRO requests being declined when the configured fetcher didn't support https. After specifically testing that, it looks like I was wrong and things are working fine. Closing this issue. |
I have to double check this, but I'm putting it here so I don't forget to do so. I think I saw in-place rewriting for https pages being declined when the configured http fetcher did not support https.
As the resource has been recordedm instead of having to be fetched via http, I think that shouldn't be a problem.
The text was updated successfully, but these errors were encountered: