URL-Splitter

OAuth- und OpenID-Connect-Integrationen scheitern an Details: trailing slash, falscher Port oder http statt https. Anbieter vergleichen die registrierte redirect_uri wörtlich mit dem Wert in der Authorization Request. Bevor Sie sie bei Google, Microsoft oder Okta einfügen, splitten Sie sie mit DN01 und prüfen Schema, Hostname, Path und Query zeichengenau gegen die Allowlist. Bei dynamischen Callbacks fügen Sie den Wert aus einem fehlgeschlagenen Login ein und vergleichen Origin und normalisierte URL mit der Registrierung. Hostname-Groß-/Kleinschreibung ist meist harmlos, weil DN01 Host-Teile normalisiert; ein extra Query-Parameter oder abweichender Path bricht den Flow. Der Check ist kostenlos und spart Runden über Anbieter-Fehlerseiten.

Marketing taggt Links mit UTM-Parametern für Attribution. Mit der Zeit entstehen inkonsistente Schreibweisen, doppelte Keys oder Kodierung, die in Tabellen unsichtbar ist. Fügen Sie jede Landing-URL in den Splitter ein und lesen Sie die Parameter-Tabelle statt Ampersands zu zählen. Prüfen Sie utm_medium, utm_campaign und utm_content vor dem Versand und finden Sie doppelte ? beim URL-Zusammenfügen. Parsing ist lokal – unveröffentlichte Kampagnen-Links mit vertraulichen Slugs sind sicher prüfbar.

