machawk1
Append information about Mink onto the user agent when making requests to the aggregator
e.g., Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 Mink/1.4.1
This will allow for logging on the aggregator side.
http://stackoverflow.com/questions/19294981/how-to-find-the-version-of-chrome-browser-from-my-extension https://developer.chrome.com/extensions/runtime
Per @ibnesayeed, "Make it easy to parse, something like [custom user agent]".
Have the custom user-agent in [square brackets] if you plan to append extra info to the existing browser user-agent, otherwise something like the following will be a preferred way.
Mink:OS:ARCH:VERSION
Why square brackets, of all characters? I am open to doing it for the sake of parsing logs.
Because that's not commonly present in the existing browser user agents.
So, would the following suffice?
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 [Mink/1.4.1]
How about something like this:
Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36 [Mink:win:x86-64:41.0.2228.0:1.4.1]
This way you still have access to the raw user-agent of the browser, but have all the useful pieces of information in one place for easily grepping/filtering the access log.
That could be done and I understand your rationale now (I think). Once you parse out the [.*], you want to be able to get system/browser information without having to parse the rest of the user agent string, is this correct?
On second thought, it makes the information about Mink quite convoluted.
Yes, that's what I was trying to achieve. I understand that Mink info in convoluted and mixed with the platform info. Something like Original User-Agent [win:x86-64:41.0.2228.0 Mink:1.4.1] might work better. In this way we have separated the platform info from the tool info using a space and internally they two have different attributes separated by colons. Alternatively, you may like to reverse the order of the the platform info and the tool info like Original User-Agent [Mink:1.4.1 win:x86-64:41.0.2228.0].
Via jQuery, which I am using for the Ajax requests to the aggregator, I attempted a simple:
$.ajaxSetup({
beforeSend: function(request) {
request.setRequestHeader("User-Agent","ThisIsATest");
}
});
then proceed with the Ajax request. This is executed from a local (file://) web page to a dummy php -S server that echos back the received user agent. Chrome reports: Refused to set unsafe header "User-Agent" in the JS console. Will try this approach in a similar manner in the Chrome extension but not holding my breath.
An alternative in the Chrome extension API is to use the webRequest module to modify the User-Agent header but this would affect all requests from the user's browser, which is not what is needed.
webRequest allows the modifications to be conditional on a certain URI format, which we could specify memgator.cs.odu.edu:1208/* to only contain the user agent modifications.
@ibnesayeed , I did not see a http://github.com/oduwsdl/memgator ticket related to the logging. Without this, it's a little harder to reliably test what is being received server side from Mink using the normal flow. I can continue with the above local-to-php style of implementation but likely cannot close this until I can be confident that MemGator is receiving the modified user-agent.
Unfortunately, a handful of headers are not allowed to be set in the XMLHttpRequest using the setRequestHeader() method.
@ibnesayeed , I did not see a http://github.com/oduwsdl/memgator ticket related to the logging. Without this, it's a little harder to reliably test what is being received server side from Mink using the normal flow. I can continue with the above local-to-php style of implementation but likely cannot close this until I can be confident that MemGator is receiving the modified user-agent.
I am still thinking if this logging should be part of MemGator itself or a reverse proxy service should take care of it.
@ibnesayeed What was the reason for Mink sending a modified User-Agent, btw? I'm going to lower the priority on this ticket, since there is nothing in-place on the receiving end to do anything useful with the modified User-Agent.
@ibnesayeed What was the reason for Mink sending a modified User-Agent, btw? I'm going to lower the priority on this ticket, since there is nothing in-place on the receiving end to do anything useful with the modified User-Agent.
To have a better understanding of how popular Mink is, how often it is used, and from what places in the world. Additionally, it will help filtering traffic of Mink from the MemGator logs when needed to know what are the sources that are consuming MemGator.
Ok. This can likely be done via the above webRequest API. I can deploy a local instance of MemGator or a dummy server to test that the right UA is being sent. When do you expect the service, even if the functionality is external to MemGator, to be in-place?