Worklight: WL.Client.addGlobalHeader() has no effect - http-headers

When I add the line
WL.Client.addGlobalHeader("MyCustomHeader","abcdefgh");
inside of my main js file like so
function wlCommonInit(){
WL.Client.addGlobalHeader("MyCustomHeader","abcdefgh");
(...)
like it's described in the documentation (http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/topic/com.ibm.worklight.help.doc/apiref/r_wl_client_addglobalheader.html) this has absolutely no effect all request send after that:
GET /apps/services/preview/MobileOPMClient/common/0/default/images/icons/icon_settings.png
HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Accept: image/webp,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/30.0.1599.66 Safari/537.36
Referer: http://localhost:8080/apps/services/preview/MobileOPMClient/common/0/default/MobileOPMClient.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,de;q=0.6
Cookie: JSESSIONID=1e1fig7holfdpeuc46w6jmrph; testcookie=oreo
Why is there no line
MyCustomHeader: abcdefgh
Background: I would like to allow local caching of javascript-files to debug them in chrome.
spyro

Global headers are added for requests made by WL client API, for example WL.Client.connect(), WL.Client.invokeProcedure() etc.

Related

HTTP Caching problem. Request works on and off

I'm facing a weird behaviour on chrome with http get requests that most likely has something to do with cache.
Basically, the same request returns 200 the first time, then if I send the same request again by entering again the URL bar it returns 404. THen again 200. Then 404.
The request looks something like this (by using the dev tools on chrome) I use ## to hide sensitive info
General:
Request URL: ###
Request Method: GET
Status Code: 200 OK
Remote Address: ##############
Referrer Policy: strict-origin-when-cross-origin
Response Headers:
Accept-Ranges: bytes
Cache-Control: max-age=0, no-cache
Content-Length: 75209
Content-Type: application/json
Date: Fri, 10 Sep 2021 10:29:22 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Last-Modified: Wed, 08 Sep 2021 08:36:01 GMT
Server: Jetty(9.4.z-SNAPSHOT)
Request headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Connection: keep-alive
Cookie: ##################
Host: #########
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
If i now press enter in the URL bar issuing the request again i get the following response:
General
Request URL: ####
Request Method: GET
Status Code: 404 Not Found
Remote Address: ######
Referrer Policy: strict-origin-when-cross-origin
Response Headers
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 347
Content-Type: text/html;charset=iso-8859-1
Date: Fri, 10 Sep 2021 10:29:05 GMT
ETag: W/"IDGfBPV6nmAIDGefDH3A0M"
Server: Jetty(9.4.z-SNAPSHOT)
Request Headers
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en,it-IT;q=0.9,it;q=0.8,en-US;q=0.7
Cache-Control: max-age=0
Connection: keep-alive
Cookie: #################
Host: ####
If-Modified-Since: Wed, 08 Sep 2021 08:36:01 GMT
If-None-Match: W/"IDGfBPV6nmAIDGefDH3A0M"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36
And so on, 200, 404, 200, 404 ...
Differences I noticed are in the Cache-Control header of the response and the new If-Modified-Since and If-None-Match request headers.
The backend server is a proprietary server and between the client there is an Apache Proxy Server.
I know that to get the solution I should provide more data (maybe the httpd configuration) but I'm more like trying to understand what the issue is rather than asking for a magic solution.
I searched on google "Get request works on and off" and all sort of wording variations but had no luck.
If anyone could help me out at least understanding the problem
Thanks
Davide
UPDATE
As Kevin suggested in the comment, shutting down the apache proxy did not change this on/off behaviour. Has to be something within the origin server

Amazon s3 bucket, CORS issue, header origin

We are using an Amazon s3 bucket to store our files. On the frontend side, we have to do this one:
fetch('https://some-bucket.s3.eu-central-1.amazonaws.com/some-bucket/4575/some-image.png');
On the amazon s3 bucket configuration, we added cors configuration:
[
{
"AllowedHeaders": [
"*"
],
"AllowedMethods": [
"GET",
"HEAD"
],
"AllowedOrigins": [
"*"
],
"ExposeHeaders": [],
"MaxAgeSeconds": 3000
}
]
The main problem here header origin. In some cases browser set header origin in some cases not.
Here example when all okay:
GET /some-bucket/4016/Elephant_Large_PNG_Clipart-1047.png HTTP/1.1
Host: some-bucket.s3.eu-central-1.amazonaws.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
Accept: application/json, text/plain, */*
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
Origin: https://some-domain.com
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://some-domain.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7,uk;q=0.6
Here is a request which is failed because the origin header is missing.
GET /some-bucket/4608/469705261---Copy.jpeg HTTP/1.1
sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="90", "Google Chrome";v="90"
Accept: application/json, text/plain, /
Referer: https://some-domain.com/
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36
In the amazon docs, we could see - that origin header is required. No origin header, cors issue. Origin header send, cors works well.
We have one more important thing, we are using https://quasar.dev/ on frontend side.
We decided to create plain js without any frontend framework. Just for test. Simple html just with fetch. It works everywhere! It sent header origin.
We tested in:
Firefox - always all okay in all cases.
Chrome - issue exist.
At this point we are using workaround with nginx like a proxy server to amazon s3 bucket, but we would like to use s3 bucket directly.
I am confusing. Please share your thouths, or maybe we are missing something. I will be appreaseate. Thank you!
We resolved the issue, this article helped us. We add this one "?some-parameter=some-unique-text" it resolved problem. Browser cache issue.

UCWA - getting all meetings not just ones you scheduled

I have managed to use the UCWA API for Skype for Business to pull back online meetings, however, this only seems to get information for meetings scheduled by the user themselves. Is there a way to view all scheduled meetings for the user?
This is the request I have been using:
GET /ucwa/oauth/v1/applications/10XXXXXX052/onlineMeetings/myOnlineMeetings HTTP/1.1
Host: lywebext.contoso.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: application/json
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Authorization: Bearer cwt=AAEBHAEFAAAXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXx
Upgrade-Insecure-Requests: 1
I have looked at other endpoints such as onlineMeetingInvitation but none of them seems to give meetings scheduled by other people with the user in question.
Thanks!

Headless chrome does not send Accept-Language header

In testing headless chrome I have noticed that it does not transmit the Accept-Language header entry. I have confirmed that it does get sent when there is a visible browser window.
Is there a reason for this and does chrome have an option to require/force it to send these normal values?
To see this, you can fire up Fiddler and type this at the command line:
chrome --headless --incognito --window-size=1920,1080 --disable-gpu --no-sandbox http://www.daringfireball.net/
In the Fiddler inspector (raw view) you'll see this:
GET https://daringfireball.net/css/ie_sucks HTTP/1.1
Host: daringfireball.net
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) HeadlessChrome/65.0.3325.181 Safari/537.36
Accept: text/css,*/*;q=0.1
Referer: https://daringfireball.net/
Accept-Encoding: gzip, deflate
Whereas running the same command without --headless gives you this:
GET https://daringfireball.net/css/ie_sucks.php HTTP/1.1
Host: daringfireball.net
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Accept: text/css,*/*;q=0.1
Referer: https://daringfireball.net/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
When running headless mode, set the following as an option:
'--lang=en-GB'
It would appear that Accept-Language is a user-profile header sent only when the browser has a confirmed user specifying a language and as headless has no user it can/does not send that header. This was raised in these posts and looks to be a lacking feature for the foreseeable future:
https://github.com/SeleniumHQ/selenium/issues/4437
https://bugs.chromium.org/p/chromedriver/issues/detail?id=1925

POST data not sent in IE 11 using the WebBrowser control

I have the following JavaScript code being executed inside of an onclick event handler on my website.
var newRequest = new window.XMLHttpRequest();
newRequest.open('POST', '/index.cfm', true);
newRequest.send('q');
If I use IE 11 and open up my web page that is located on a testing server I can see that the request gets sent as expected using Fiddler with a content length of 1 and 'q' in the post data. However, if I open up my application that hosts the WebBrowser control and navigate to the same website on my test server and have it execute the above code I can always see that the request is being made but that the Content-Length header is 0 and 'q' is not sent along with the request. Here is the failing request as it appears in Fiddler.
POST http://test.mycompany.com/index.cfm HTTP/1.1
Accept: */*
Referer: http://test.mycompany.com/Curtis/BrowserTests/BrowserEventTests.html
Accept-Language: en-US
Content-Type: text/plain;charset=UTF-8
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: test.mycompany.com
Content-Length: 0
Connection: Keep-Alive
Pragma: no-cache
If I then set the HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION registry value for my executable to 9000 then it works and does send the post data as expected.
Here is the correct request as reported by Fiddler.
POST http://test.mycompany.com/index.cfm HTTP/1.1
Accept: */*
Referer: http://test.mycompany.com/Curtis/BrowserTests/BrowserEventTests.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: test.mycompany.com
Content-Length: 1
Connection: Keep-Alive
Pragma: no-cache
q
If I change that value back to 10000 or 11000 then it does not work. Does anyone have any ideas on why the post data would not be sent properly using the WebBrowser control? I have reset my IE settings back to factory default with no change in behavior.
Update: If I change the JavaScript to look like this instead then it works with the emulation mode set to 10000.
var newRequest = new ActiveXObject("Msxml2.XMLHTTP");
newRequest.open('POST', '/index.cfm', true);
newRequest.send('q');
Is this just a bug that needs to be reported?