#344 Throw away all /g/ urls
Closed: Won't fix 3 years ago by msuchy. Opened 5 years ago by clime.

In our code, we use url paths like /g/<group_name>/<copr_dirname>/repo/<name_release>/<repofile> for group coprs and e.g. just <username>/<copr_dirname>/repo/<name_release>/<repofile> for user coprs.

Well...instead of this we should make it so that there is just one entry point:

<ownername>/<copr_dirname>/repo/<name_release>/<repofile>

Where ownername may or may not begin with '@'. We will need to keep the /g/ paths working e.g. by permanent redirects.

'@' is ok to be used in URL path. It is only impossible to use it in the "domain name" part of URL so it wasn't actually necessary to introduce the '/g/' thing at all.

We might want to do something about Flask wanting to percent-encode the '@' char.


I was suggesting this a long time ago, so +1 from me.

IIRC @msuchy was against it, so ideally we should wait also for his opinion.

This is not -1 -- I'm neutral, but to be honest @ symbols in URLs look ugly to me (it evokes feeling that there's some mess in URL).

I'd much rather love to treat groups equivalently to users - similarly as it is done on gitlab/github. It would require us to pair FAS name with Copr name (as we do for groups anyways), but it would result in really pretty-looking layout.

I'd much rather love to treat groups equivalently to users - similarly as it is done on gitlab/github. It would require us to pair FAS name with Copr name (as we do for groups anyways), but it would result in really pretty-looking layout.

I agree it would be good. We will need to keep the old paths working if implemented.

See http://www.ietf.org/rfc/rfc3986.txt
Chapters 2.2 and 3.3.

A URI is composed from a limited set of characters consisting of
digits, letters, and a few graphic symbols.  A reserved subset of
those characters may be used to delimit syntax components within a
URI while the remaining characters, including both the unreserved set
and those reserved characters not acting as delimiters, define each
component's identifying data.

and

URIs include components and subcomponents that are delimited by
characters in the "reserved" set.  These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.

Short answer would be: https://en.wikipedia.org/wiki/@_!*

In other words, @ can be used if it does not conflict with scheme
specific syntax. For http and https that would be passing user info
in URL, e.g.

http://username:password@localhost:5000/path

User info can however be passed only in the first "authority"
part of the URL. In path, '@' can be therefore used without
any problems.

'@' (as well as ':') are in the "reserved" category of characters in the
URI grammar according to the RFC but that's only a "simplification".
It does not mean they cannot be used in URI path and in case of http://
and https://, they are allowed to be used.

As mentioned, we should, however, discuss whether to keep the '@' char
at all or follow Pagure/Github/GitLab group's naming. I think it would be
good to make it consistent with the rest although it's not a small change
on our side.

Metadata Update from @msuchy:
- Issue tagged with: RFE

5 years ago

I am going to close this. We did not have time for this in past years. And it will likely not change in the upcoming several years.
I will happily review any pull-request for this if you take the initiative.

Metadata Update from @msuchy:
- Issue close_status updated to: Won't fix
- Issue status updated to: Closed (was: Open)

3 years ago

Login to comment on this ticket.

Metadata