gbfs.json: allow relative URLs to other files

[derhuerst]

If you are new to the specification, please introduce yourself (name and organization/link to GBFS). It’s helpful to know who we're chatting with!

Hey, I'm Jannis, mostly active in the GTFS realm, but occasionally I work with shared mobility data. I'm passionate about the web and all things open (open data, open source, etc.)!

What is the issue and why is it an issue?

I originally brought this question up in the (old) PR introducing gbfs.json.

The spec currently defines gtfs.json's url field as being of the type URL, which in turn is defined as follows:

A fully qualified URL that includes http:// or https://. Any special characters in the URL MUST be correctly escaped. See the following https://www.w3.org/Addressing/URL/4_URI_Recommentations.html for a description of how to create fully qualified URL values.

I interpet this as follows:

• A GBFS URL must conform to RFC 3986, and could therefore also be relative, except that
• it must contain http(s)://, which I interpret as "its scheme must be http(s):". – Even if we don't adopt the quite technical "scheme" term, I think it would be more precise to say that it should begin with http():.

I would argue strongly in favour of explicitly allowing relative URLs, given that they make a GBFS feed (the set of files) much more portable and less brittle, because it's "common path" can be changed (a.k.a. it can be moved within or across web servers) without having to modify the files.

While consuming some GBFS feeds in Germany, I've noticed that a) a feed provider got their absolute URLs wrong (so that the feed is invalid), and b) that mirroring or fixing and republishing (which is the sad reality given the frequent bugs in feeds) is cumbersome because one has to adapt all absolute URLs.

A bonus of using relative URLs: It would also allow consuming a GBFS feed via the file: URL scheme, making tools (e.g. OTP or Lamassu) more user-friendly.

Is your potential solution a breaking change?

• Yes, likely.
• No
• Unsure

I may break some consumers, given that they don't resolve relative URLs.

---

For a discussion about using IRIs/IRLs instead of URLs, see #543.

[testower]

I think this is an interesting proposal. Would love to avoid having to manipulate URLs in the aggregation layer. Consumer support is definitely a potential issue so curious to hear what the community has to say.

[leonardehrenfried]

I can only speak for OTP as a consumer, but if it makes the producers lives easier (and two already said so), then I would be okay with changing the implementation.

Interesting fact: we already allow file: URLs in OTP because we use that for unit tests. It's undocumented though.

[richfab]

Thank you @derhuerst for this contribution. Relative URLs is a very interesting topic.

Tagging recent contributors for visibility: @cmonagle @viestat @ArashMansouri @AntoineAugusti @ezmckinn @fbouchPBSC @Carl-NM @bdferris-v2 @kulovan @gajayraghav @hynick4 @PierrickP @tdelmas @tobsesHub @tstrubel @HannesOlszewski @simonsolnes @futuretap

[tdelmas]

To have work in both the consumer and producer side, I would say:

• It is interesting
• It will make life easier on the producer side
• It will make life more complicated on the consumer side

Also, the current specification specifies "All endpoints MUST use HTTPS" (so the file: is not really valid, but as it is used for development, it's not really an issue.)

• Does scheme-relative links makes sense //something as it must be https?
• Are all relative path allowed (both domain-relative /something and path-relative like ./something, ../../something or simply something)?
• consumers must be careful if the fetch of the original gbfs file had a redirect (because the relative link must be computer from the last uri, not the one the consumer asked for)

If it's accepted, it must be clearly documented (ideally a well known producer should implement it, to drive consumers)

[AntoineAugusti]

I would be against this, it makes life more complicated on the consumer side.

There are more consumers than producers. Providing stable URLs shouldn't be too hard for producers and relative URLs are subject to interpretation/implementation (relative to the base domain, current path, ./, ../../ etc).

[testower]

After reviewing some of these comments and discussing at the North America workshops last week, I'm leaning towards not supporting this proposal. Anything that makes consuming GBFS more complicated is not great, especially by introducing ambiguity about where to find feeds.

[futuretap]

I'm against this, would make life on the consumer side more challenging. Also, as @tdelmas pointed out, there could be edge cases involving redirects of the root feed which are actually pretty common.

[ezmckinn]

I don't have a strong opinion on this, from the Producer side. It is not likely that we implement relative URLs or change our web domain soon, so even if it were allowed, we would be unlikely to implement.

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[derhuerst]

still relevant

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[derhuerst]

still relevant

[futuretap]

@derhuerst can't you just create a PR and ask for a vote? Just defending staleness by posting "still relevant" doesn't help anyone. I'm against this, as written above, but let the community decide!

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[mobilitydataio]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.