Able to reproduce the issue on chrome reported version# 67.0.3396.99 and on latest chrome# 69.0.3478.0 using Windows-10, Ubuntu 14.04 and Mac 10.12.6 This issue is seen from M-60(60.0.3112.0), hence considering this issue as Non-Regression and marking it as Untriaged.

Thanks!

Hi, I have an infrastructure project that depends on the omahaproxy url. I would like to contribute/provide help maintaining the omahaproxy url. Does this project take external contributions?

waffles@, I don't think anything has changed w.r.t. download link parsing in OmahaProxy lately, do you know if anything might have broken elsewhere in the serving pipeline?

Hm, I did not know about this endpoint.

Commit 0ce1357c76fe13997ac496720c7d8b24f1a3addc (to infra_internal) is the cause.

This broke when the team transitioned OmahaProxy to the V3 Omaha protocol in April (although the change may not have been released until later). It looks like it just picks up the codebase attr in the response XML via regex - in V2 this was the full URL but in V3 that value needs to be combined with the basename provided in the <package> to compute the full URL. See https://github.com/google/omaha/blob/master/doc/ServerProtocolV3.md for way too much detail.

Thank you for the offer to contribute but OmahaProxy isn't currently open-sourced. This fix should be fairly straightforward - I'll try to land a patch within the next 24 hours to fix the Windows and Mac URLs. (I believe Linux/ChromeOS/Android/Webview has long been broken for other reasons, and am assuming you don't need them.)

Alex, Robert, or Anthony: do any of you want to comment on whether this is an "official" source of information? In the past we've avoided publishing links to the bare Chrome installers (i.e. installers without the updater - this is one of the reasons we include random bits in the URL), I'm a bit surprised to learn that this was there all along. (That being said, I don't want to direct people toward writing their own Omaha clients, either.)

Thanks for the response. I consume urls for Linux, Mac and windows. It would be great if you could land the fix for Linux as well.

Can you confirm that Linux used to work?

No linux never worked previously, i just used to see "None" instead of the actual dl url

Got it, that's what I thought. Can you share a little more about your use case?

It's unclear whether the Linux URL should serve a DEB or RPM file. I'm inclined to handle Linux support as a separate bug/feature request, as it's not a regression and will involve new functionality.

On a related note, it's also unclear whether the page should serve 32- or 64-bit installer URLs for Windows. Maybe we should revisit the purpose of this page.

Robert, do you know who else uses this and why?

I think laforge@ is the authority on this, but I was under the impression that the dl_urls endpoint was unauthenticated but meant to be unpublished/internal.

Use case -> I have a cron job which pings https://omahaproxy.appspot.com/all.json
To check if a new release of chrome(stable|canary) is available, If so use
https://omahaproxy.appspot.com/dl_urls to download chrome binary for win64 and mac OS To run automated tests.
I am using the dl_urls to download chrome binary for win64, because i found it easy to use 7z to extract the downloaded contents.

I can create a new feature request for the linux url case and drop more info there.

I am aware chrome comes with an autoupdater, but its disabled for other reasons one of them is to maintain a repo with multiple versions of chrome..

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/1c415eaa155939b9be9c3cc9c86407f65bf90ddc

commit 1c415eaa155939b9be9c3cc9c86407f65bf90ddc
Author: Joshua Pawlicki <waffles@google.com>
Date: Thu Jul 12 18:40:24 2018

When this url/ service was created there was no such thing as a side by side dev, beta, stable install so having a way to fetch current binaries was important (and meant for internal use). Today that’s no longer the case.

It should no longer be necessary to share non-meta installers. I’d advocate for the removal of the service.

We cannot remove it entirely (yet) because the macOS signing pipeline uses the dl_urls endpoint in the generate_diffs script.

Had same problem. This url https://omahaproxy.appspot.com/dl_urls does make us work easier. 

I tracked down the part of the Mac signing pipeline in #15 and it was actually dead code. So from the internal side, it would be safe to remove dl_urls.

But it sounds like some people are using it (I sometimes use it as well, but I also have access to the gs bucket for builds), so perhaps we just keep it around? We can always opt to not fix it if/remove it, if it breaks again.

Thoughts?

The problem w/ dl_urls has to do w/ exposing the windows full installers, which don't AU, in a public location.  Those are intentionally something that we don't advertise.

If there isn't an internal need for the service, we should remove it.

Ack, I'll remove it then.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/fb02b4531011e433ff5fa395b95f5e1c1a2eb2a8

commit fb02b4531011e433ff5fa395b95f5e1c1a2eb2a8
Author: Robert Sesek <rsesek@google.com>
Date: Thu Jul 26 18:22:01 2018