Je sais que vous avez toujours pensé aux épreuves et aux tribulations de l'expérience des joies de la vie en tant que proxy Web. Honnêtement, qui ne l'a pas fait? Aujourd'hui, vous êtes chargé de réaliser cet objectif (au moins une partie de celui-ci). Le site Web X reçoit beaucoup de trafic quotidiennement et recherche un PaaS (il s'agit clairement de Proxy as a Service) en raison du grand nombre d'utilisateurs qui insistent pour transmettre des informations sensibles via des paramètres de requête (les utilisateurs sont stupides). Votre tâche consiste à supprimer tous les paramètres de requête sensibles de la demande avant de transmettre la demande à sa destination d'origine.
Contribution
- Une URL HTTP absolue bien formée qui suit la grammaire URI de la section 3 de la RFC3986 .
- Vous pouvez supposer qu'il n'y a pas de fragment
- Exemple de format bref où quelque chose entre crochets indique facultatif:
http[s]://[user:pass@]host.name.com[:port]/[?param1=value1¶m2=value2...]
- Une liste des paramètres de requête à supprimer.
Production
L'URL HTTP modifiée sans les paramètres définis dans la liste d'entrée.
Exemples
http://example.com/ [foo]
> http://example.com/
http://example.com/?foo=bar []
> http://example.com/?foo=bar
http://example.com/ []
> http://example.com/
http://example.com/?foo=1&bar=2&baz=3 [foo,baz]
> http://example.com/?bar=2
http://example.com/?foo=1&bar=2&baz=3 [foo,bar,baz]
> http://example.com/
http://example.com/?foo&bar=2&baz= [foo,baz]
> http://example.com/?bar=2
http://example.com/?abc=1&def=2&baz=foo [foo,bar]
> http://example.com/?abc=1&def=2&baz=foo
http://example.com/?foobar=baz [foo]
> http://example.com/?foobar=baz
http://foo:foo@foo.com:8080/?foo=1&bar=foo [foo]
> http://foo:foo@foo.com:8080/?bar=foo
Notation
Il s'agit de code-golf , donc la réponse la plus courte (en octets) l'emporte.
&apparaître ailleurs qu'entre les paramètres?
?? La commande doit-elle également être conservée telle quelle?
&fait partie d'un paramètre de requête, il doit être correctement encodé comme%26
http://foo:&foo=x@foo.com:8080/?foo=1&bar=fooest autorisé par le RFC. Cela devrait casser un tas de solutions existantes. : D (La règle est que userinfo peut être développé comme non réservé ou pct-escape ou sous-délimités, et les sous-délimitations peuvent avoir &et =)