Attached here with the screenshot and three NetLog dump files.

The file "download error.png" is the screenshot.

The file "chrome-net-export-log (export report to pdf).json" contain the network log for exporting the report to PDF by using the web interface. The export of pdf was successful and Chromium displayed the PDF file.

The file "chrome-net-export-log (refresh pdf report).json" contain the network log which log the network events when I press F5 key on keyboard or click the "refresh" button to refresh the PDF file. I was prompted to resubmit the form. The refresh was success.


The file "chrome-net-export-log (save pdf).json" contain the network log which log the network events when I download or save the pdf file by clicking the download button on chromium's PDF viewer.

Deleted: download error.png 35.5 KB

	download error.png 35.5 KB View Download

Deleted: chrome-net-export-log (export report to pdf).json 189 KB

chrome-net-export-log (export report to pdf).json 189 KB View Download

Deleted: chrome-net-export-log (refresh pdf report).json 223 KB

chrome-net-export-log (refresh pdf report).json 223 KB View Download

Deleted: chrome-net-export-log (save pdf).json 42.9 KB

chrome-net-export-log (save pdf).json 42.9 KB View Download

Copy-pasting the failing log, since there is only one thing there:
2331: URL_REQUEST
https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf
Start Time: 2018-01-29 23:53:09.273

t=0 [st=0] +REQUEST_ALIVE  [dt=3]
            --> priority = "LOWEST"
            --> url = "https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf"
t=0 [st=0]    URL_REQUEST_DELEGATE  [dt=0]
t=0 [st=0]   +URL_REQUEST_START_JOB  [dt=1]
              --> load_flags = 32780 (MAYBE_USER_GESTURE | ONLY_FROM_CACHE | SKIP_CACHE_VALIDATION)
              --> method = "POST"
              --> upload_id = "1517284834931228"
              --> url = "https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf"
t=0 [st=0]      URL_REQUEST_DELEGATE  [dt=0]
t=1 [st=1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=1 [st=1]      HTTP_CACHE_OPEN_ENTRY  [dt=0]
                --> net_error = -2 (ERR_FAILED)
t=1 [st=1]   -URL_REQUEST_START_JOB
              --> net_error = -400 (ERR_CACHE_MISS)
t=1 [st=1]    URL_REQUEST_DELEGATE  [dt=2]
t=3 [st=3] -REQUEST_ALIVE
            --> net_error = -400 (ERR_CACHE_MISS)

So that fails because the entry isn't in the cache, and that button expects it to be.

Now the download and the refresh logs look similar. First the cache portion:
t= 1 [st= 0] +DISK_CACHE_ENTRY_IMPL  [dt=66]
              --> created = true
              --> key = "1517284834931228/https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf"
t=67 [st=66]    ENTRY_DOOM
t=67 [st=66] -DISK_CACHE_ENTRY_IMPL

... So it's creating a cache entry, then deletes it w/o doing anything?
And this is the request, not sure why it doesn't seem to be writing to the cache entry
(or where it dooms it).

t= 0 [st= 0] +REQUEST_ALIVE  [dt=68]
              --> priority = "HIGHEST"
              --> url = "https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf"
t= 0 [st= 0]    URL_REQUEST_DELEGATE  [dt=0]
t= 0 [st= 0]   +URL_REQUEST_START_JOB  [dt=66]
                --> load_flags = 37121 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VALIDATE_CACHE | VERIFY_EV_CERT)
                --> method = "POST"
                --> upload_id = "1517284834931228"
                --> url = "https://localhost:8443/jasperserver/flow.html/flowFile/TEST_REPORT.pdf"
t= 0 [st= 0]      URL_REQUEST_DELEGATE  [dt=0]
t= 0 [st= 0]      HTTP_CACHE_GET_BACKEND  [dt=0]
t= 0 [st= 0]      HTTP_CACHE_OPEN_ENTRY  [dt=1]
                  --> net_error = -2 (ERR_FAILED)
