SisMaker
/
rebar3
1
0
Derivar 0
Código Questões 0 Pedidos de integração 0 Projects 0 Lançamentos 62 Wiki Trabalho
Não pode escolher mais do que 25 tópicos Os tópicos devem começar com uma letra ou um número, podem incluir traços ('-') e podem ter até 35 caracteres.
4893 Cometimentos
12 Ramos
11 MiB
Ramo: master
Ramos Etiquetas
${ item.name }
Criar ramo ${ searchTerm }
de 'master'
${ noResults }
rebar3/test/rebar_uri_SUITE.erl

50 linhas
2.0 KiB
Em bruto Ligação permanente Vista normal Histórico

Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
​
​
​
​
​
​
​
​
​
​
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
​
​
​
​
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
​
​
​
​
​
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
​
​
​
​
​
​
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
​
​
​
​
​
​
Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
​
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
​
​
​
​
​
​
Continue transitioning away from http_uri (cherry picked from commit fa577bc46e289b5e1a739df7bd3bf08451579552)
há 5 anos
Fix previous OTP-23 compat patches - Normalize path behaviour to always be "/" across versions - Normalize port visibility behaviour to match input string when appending - restore rebar_utils function to avoid breaking random plugins that peek into our libs for their stuff - Support URIOpts equivalent and protocol-based overrides; the behaviour there is not necessarily consistent across versions in terms of what ports are returned (http_uri always returned a port but uri_string only returns it if explicitly specified -- we choose the latter behaviour on newer releases), but the calls work to ensure URI parsing consistently works across versions The latter judgement call is a bit of an odd one; for consistency we could always mandate ports, but this would come at a performance penalty when appending URL paths (i.e. when fetching packages). The reason for this is that we standardize on the new uri_string behaviour for path appending (if the port wasn't specified, we don't add it), and with the http_uri rules, we need to do a kind of parsing round that checks if the port was included or not to make it equivalent. This is costly, and _not_ returning the port when it isn't specified lets us do this transparently. This allows to maintain backwards compat in older append functions, and nobody aside from us currently uses the new rebar_uri module so we can decide to introduce this potential inconsistency if we wish to.
há 5 anos
 
  1. -module(rebar_uri_SUITE).
  2. 

  3. -export([all/0,
  4.          parse/1,
  5.          append_path/1]).
  6. 

  7. -include_lib("common_test/include/ct.hrl").
  8. -include_lib("eunit/include/eunit.hrl").
  9. -include_lib("kernel/include/file.hrl").
  10. 

  11. all() ->
  12.     [parse, append_path].
  13. 

  14. parse(_Config) ->
  15.     #{scheme := Scheme, host := Host, path := Path} = rebar_uri:parse("https://repo.hex.pm"),
  16.     ?assertEqual("https", Scheme),
  17.     ?assertEqual("repo.hex.pm", Host),
  18.     ?assertEqual(Path, "/"), % Normalize on OTP-23 behaviour.

  19. 

  20.     #{scheme := Scheme2, host := Host2, port := Port2, path := Path2, query := Query2} =
  21.         rebar_uri:parse("https://repo.hex.pm:443?foo=bar"),
  22.     ?assertEqual("https", Scheme2),
  23.     ?assertEqual("repo.hex.pm", Host2),
  24.     ?assertEqual(443, Port2),
  25.     ?assertEqual(Path2, "/"), % Normalize on old http_uri behaviour

  26.     ?assertEqual("foo=bar", Query2),
  27. 

  28.     #{scheme := Scheme3, host := Host3, path := Path3, query := Query3} =
  29.         rebar_uri:parse("https://repo.hex.pm/over/here?foo=bar"),
  30.     ?assertEqual("https", Scheme3),
  31.     ?assertEqual("repo.hex.pm", Host3),
  32.     ?assertEqual("/over/here", Path3),
  33.     ?assertEqual("foo=bar", Query3),
  34. 

  35.     %% override default port and get it parsed as such

  36.     ?assertMatch(#{port := 1337},
  37.                  rebar_uri:parse("https://repo.hex.pm/",
  38.                                  [{scheme_defaults, [{https,1337}]}])),
  39.     ok.
  40. 

  41. append_path(_Config) ->
  42.     %% Default port for the proto is omitted if not mentioned originally

  43.     {ok, Val1} = rebar_uri:append_path("https://repo.hex.pm/", "/repos/org"),
  44.     ?assertEqual("https://repo.hex.pm/repos/org", Val1),
  45.     %% QS elements come after the path

  46.     {ok, Val2} = rebar_uri:append_path("https://repo.hex.pm?foo=bar", "/repos/org"),
  47.     ?assertEqual("https://repo.hex.pm/repos/org?foo=bar", Val2),
  48.     %% If the port is explicitly mentioned, keep it.

  49.     ?assertEqual({ok, "https://repo.hex.pm:443/repos/org?foo=bar"},
  50.                  rebar_uri:append_path("https://repo.hex.pm:443?foo=bar", "/repos/org")).