I ran into a really weird issue this morning when trying to access a web app I'm building using an iPad (Safari Mobile/Webkit). On the front end, the web app relies heavily on XHR/Ajax requests. On the back end, the server is configured to gzip compress responses if the "Accept-Encoding" includes "gzip".
Everything was working great until I flipped the server to SSL. Then I started getting intermittent "CFURLErrorDomain:303" errors in Safari.
After a quick search I found this link:
http://beyondrelational.com/modules/2/blogs/45/posts/12034/failed-to-load-resource-safari-issue.aspx
According to the link, Safari requires a content-length header when making XHR (ajax) request over SSL/HTTPS. In my case, the server is gzipping content directly to the output stream so I have no way of knowing what the final content length will be.
As a workaround, I added the following logic on the server:
if (request.isEncrypted()) gzip =
!request.getHeader("User-Agent").toLowerCase().contains("webkit");
In other words, if the connection is encrypted via SSL, and the browser is some webkit derivative (e.g. Safari, Chrome, etc), then don't compress the output. This seems to work but it really slows things down.
So my question is this:
Does Safari support gzip compressed responses over SSL or am I barking up the wrong tree?
Turns out the error I was seeing was a bug in the server and nothing to do with Safari. The server was relying on chunked transfer encoding when compressing large byte arrays. Individual "chunks" were broken up into pieces (header, body, trailer) and sent to the client in separate messages. The SSL client (safari) was expecting one contiguous "chunk" so it didn't know what to do when it saw an incomplete chunk. The server has been patched and the issue is now resolved.
Related
I have a very weird problem with Safari opening my web app.
The setup: I am running an Vuejs application stored in a S3 Bucket on AWS. The app is exposed by an API Gateway.
The Problem: When opening the app only index.html and the favicon are loaded but not the other assets. Sometimes they occur inside the Network tab in dev tools with the message "Failed to load resource" but sometimes not.
"Solution": When I open the app with http (which doesn't work) and then with https again, the resources can be loaded somehow and the app will work fine even when reloading with cache clearing.
Does anyone know how to overcome this problem? 🤷♂️
I have a similar problem (not related to vue.js and amazon, but just to Subject: Safari selectively loads resources):
Mac OS Safari 14 (desktop version, I don't know for a mobile one) doesn't load all referred css, js, and image files.
Safari 13 performed well. Other browsers (Chrome, Firefox) perform well. All files are referred the same way, using relative URLs.
When using Safari 14, some of them are loaded, some are not. Caching is not an issue (I use "empty caches" before loading a page).
It looks like successfully loaded files are randomly chosen (the same file is sometimes loaded, sometimes it isn't).
In the Network tab of Develop menu, for not loaded files Preview says: "An error occurred trying to load the resource",
and in Headers, section "Request", there are only: Accept, Referer, and User-Agent lines, while:
GET, Cookie, Accept-Encoding, Host, Accept-Language, and Connection lines are missing.
Response says: "No response headers".
In the server's access log, there are no lines related to not loaded files.
EDIT:
The cause: TLS 1.0
The solution: TLS 1.2
Problem
Sometimes important HTTP POST requests sent with AJAX got duplicated so several entries of the same data got created in the production database, that is of course not supposed by users.
What is important is that users have a poor internet connection and this request is taking a long time (9-20 seconds). We can't reduce this time because it is the requirements of business logic.
Requests are sent with http, not https.
Details
We have Apache/2.4.18 (Ubuntu) with PHP module loaded and two frontends: one for desktop (AngularJS) and one for mobile (React) devices. AngularJS is sending requests with the $http service, and React is using whatwg-fetch (tried whatwg-fetch-timeout also).
We know from Apache access.log and PHP logs that the same request is coming from the client several times and PHP processes them without the errors. But! These requests have response with 200 status code, %b > 0, and %O = 0, that means request is aborted before a response is sent (Apache logging format docs).
Reproduce
So we tried to reproduce and the same happens sometimes. The following case is just a reproduced case, but this happens on mobile devices (iPhones and Android phones) with different browsers installed. Also, we have repeated it in the Firefox under Windows.
Environment: Windows; both Chrome and Firefox; React frontend version; no proxy used.
That's what we found out: Google Chrome identifies the request as "Stalled", but is internally trying to send the request multiple times (and it is received and processed on the server actually), because it got the network error (ERR_CONNECTION_CLOSED). Only when the browser succeeded to fetch the response, it stops sending the repeating requests.
Gathered info
URL_REQUEST event log from chrome://net-internals/help.html#events (headers are also available there)
Google Chrome dev tools request screenshots:
Headers tab
Timeline tab
I personally can't reproduce this even once and I suppose a good internet connection is a reason for this.
I have googled a lot and even found some similar Chromium bugs, but nothing exactly about this problem.
Thank you in advance for any useful information.
I am also not pretty sure which tags should I set for this question, so if I should add or remove some, please tell me.
Maybe it is a stupid question, but will gzip compression affect my db queries ( i mean, will they be cached) or gzip is related only to html and css output delivered to browser and php stuff will still be efecuted on the server with every page load?
If your using HTTP server compression then as you guessed its a way to optimize transmission from server to client, it (generally) works transparently.
Browser extensions as firebug or monitor tools such as fiddler can help you see whats is really happens behind the scenes.
Okay here is our setup:
Simple form being submitted via AJAX using Prototype 1.7 to a Apache server captured by ColdFusion. (We have noticed similar bugs on pages that submit form data in the conventional way but these pages are used far less.)
Some of our clients are reporting an error. After looking through the logs and doing live testing from their machine Firebug Light is reporting that the request was being sent with the post data.
However on the server side the post data is not present in raw logs or ColdFusion's FORM object or in GetHttpRequestData().
This problem has been isolated to IE only even when running Chrome Frame and is intermittent.
We can not reproduce this error with our IE8 installs on our machines OR on their machines running Firefox or Chrome.
Any thoughts on this extremely difficult bug to track down?
Do you have an HTTP proxy involved in this somewhere? We have had issues in the past, I can't recall the details, but I know that it had something to do with using AJAX to POST. The proxy was configured such that a certain combination of headers would make it misbehave. Take a good look at the HTTP headers coming from the browser, comparing one that works and one that doesn't.
I have a problem with embedding SWFs via SSL.
I know that the common misconception with embedding SWFs on secure pages is that people always try to embed it using a non-secure link. This isn't the case, as I am trying to host the SWF and swfobject.js locally using relative paths to account for the use of SSL.
It appears that the first of these players (under ssl) will play the audio playback, but won't display the video, while the second one will render the entire SWF fine.
Here are 2 examples that are EXTREMELY similiar. Unfortunately I can only post 2 hyperlinks, so you'll have to swap the http: protocol with https: to see how each player renders under SSL.
These 2 players are using 2 different SWF's, so I'm lead to believe it's a Flash/ActionScript issue, but I have failed to isolate it.
Example 1
Non-secure working embed
Example 2
Non-secure working embed
First, Mixed http & https are different domains that run afoul of the Adobe Flash Player's same-domain security restriction. Using a cross-domain file on the root of your server will allow access.
Second, IE has some known problems with SWF and SSL.
Third, be sure to enable https and check to ensure you have a valid root certificate.
Without more information, this is the best I can do.
The best way is to test your work using the Debug Version of Flash Player. This works best in Firefox. Chances are there is something (dependency or resource) that the player is trying to get without SSL.