t= 1 [st= 1]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t= 1 [st= 1]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t= 1 [st= 1]     +HTTP_STREAM_REQUEST  [dt=0]
t= 1 [st= 1]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                    --> source_dependency = 2043 (HTTP_STREAM_JOB_CONTROLLER)
t= 1 [st= 1]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                    --> source_dependency = 2044 (HTTP_STREAM_JOB)
t= 1 [st= 1]     -HTTP_STREAM_REQUEST
t= 1 [st= 1]      UPLOAD_DATA_STREAM_INIT  [dt=0]
                  --> is_chunked = false
                  --> net_error = 0 (?)
                  --> total_size = 105
t= 1 [st= 1]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t= 1 [st= 1]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                    --> POST /jasperserver/flow.html/flowFile/TEST_REPORT.pdf HTTP/1.1
                        Host: localhost:8443
                        Connection: keep-alive
                        Content-Length: 105
                        Cache-Control: max-age=0
                        Origin: https://localhost:8443
                        Upgrade-Insecure-Requests: 1
                        Content-Type: application/x-www-form-urlencoded
                        User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3335.0 Safari/537.36
                        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                        Referer: https://localhost:8443/jasperserver/flow.html?_flowId=viewReportFlow&_flowId=viewReportFlow&ParentFolderUri=%2FTesting&reportUnit=%2FTesting%2FTEST_REPORT&standAlone=true
                        Accept-Encoding: gzip, deflate, br
                        Accept-Language: en-US,en;q=0.9
                        Cookie: [90 bytes were stripped]
t= 1 [st= 1]        UPLOAD_DATA_STREAM_READ  [dt=0]
                    --> current_position = 0
t= 1 [st= 1]        HTTP_TRANSACTION_SEND_REQUEST_BODY
                    --> did_merge = true
                    --> is_chunked = false
                    --> length = 105
t= 1 [st= 1]     -HTTP_TRANSACTION_SEND_REQUEST
t= 2 [st= 2]     +HTTP_TRANSACTION_READ_HEADERS  [dt=64]
t= 2 [st= 2]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=64]
t=66 [st=66]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                    --> HTTP/1.1 200
                        P3P: CP="ALL"
                        Pragma: 
                        Expires: Thu, 01 Jan 1970 00:00:00 GMT
                        Cache-Control: private
                        Content-Disposition: inline; filename="TEST_REPORT.pdf"
                        Content-Type: application/pdf
                        Content-Length: 1343
                        Date: Tue, 30 Jan 2018 04:49:48 GMT
t=66 [st=66]     -HTTP_TRANSACTION_READ_HEADERS
t=66 [st=66]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=66 [st=66]      URL_REQUEST_DELEGATE  [dt=0]
t=66 [st=66]   -URL_REQUEST_START_JOB
t=66 [st=66]    URL_REQUEST_DELEGATE  [dt=2]
t=68 [st=68]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=68 [st=68]    URL_REQUEST_JOB_FILTERED_BYTES_READ
                --> byte_count = 1343
t=68 [st=68]    HTTP_TRANSACTION_READ_BODY  [dt=0]
t=68 [st=68] -REQUEST_ALIVE

Ahh, of course:
t=3 [st=0] +SOCKET_POOL_CONNECT_JOB  [dt=3]
            --> group_name = "ssl/localhost:8443"
t=3 [st=0]   +SOCKET_POOL_CONNECT_JOB_CONNECT  [dt=3]
t=3 [st=0]      TCP_CLIENT_SOCKET_POOL_REQUESTED_SOCKET
                --> host_and_port = "localhost:8443"
t=3 [st=0]     +SOCKET_POOL  [dt=0]
t=3 [st=0]        SOCKET_POOL_BOUND_TO_CONNECT_JOB
                  --> source_dependency = 2185 (TRANSPORT_CONNECT_JOB)
