Bugzilla – Full Text Bug Listing
| Summary: | [MPC] Identify Marketplace Client in HTTP requests for log analysis | ||
|---|---|---|---|
| Product: | [Technology] MPC | Reporter: | Mark Phippard <markphip> |
| Component: | Install | Assignee: | Project Inbox <mpc.install-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | francisu, ian.skerrett, irbull, john.arthorne, jrepenning, reckord |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
|
Description
Mark Phippard
Marketplace Client does not make any HTTP requests during the install process -- this is handled by p2. Ian, does p2 provide API for this kind of thing? John, I think you did the p2 stats work -- I don't remember the details, but I think it boils down to making an http request for an artifact that will then get logged by the server to track downloads. I don't think we have any API for setting the 'client' (p2 UI, vs. director, vs. the MPC). Do you think this would be difficult to add? I'd be happy to do the work here. It was my question to Mark that prompted this request. I'm not sure, but it seems like either Ian's comment about "p2 stats work" implies there already *is* a solution to the problem I'm trying to solve, or possibly that the presenting problem statement isn't clear. So let me describe the base user story more precisely. First, as I understand it, the Marketplace download process goes roughly like this: 1. (->) Client contacts Marketplace to find a interesting download. 2. (<-) Marketplace reply (possibly after multiple back-and-forths) names the "download server" whence actually to get it. 3. (->) Client contacts download server for the actual download. I think Ian refers to "stats work" relating to steps 1 and 2: information recorded on the Marketplace server. My interest is in getting the information at the "download server." If Ian is saying there's some way for me, as a download server operator, to get stats from the Marketplace Server, that might be sufficient. Pointers? If, OTOH, Ian is talking about stats captured at the Marketplace Server, and had missed the point that I want the data at the download server, then let me emphasize that here. The thought in this request is that the Client could package the URL of the Marketplace Server as the "Referer:" header of the download request delivered to the download server. Or, alternatively, if the Marketplace Client were always to set a specific "User-agent:" header, then we could recognize the Marketplace Client, and pretty much assume that this is a referral from the Marketplace. Since we already mine stats related to other "Referer:" headers, it would be more convenient if the information were there (and it's directly consistent with the general HTTP meaning of this header). John, in case you missed this bug. Do you know if p2 can add a client identifier? p2 doesn't make any HTTP requests either ;) However, we use ECF to retrieve files, and I believe it provides a way to add additional headers. Ian, See the FileReader class for where we interact with ECF. I believe where we invoke IRetrieveFileTransferContainerAdapter#sendRetrieveRequest, it takes a map that can pass additional headers (see IRetrieveFileTransferOptions#REQUEST_HEADERS). To answer the original question, p2 doesn't currently set any additional headers that ECF doesn't already add for free. For example we don't set any user agent (not sure if ECF does). Some supplementary info: currently, someone definitely provides User-Agent:, though I don't know who. I can't correlate this to particular Eclipse versions (or much of anything else, client site -- that being what I'm after, after all!), but statistics for a representative week show User-Agent counts (on subclipse installs/updates) like: +----------+--------------------------------+ | count(1) | client | +----------+--------------------------------+ | 667470 | Jakarta Commons-HttpClient/3.1 | | 34373 | Java/1.5.0_11 | | 21648 | Java/1.6.0_20 | | 21563 | Java/1.6.0_21 | | 10161 | Java/1.6.0 | | 8258 | Java/1.6.0_18 | | 6503 | Java/1.6.0_16 | | 5302 | Java/1.6.0_17 | | 4898 | Java/1.5.0 | | 4846 | Java/1.6.0_13 | | 4390 | OaklandSoftware/2.6.1 | ... (In reply to comment #7) Then it looks like the HTTP client is setting it. In the past we used the HTTP client provided by the java class libraries, so most of the entries in the table are just showing you what JRE version they are using. We then switched to using the Apache client in Eclipse Galileo (3.5). That is clearly identifying as "Jakarta Commons-HttpClient/3.1". This has been fixed in MPC 1.5 with the new Apache HTTPClient based transport (bug 484513). The user agent sent by MPC is "mpc/<version> (<environment>) <product>" similar to the agent string used by P2, where <version> is the MPC core bundle version without the qualifier, <environment> are details of the running system and Java environment, and <product> contains the product information for the running Eclipse/RCP or a custom string provided as a Java property. Example: mpc/1.5.0 (Java 1.8.0_74-b02 Oracle Corporation; Windows7 6.1.0 x86-64; de_DE) org.eclipse.sdk.ide/4.6.0.v20160606-1100 (org.eclipse.ui.ide.workbench) |