CDN- und Reverse-Proxy-Betreiber schreiben Cache-Keys und Origin-Regeln aus URL-Komponenten. Eine Regel /images/* darf nicht versehentlich cache-bustende Query enthalten; Hostname-Routing muss www vom Apex unterscheiden. Das Splitten einer problematischen Request-URL zeigt, ob Pfadsegmente zur Edge-Regel-Reihenfolge passen und ob der Port in host Dev-Umgebungen beeinflusst. Beim Wechsel von Prefix- zu Segment-Routing klärt Segmentvergleich, welche Verzeichnisse Redirect-Maps brauchen.

Webhook-Debugging beginnt oft mit einer Log-Zeile mit vollständiger Callback-URL. Zahlungsdienstleister, GitHub und CI zeigen die exakte Zieladresse. Fügen Sie die URL ein, um den Path für Ihren Router von Query zu trennen, die die Signaturprüfung einbezieht oder ignoriert. Bei nicht standardmäßigem Port bestätigt das Port-Feld, ob :443 explizit war. Schneller als Doppelpunkte in langen HTTPS-Strings zu suchen.

SPAs legen State oft ins Fragment (#/dashboard?tab=billing), das Server-Logs nicht sehen. Wenn Nutzer «falsche Seite nach Login» melden, splitten Sie die URL aus der Adressleiste und prüfen Fragment getrennt von Path und Query. Support kann erklären, ob Server-Routing oder Client-Router das Problem ist. DN01 dokumentiert: Fragment wird analysiert, erscheint aber nicht in klassischen Access-Log-Zeilen.

Security Reviews erhalten verdächtige Links mit unzulässigen Schemas. DN01 akzeptiert absolute http/https und lehnt javascript:, data: und file: ab – sichere Praxis. Analysten dokumentieren Schema und Host fürs Ticket ohne Codeausführung oder Fetch. Bei https unterstützt Hostname-Extraktion WHOIS oder DNS in anderen Tools bei rein strukturellem Schritt.

API-Gateways und Service-Meshes hängen Path-Präfixe an interne Services. Extern https://public.example.com/payments/v1/charges, intern /v1/charges. Beide Darstellungen als Segmente zu splitten macht Prefix-Drift vor Produktions-Routetabellen sichtbar.

Bei «absolute URL with scheme and host is required» https:// (oder http://) vor den Host setzen und Leerzeichen entfernen. example.com/path ohne Schema ist hier keine gültige absolute URL. Am besten aus der Browser-Adressleiste kopieren.

javascript:, data: und file: sind absichtlich blockiert – keine Web-Navigation für Redirect oder CDN. Als https umschreiben, wenn Sie eine Seite aus anderem Kontext studieren, oder ausführbare Payloads vor dem Parsen entfernen.

Wenn Query-Parameter leer wirken, obwohl nach ? Werte erwartet werden, Kodierung prüfen. Fehlerhafte Percent-Sequenzen verhindern Parsing. URL so einfügen, wie sie in Log, E-Mail oder JSON stand – nicht teilweise dekodiert.

Wenn sich Host und Hostname nur im Port unterscheiden, braucht die Routing-Regel evtl. expliziten Port. Standard-https lässt :443 weg; :3000 zeigt befülltes Port-Feld. Normalisierte URL entfernt keinen Custom-Port.

Doppelte Query-Keys erscheinen als separate Zeilen. Manche Frameworks behalten nur den letzten Wert; andere konkatenieren. Der Splitter zeigt strukturell Vorhandenes, nicht die Runtime-Wahl Ihres Frameworks.

Bei internationalisierten Domains (IDN) zeigt der Hostname die Punycode-Form (xn--…), wenn die URL so kodiert eingefügt wurde. Das ist korrekt für technische Vergleiche mit Server-Logs und TLS-SNI. Wenn Marketing-Teams die Unicode-Darstellung erwarten, notieren Sie beide Varianten im Ticket — DN01 spiegelt die Eingabe nach Parser-Normalisierung, ohne zusätzliche DNS- oder WHOIS-Abfragen auszulösen. Für reine Hostname-Reviews können Sie danach den Punycode-Konverter auf DN01 nutzen.

Das Schema legt Transport-Erwartungen fest. OAuth-Anbieter verlangen https in Produktion; lokale Entwicklung erlaubt manchmal http auf localhost. Schema getrennt vom Origin hilft bei Mixed Content und HSTS ohne RFC-Nachlese. Bei nicht-http-Schemas, die andere Tools parsen, warnt DN01 ggf., dass kein Netzwerkzugriff stattfand – http/https stehen hier im Vordergrund.

Host versus Hostname spiegelt RFC 3986 und Server-APIs. TLS-SNI nutzt Hostname; Sockets binden an Ports. CDN-Healthchecks zielen auf hostname:443, Docker-Services publizieren host:8080. Beide Felder reduzieren Verwirrung, wenn «Host» informell nur den DNS-Namen meint.

Path und Segmente unterstützen string- und REST-Denken. Proxies dokumentieren Prefix-Regeln; Anwendungscode splittet Segmente für Autorisierung. Percent-Encoding im Path ist Drahtform – treuer Vergleich mit Access Logs. Segmentlisten lassen leere Teile von führenden/abschließenden Slashes weg.

Rohe und geparste Query sind für Analytics und Signaturen unterschiedlich relevant. Marketing braucht dekodierte utm_campaign; HMAC-Webhooks evtl. exakt gesendete Query-Substring. Doppelte Keys und leere Werte sind von fehlenden Keys zu unterscheiden.

Fragmente sind der am meisten missverstandene URL-Teil. Bei klassischem Seitenladen fordert der Browser nur den Teil vor # an; Fragment wird lokal interpretiert. Fragment-Änderungen erzeugen daher keine neuen Server-Log-Zeilen. Historische implizite OAuth-Flows lieferten Tokens im Fragment – Security Reviews müssen Fragmente prüfen, auch wenn nginx sie nicht sieht. DN01 zeigt sie zur Aufklärung und SPA-Debug, nicht als Server-Routing.

Origin und normalisierte URL unterstützen Äquivalenzprüfungen. Origin ist CORS-Grenze und Speicher-Partitionierung. Normalisierung setzt Schema und Host klein gemäß Tool-Regeln. Für Allowlists nutzen, aber prüfen, ob Ihr IdP case-sensitive Paths erwartet.

Manuelles Zerteilen im Editor reicht für eine URL, skaliert aber schlecht bei langen Queries. Ein falsch gesetztes & oder = in base64 bricht naive Skripte. DN01 nutzt einen formalen Parser im Sinne von Go net/url.

DevTools Network zeigt URLs erst nach einer Anfrage. Für redirect_uri oder embargoierte Kampagnen ist Anfragen oft unerwünscht. Lokales Parsing strukturiert ohne Netzwerk-Nebenwirkungen.

Python- oder Node-One-Liner sind flexibel, aber für Marketing/Support schlecht teilbar. DN01 bietet konsistente Tabelle in Ihrer Sprache ohne Runtime-Installation.

Tabellenformeln kämpfen mit kodierter Query und doppelten Keys und verstecken Fragmente. Der Splitter zeigt Fragmente in eigener Zeile.

Online-Parser variieren in Komponenten und fetchen teils die Remote-Seite. DN01 ist spezifisch für absolutes http/https-Struktur-Parsing ohne Fetch und mit Ablehnung gefährlicher Schemas.

curl -I oder wget prüfen Erreichbarkeit und vermischen DNS, TLS und HTTP-Status mit URL-Struktur. Erst DN01 für Path und Query, dann Erreichbarkeit.

RFC 3986 lesen lohnt für Tiefe, ist in Incidents aber langsam. DN01 operationalisiert die Felder für Responder in Tabellenform — inklusive Fragment-Hinweis für SPA- und OAuth-Flows.