t=3 [st=0]        SOCKET_POOL_BOUND_TO_SOCKET
                  --> source_dependency = 2186 (SOCKET)
t=3 [st=0]     -SOCKET_POOL
t=6 [st=3]      CONNECT_JOB_SET_SOCKET
                --> source_dependency = 2186 (SOCKET)
t=6 [st=3]   -SOCKET_POOL_CONNECT_JOB_CONNECT
              --> net_error = -200 (ERR_CERT_COMMON_NAME_INVALID)
t=6 [st=3] -SOCKET_POOL_CONNECT_JOB

I think this has a certificate error, so there is no caching happening. I think from network layer PoV that's desired, 
but maybe PDF viewer should behave differently?

Lei, do you know if this is the expected behavior? Maybe it's just a matter of failing more gracefully here.

Judging from the screenshot, the user already clicked through the certificate error. We do indeed not caching anything on a certificate error (otherwise later loads of the resource would think the certificate was fine).

I gather this feature of the PDF viewer depends on loading things from the cache, and doesn't work well when the resource isn't in the cache for whatever reason.

I'm not sure what the right thing to do in response to this is. My gut feeling is that the PDF viewer probably should not be as sensitive to the disk cache, since there are lots of reasons why the resource may not be in the cache---perhaps it was Cache-Control: no-store, or perhaps the resource had since been evicted.

PDF folks, what kinds of things would go wrong if this feature used SKIP_CACHE_VALIDATION, but not ONLY_FROM_CACHE, so that we'd still redownload from the network if necessary?

This may be a naive question, but if the PDF viewer is currently showing the PDF,  doesn't it already have the PDF data and could just save that? Does it parse it into some internal format and discard the original?

The SSL error is due to domain name. A few employees who are authorized to access the JasperReports Server from remote location will use a domain name to connect to the server. The domain name resolve to our WAN ip address assigned by Internet Service Provider. All other employees who are authorized to access the server from the same internal network as server will use the server's internal LAN IP address to connect to the server.

Many SSL certificate authorities will only issue trusted SSL certificate for public domain name. They will not issue trusted SSL certificate for IP address. Employees who access the application server from internal network by using server's IP address will see the SSL certificate error.

In Mozilla Firefox, we can download the PDF file without any issue.

We hope the issue of cannot save or download the PDF file will be solved, even though there is an SSL certificate error.

re: comment 9 - Yes, the PDF plugin has a copy of the original PDF. There are several PDF saving bugs so this is definitely on my mind. Should I just merge this into an existing PDF saving bug then?

@thestig: As of now we don't have JasperReports Server setup to test and confirm this. [RE c#11] Could you please let us know if this issue requires bisect from TE end? 

Thanks!

You can probably got the same effect by just serving a PDF file with Cache-Control: nostore, as comment #8 pointed out.

(Removing Needs-Bisect and Needs-Feedback. I think we understand what's going on in this bug?)

re: comment 11: If there is already a bug about saving non-cacheable pdfs, merging it sounds reasonable to me.

Same. Although I am curious whether removing ONLY_FROM_CACHE would work. That might be an easier fix, depending on how annoying it is to recover the PDF from the plugin.

My bad, I am so sorry, when I say "This issue never occur on earlier version of Google Chrome", I forgot that previously I was not using HTTPS/SSL to browse the website. You can change the bug type if you want.

But, I still wish that this issue will be fixed. Thank you very much!

Could someone from Internals>Network>Cache team please have a look at this issue.

Thanks!

I do not believe this requires action from the Cache folks.

As this issue is not reproducible from TE end, could someone from dev team please have a look at that. Hence adding TE-NeedsTriageHelp 

Thanks!

sc00335628: We already know what's going on with this bug. There is no need.

(Also flipping from Bug-Regression to just Bug per comment #18.)

This bug still exist in Google Chrome version 68.0.3440.106.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.