An xml-file is loaded from a different domain within an iframe in a Webkit/Chrome browser and the HTTP Content-Type is set to application/xml.
Generally xml would be colored and pretty-printed, using a built-in browser content-script. In the iframe, the same xml-file will only show the text within the tags and no colored outline, as would be expected with browser-scripts turned off.
Browser:
Iframe:
(different content)
Response headers:
HTTP/1.1 200 OK
Date: Thu, 29 Aug 2013 08:52:55 GMT
Server: Apache
Vary: Cookie
Content-Length: 154
Keep-Alive: timeout=15, max=10000
Connection: Keep-Alive
Content-Type: application/xml
Adding Access-Control-Allow-Origin:* to the response-header didn't change anything.
Update: HTML:
<form id="api_output" target="iframepostform" action="https://example.com/api/"
method="POST" accept-charset="utf-8">....
<button type="submit">Send</button>
</form>
<iframe class="clearfix" src="" name="iframepostform"
id="iframepostform" seamless="seamless"></iframe>
What is the simplest solution to fix this, without abandoning iframes and resorting to XHR requests?
Use Yahoo Pipes or YQL as a proxy formatter service. Here are some examples:
How to get the formatted view of YQL as result?
Yahoo Pipes to enrich RSS descriptions dynamically with ${title} variable?
Related
I have seen links when clicked tel:+1123456789 will invoke a call over phone/computer
I have come across some links like
https://ctrlq.org/call/9876543210
when clicked it will directly invoke make a call without even opening a page.
How is that possible?
PLease note that there is no manual hyperlink clicking involved
Examining the header response for the link you shared there is a 302 redirect with a new location tel:9876543210 which is prompting the browser to call the number.
HTTP/1.1 302 Moved Temporarily
Date: Tue, 06 Oct 2020 15:42:10 GMT
Server: Apache
Location: tel:9876543210
Cache-Control: max-age=600
Expires: Tue, 06 Oct 2020 15:52:10 GMT
Vary: User-Agent,Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8
If you are running an Apache server you can consult the Apache .htaccess Tutorial and the Apache URL Rewriting Guide. If your site is hosted on a server running other software, check with your hoster for more details.
Browser based solutions also exist for setting up redirects, some of which are covered in this post.
From #mhawksey s answer I could do this and it will successfully redirect
Use this link for passing number: https://yoursite.com/redirect.htm?tel=+1234567890
Upload this file to your drive root.
<!DOCTYPE html>
<html>
<head>
<base target="_top">
</head>
<body onload='window.location = "tel:" + new URL(window.location.href).searchParams.get("tel");'>
</body>
</html>
I don't really understand what you mean by no manual hyperlink clicking. But if u need a link that could invoke making a call, u can use anchor tag with tel attribute.
Call 987654321
In a project, client-side in the browser, i dynamically create an <img>-tag and set the source to an image. It is served from apache2 on the host.
The user can then make changes and i sometimes need to reload the image (as the source on the server has changed). I do that by changing the src-attribute to the new image.
The problem is, the old (first) image remains in the cache and no further changes are ever reflected.
I did of course try to prevent caching by the regular means:
I change the URL of the source image on every reload, by adding a parameter to the url and setting its value to the current time. I checked to confirm and yes, every load actually requests a different URL from the server, but the image is still served as a cached version.
I'm returning a variety of headers to prevent caching. Here is what the response headers look like:
Access-Control-Allow-Headers: origin, x-requested-with, content-type
Access-Control-Allow-Methods: PUT, GET, POST, DELETE, OPTIONS
Cache-control: no-cache, no-store, must-revalidate
Connection: Keep-Alive
Content-Length: 48503
Content-Type: image/png
Date: Wed, 05 Sep 2018 15:51:08 GMT
Expires: 0
Keep-Alive: timeout=5, max=100
Pragma: no-cache
Server: Apache/2.4.25 (Debian)
Set-Cookie: locale=de; Domain=c.test; Path=/; Expires=Mon, 04 Mar 2019 15:51:08 GMT
Set-Cookie: session_id=563bbb7d216d4edf7aed7e38427e15aec584414a605df6d2481223f840bf13f7; Domain=c.test; Path=/
A requested URL looks like this:
/event/590c713b5fd3197a0a16c851/reg/data/streamThumbnail?file=93c180702fd9926d40f77dd19ae48cee.crop.jpg&t=0478533001536162394&dimensions=130x181
Unfortunately i am out of options. I tried debugging this by loading the image src directly in a new tab, making changes on the server and then reloading, but the image remains the same, even though it doesn't exist on the server anymore at all.
Can anyone point me in the right direction here? Does anyone know what is going on or what i've been missing?
I'm sorry i cannot provide any testing outlet for this, so i guess this one's up to the ones who have encountered this problem themselves.
Thank you.
Tried this? Should work in both .htaccess, httpd.conf and in a VirtualHost
<filesMatch "\.(html|htm|js|css)$">
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>
</filesMatch>
And optionally add the extension for the template files you are retrieving if you are using an extension other than .html for those.
You can do this easily client side, with adding a url query. i.e.
<img src="folder/my-image.jpg?cache=1">
Every time you want to refresh the image, increase the number on your cache variable. i.e. make it ?cache=2. A lot of people will use a date/time variable in this field to never allow caching.
EDIT:
Okay, sorry, just realized you tried this. Another option is to use data-uri's. If you have the ability to read the image as source, you can use a data-uri in the image tag as a base64 hex string:
<img src="data:image/gif;base64,R0lGODdhnQAmAPcAAM3OzpKTlP759P3u4va3hvawe/Wpbr/AwPjGoPrYvvKSSPKQRfzo2P/+/frWu/KNQD5AQm5wcSwuMYWGiI+Qkvayf/3x5/OWT/OUS/vfyfnPrv/8+fa2hPKPQ/nOrP///zw+QF5gYjg6PfKPRPzr3jo8PvSdWvaueJGSlGlrbbi5uva0gtzc3aioqe3u7uPk5MDBwr2+v7m6uvrUtfOaVv769vSeXvrRsvz9/dLT1O7u71ZYWk9RVPe+k/707PKRR/WmavWrcfe7jKCiooSFh/rVuP/9++rq6/nNqve6inJzdVtcX/rUtykrLkVGSfHx8fvawvn5+pGSk9XV15ucnoqLjPWnbPvcxL6/wHR1d1hZXH+Bg8bHyFBSVNvb3IaHiYyNjm1ucISGh8PExf3+/rS2tn6AgWxub4KEhczNzdfY2LCxslJUViYoKjY4OoGChPX19Xx+fzk7PjAyNfn6+kNFRyUnKuTk5ZSVlj4/QiQmKUhKTKqrrE5QUpqbnPb39/zj0d3e3peZmvzp2ry9vlhaXGFiZImKjP7483p7fTs9QHV3eUxOUEpMTo2OkEdJS2RmaN7f4M7P0GJkZvKOQfrTteXm5sbHx/zhzZWWmPjIo7O0tTQ2ONna2oeIitDQ0aeoqfa1hPShYv39/icpLO3t7sDBwcrLy7a3uO/w8P37+oyOj/728dDS0jI0Nvf4+CstMJaYmayurra3t3R2d6ytrmJjZcrLzCgqLZmanFpcXcTExa+wsVxeYJ+gouLi4vvgzPnIpNTV1ePj5JWWlzEzNs7Oz4CBgkxNUG5wcvHy8ubn5/rOrvOYU/aud/jEnPrawP7w5v7z676+v9XW156foC8wM5+goeHi4iMmKHN1dkBCRTc5PKOkpXZ4evOUTP7278fIyC8xNCMlKLu8vWBiY8HCw+zs7JydnsTFxqKjpKysrVVXWLq6u8bFxfe4iPOXUK6vsH1/gCosL9vc3ImLjEZHSrKytKChoqmqq9DR0vrXvd/g4KqsrdLS0yZFySH5BAEAAP8ALAAAAACdACYAAAj/AD8IHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHClxAyKSKFOqJDhA1AkcMGPKnEmzps2bOHPq3MmzJ89REw08eIAkCo5RPpMqXcq06VKgEckM+DGUAUykTrNq3crVJlSHDciQGVVkKA04o9J2Xcu27c+HgESR+EAGB4GhJ9Kqdcu3b9uvCy1ceKAgg9hXNoYiwfEBq9/HkJkCVqhqxVBKHsaSGDF0UOTPoHtORigWB4KhD5LQwVHJLNrQsGPLHG1QbF0cCTg/MMCKTqihFT536lZKNs0okbCQw4EKVDfHXGkTJDMDnECYDJqZJQGHxlANUaC7/wU1TpL42Od2jFuPAxl7ttIFkmFAuIcFHHWfiBpaePOD4EfhFMIbTnUzjj7nhTZKIuutFwUPDibYVHxiJYEaJRyQAFMNlimmgSbh6XUTN5NIqNMo5JlnXEyKjKNHJ+H1wZ6JT5FGlyo3eIdaEIDUddpQwNBBhnx7zTSKCJDQmJOBCOb0hw5KpQLHTkeOw01aH0A4TngyvVLchAeJRdcHMDmwH2pAQEMHNCP08IptYo5CjhI7TCLPGEeJwAM55KgxCjaHKJECGjDIFMUmcaSwxS1HpRjTFN7EIxM5WnKyhTJRcDOOBK/EtM162LyCQovj2JNPTJoiE4sTesgRBxya6v/RhyGjyDhOgDiEs4Md48zhTXGf6qEMTGqsN8VRyvC6DVKjDeksmXXRkYFQqNnAhCWqMAbnKPWM88gW3jRihyQ4aFpqKbfMQ6IS7nmD1B8hjMOJFpqiMIqB5OKgTzFaKIPVJg02uMQoE6ynAlJTrKcFDmEEvJ4jMJkb8A7KyNHglVpyyQWvATcSxRfrkYMUBQ8PGcN6XzBbkJhkCIAJIjPRwYAzF94H55BH2OFJgKMMk5YIKUgCpTKHTHnUIePcMgoFdpxKpiMHOypJMTughRSs45CCQj7ujXNPseMoMfJ6oKSzXi9ccLGEi5GMYm4emXjTb5USkGNOrRHi8IiLh9T/osV6VNyyHhpI2bOeE2IVPA4XV01Hl1jAmFWBJhn4QMflJBDQAQEwsUxXDuOUMRZ03CQC1JB60YXNOCj84ateWKJYXhrWaPHaUQCPEwdSnaw3sHucjrJH1so0jMsTaenAKwVVjnMHUnQIJIKVUNl6lODjJElGKbw6gUMx4+yBA9jrqUFGI+MUYxSW8j1Lhgeoxd+MM89Ac84T9+Hn7JB/cNLHNKnYy5FMNyaklOIIy0gYBbgwDkIQRC8GyoUExiEIAYJhPajAiqaKMQoqhCwS60kGDvIwDjeg4IQoAB8kPjA9bhwFdtMTQWPwtqVR4GM9vmgMGbqwnlcsYj1HIJkc/1pEgVKsZxH4Yd+QsMFEsTjACvCInxQJAw4cMBEbN7uErSSgBTz8oVwEJAMcEgELhzmCHOPwB+xmSJ5x7CAE82gbVpA2jhhghYTF+EDOwpaL9cBgFJxwWINK1ELxaEoEWOnaUXyxnnxAhQ3r+YMK1nMPJ4zjCyBzQhkwCBjbjOGTpbkcHBgwg2esQBQKiN8XPzkG2wykActwRy3i0IQwDPB0DPJDJ5axjECM44wHAkrqZEexX8wjBLDzRMj0Ysk5NAYS47CGjLhhlEC6wREUwGY21zAKiyFyNi2Mia3CUw2y6QWS44ADHEjhxvVIQhLrgSQp0OLKIX3AHfhsX7RwcP85UQKiEs/AQQPw6Y79laYB8iEZNkp3OlykAHbLGAcFQOhI2KWFPMZISybGUQu95GM9b0jL6sbBg8bkDmX40cU4xGG11H3AYi6ciaZcmBZGRGga63noB0qBCyvBZBINEkEU6ECqcdDqcc+6Zz7JgICmOvWpCHhGU/GDz10k9QgIbUBYUDAONcghC7aRQApeKCeJkoEHfQjRKM6RFnylJQr24MQ5BFKKJowDF5mohZZ8kZZXWKNBfiJDP0I4jCeEQwt3q1JMY6LYmBRiPbnIwR/c8LB4rO2SjWrQFvCDhgaBQpgDsSdBxTLF0j5ASLtwxy7GRIY0NCEOpgjEKagwDy3/jCIFnCDHET6wCD0EIG34oCwFyCC4XkyDBfdQxO7Io48ZCk5sGhVkHf6gFwaNAxlHIRM6A0YKFjRWpj5Ny0cbNAo+CJITOhhLRNfDqNY2yBLsk49A8NlKMph2iqh1xxge9wFVgAIC2VhPE2iRig8Eog7jkGEqoLmeYnB1uGSQQQka1AgvyA5BevHGOGBwnVzYdT08wAbsjAG4tKg3BQHjxD1+5lNwhhcpnujprUaRj7+uxx5TON0oIMSJ1dRletgV0enmm1q6RPUZSE6ykpGc3/o6S6su6MQv6NAAE9MhENQQyCiU4YVhDHUZyrAnHVjgjmGQ1aKwe+EH/pCDdNwB/z8zTMsdlrG+gYyiFJIwRyTUisAj0KTPs4kCL/XyCjWYw8xYGpIOlpFeMS06FVdpnD13QWnb8LOfmO5n51K7WvmEpQFGCDVCHbfG2qAuzmiOnUVnI8w0q7kxNEm1kQSo41Sv8WauROrosussgmLjF1fkxxWHzUR+CJvT8jFCAwT6Sq1qVSy2XiNooz3MIjG21WmOXU1sfZNEa9nWSdUnUu3Ma7HsYgypVe25WcnudlNatXT59OPwM2q6KBuhtm5MnFEd7TjPmt+r3ra0rc3qAp7ZpfbUNZyIxCwxKZXS6SaoxCdeVf2GxQhkQOiQtCqQZxeQ2rEDeL5FdG2R0wjN/qmOda0PDrubKXzcKnscsYuNDWHbvOY4F/YVWRvvD2R11BqvMrX1jW2QY7vk0e42yklecNSxvJO4xrVaTufyqFs96mTKqs+37mxnm3zpRq82VlTNbYGDXTyJnvrQScMyveCa5/Vkmdzr6fWMa73e3wZ53sNOdjWD3Oxnbzqs+830krM20Quv+tzHLd+E293nWrcz3ydvUX5/vfBXIXyR0s4szaOd6mP6QEAAADs=">
I believe there's a size limit on some older versions of Internet Explorer.
EDIT 2:
If you are truly looking for a HTTP HEADER option, did you also try the "Expires" value. If I recall, you have to use a negative value, i.e. Expires: -1. There's also a few other cache controls you can play with, like Cache-Control: max-age=0 or Cache-Control: must-revalidate.
EDIT 3:
Ok, you did try the Expires as well, BUT you are using ZERO. You need to change this to -1. Full explanation here:
HTTP Expires header values "0" and "-1"
When we log in google. It set cookies for both Google and youtube domain.
In the network, I see two interesting get call,
https://mail.google.com/accounts/SetOSID?authuser
https://accounts.youtube.com/accounts/SetSID.
How can I achieve the same results?
I have to set a cookie for a website like youtube.com from a website like google.com.
I tried making a XMLHttpRequest(). It didn't work. But If I open my second domain in a separate tab, It set the cookie for the second domain.
My request header :
Request URL: https://mysite.ngrok.io/SetSID?params=xyz
Request Method: GET
Status Code: 302 Found
Remote Address: xx.xx.xxx.xxx:xxx
Referrer Policy: no-referrer-when-downgrade
My Response Header :
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Origin: *
Content-Length: 184
Content-Type: text/plain; charset=utf-8
Date: Wed, 09 May 2018 16:29:34 GMT
Location: https://mysite.ngrok.io/SetSID/callback?params=xyz
set-cookie: _cookie=sample; Path=/; HttpOnly
Vary: Accept
X-Powered-By: Express
If we inspect the console, the request type is binary.
Did it somehow help them achieve the current goal ?
This API is hit
https://myaccount.google.com/accounts/SetOSID?authuser=1&continue=https%3A%2F%2Faccounts.youtube.com%2Faccounts%2FSetSID
followed by the api
https://accounts.youtube.com/accounts/SetSID?ssdc=1&sidt=xxx&continue=https://mail.google.com/mail/u//?authuser
If I am not wrong, Google is loading the https://accounts.youtube.com in a split second and setting up the cookies. It then continue to mail.google.com. (see the params in continue)
I am actually getting an Ajax Response Text from a PHP Server. Suppose the response text comprises of 20 characters.
(e.g. echo "asdhfgyd dhrjtjsjtjr";)
This equals roughly (20/1024) KB.
I'm using a mobile web application to get this reponse text using standard Ajax XMLHttpRequest. However when i measure the data usage by the mobile app due to only that one single ajax response text, it uses nearly 3 KB. This is what i'm not understanding, what is causing this additional data usage, can you please help me out on this.
Additionaly: I confirm that this is the only part of the app that makes internet usage, the others are offline features.
The data you see in the response text is only the body of the response. The other bytes will most likely have been taken up by the headers.
For example here is a response I would expect to receive when calling an API:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?XFxwc2ZcSG9tZVxEb2N1bWVudHNcR2l0SHViXFNvdXJjZVxDaGVyaXNoQXF00XJpc2guQXBpXGFwaVxjaGlsZFxsaXN0?=
X-Powered-By: ASP.NET
Date: Fri, 13 Mar 2015 09:02:35 GMT
Content-Length: 577
[{"result":"FooBar"}]
(Note: This is a follow up to my question Can jQuery.getJSON put a domain's cookies in the header of the request it makes? and covers the XSS case of Setting a cookie in an AJAX request?)
I've been told I'm unable to set cookies to be read by other domains that are not subdomains of the current domain using $.cookie(..., ..., {domain: ...}). But in a comment on a response to my last question, #zanlok said "The server's reply, however, can definitely set a cookie" and it got two upvotes.
So I thought I'd try using a service which was created for the explicit purpose of setting cookies called Freebase's "touch" API. The call looks like:
$.getJSON("http://api.sandbox-freebase.com/api/service/touch",
{}, // URL parameters
afterCookieIsSetCallback); // Callback function
Looking in FireBug at the response header it's like this:
Date Wed, 24 Nov 2010 03:35:28 GMT
Server Apache
X-Metaweb-Cost [...]
Etag [...]
Expires Wed, 24 Nov 2010 03:35:29 GMT
Cache-Control no-store
Vary Accept-Encoding
Content-Encoding gzip
Set-Cookie mwLastWriteTime=1290569730|10325_9202a8c04000641f80000000199eff96|sandbox; expires=Thu, 25-Nov-2010 03:35:28 GMT; Path=/
Last-Modified Wed, 24 Nov 2010 03:35:28 GMT
Content-Length 134
Content-Type text/plain; charset=utf-8
X-Cache MISS from cache01.sandbox.sjc1.metaweb.com
Connection keep-alive
X-Metaweb-TID cache;cache01.sandbox.sjc1:8101;2010-11-24T03:35:28Z;0001
So there's definitely a Set-Cookie in there, and the script runs the response handler. Yet the cookie is not present in the request headers for later JSON requests this script makes to .sandbox-freebase.com.
(By contrast, simply typing the touch api URL into the address bar and loading it that way does set the cookie for future requests. That applies even in other tabs.)
This seems to be a deviation from a prior "expected behavior", because there was a toolkit published by MetaWeb circa "2007-2009" which seemed to think such an approach could work:
http://www.google.com/codesearch/p?hl=en#v099O4eZ5cA/trunk/src/freebase/api.js&q=touch%20package:http://mjt%5C.googlecode%5C.com&l=340
Without knowing much about it, I'm wondering if it was a recent change that Firefox adopted and then WebKit followed suit. Perhaps the one mentioned here:
http://trac.webkit.org/browser/trunk/WebCore/xml/XMLHttpRequest.cpp#L856
So is there any canonical documentation on this particular issue?
The AJAX call you are making, is making a request to a domain outside of the domain of the top level url(the url in the address bar). This results in it being a 3rd party cookie, by default Internet explorer won't persist a 3rd party cookie. Meaning that the cookie will come back in the Set-Cookie header on the first request, but subsequent requests that you make to that server will not have that cookie sent in the request.
Like you said, if you go directly to the url in your browser it works. This is because in this case it's a first party cookie.
In order for IE to accept 3rd party cookie's the server that is sending the SET-COOKIE header on it's response, must also have a P3P Policy Header set.
Here is an example, when you navigate to CNN, you will notice one of the requests it makes is to a domain name of b.scorecardresearch.com, scorecardresearch is dropping a tracking cookie, but this cookie is considered a 3rd party cookie. So in order to make it work they had to also in include a p3p header, see headers below:
HTTP/1.1 200 OK
Content-Length: 43
Content-Type: image/gif
Date: Thu, 02 Dec 2010 19:57:16 GMT
Connection: keep-alive
Set-Cookie: UID=133a68a4-63.217.184.91-1288107038; expires=Sat, 01-Dec-2012 19:57:16 GMT; path=/; domain=.scorecardresearch.com
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
Expires: Mon, 01 Jan 1990 00:00:00 GMT
Pragma: no-cache
Cache-Control: private, no-cache, no-cache=Set-Cookie, no-store, proxy-revalidate
Server: CS
If you were to copy this header and add it to the response, you would notice that the cookie's start working,
P3P: policyref="/w3c/p3p.xml", CP="NOI DSP COR NID OUR IND COM STA OTC"
It's best that you craft a P3P header specific for your business, but the above should work for testing purposes.
If I correctly understand you, you are wondering why the server sends Set-Cookie only on the first request. If that is true, then it's by design - take a look here:
http://en.wikipedia.org/wiki/HTTP_cookie
Set-Cookie is like a setter - the server sends it for the browser to cache it locally. It can send every time, but there is no need to do that, so it will send it again only if it needs to change the value stored locally.
Browser, on the other hand, will send Cookie header every time with the contents set by the last issued Set-Cookie from the server.