Ich weiß, Sie haben immer über die Strapazen nachgedacht, die es mit sich bringt, als Web-Proxy die Freuden des Lebens zu erleben. Ehrlich gesagt, wer hat das nicht? Heute haben Sie die Aufgabe, dieses Ziel zu erreichen (zumindest einen Teil davon). Website X erhält täglich viel Verkehr und sucht aufgrund der großen Anzahl von Benutzern, die darauf bestehen, vertrauliche Informationen über Abfrageparameter weiterzugeben (Benutzer sind albern), nach einem PaaS (dies bezieht sich eindeutig auf Proxy als Dienst). Ihre Aufgabe ist es, alle vertraulichen Abfrageparameter aus der Anforderung zu entfernen, bevor Sie die Anforderung an das ursprüngliche Ziel weiterleiten.
Eingang
- Eine wohlgeformte absolute HTTP-URL, die der URI-Grammatik in RFC3986, Abschnitt 3 , folgt .
- Sie können davon ausgehen, dass es kein Fragment gibt
- Kurzes Formatbeispiel, in dem alles in eckigen Klammern als optional gekennzeichnet ist:
http[s]://[user:pass@]host.name.com[:port]/[?param1=value1¶m2=value2...]
- Eine Liste der zu entfernenden Abfrageparameter.
Ausgabe
Die geänderte HTTP-URL ohne die in der Eingabeliste definierten Parameter.
Beispiele
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
Wertung
Das ist Code-Golf , also gewinnt die kürzeste Antwort (in Bytes).
&irgendwo anders als zwischen Parametern erscheinen?
?? Sollte die Bestellung auch so bleiben, wie sie war?
&es Teil eines Abfrageparameters ist, sollte er korrekt urlencodiert sein als%26
http://foo:&foo=x@foo.com:8080/?foo=1&bar=fooist das nach dem RFC erlaubt. Dies sollte einen Haufen bestehender Lösungen zerstören. : D (Die Regel ist, dass Benutzerinformationen als nicht reserviert oder pct-Escape oder Sub-Delims erweitert werden können und Sub-Delims haben können &und =)