URL Parçası ve 302 yönlendirmeleri

URL parçasının (sonrasındaki kısım #) sunucuya gönderilmediği iyi bilinmektedir .

Bir sunucu yönlendirme (HTTP durumu 302 ve Location:üstbilgi aracılığıyla ) dahil olduğunda nasıl parçaları çalışır merak ediyorum .

Sorum gerçekten iki misli:

1. Orijinal URL'nin bir fragmanı ( /original.php#foo) varsa ve adresine bir yönlendirme yapılırsa /new.php, orijinal URL'nin parça kısmı kaybolur mu? Yoksa bazen yeni URL'ye uygulanıyor mu?
   Yeni URL /new.php#foobu durumda olacak mı?

2. Orijinal URL'den bağımsız olarak, sunucu bir parça ( /new.php#foo) içeren yeni bir URL'ye yönlendirirse parça "onurlandırılır" mı? Ya da sunucunun gerçekten parçaya müdahale eden bir işi yok mu - ve bu yüzden tarayıcı sadece gidip onu görmezden gelecek /new.phpmi ??

2014 Haziran-27 Güncellemesi :

RFC 7231, Köprü Metni Aktarım Protokolü (HTTP / 1.1): Anlambilim ve İçerik , ÖNERİLEN STANDART olarak yayınlandı. Gönderen Changelog :

Konum başlığı alanının sözdizimi, göreli referanslar ve parçalar dahil olmak üzere tüm URI referanslarına ve parçaların ne zaman uygun olmayacağına ilişkin bazı açıklamalara izin verecek şekilde değiştirildi. (Bölüm 7.1.2)

Bölüm 7.1.2'deki önemli noktalar . Bulunduğu Yer :

3xx (Yeniden Yönlendirme) yanıtında sağlanan Konum değerinin bir parça bileşeni yoksa, kullanıcı aracısı yeniden yönlendirmeyi, değer, istek hedefini oluşturmak için kullanılan URI referansının parça bileşenini miras alıyormuş gibi (yani, yeniden yönlendirme miras alır) işlemek GEREKİR orijinal referansın parçası (varsa).

Örneğin, " http://www.example.org/~tim " URI referansı için oluşturulan bir GET isteği , başlık alanını içeren 303 (Diğerine Bak) yanıtıyla sonuçlanabilir:

Location: /People.html#tim

kullanıcı aracısının " http://www.example.org/People.html#tim " adresine yönlendirmesini önerir.

Benzer şekilde, " http://www.example.org/index.html#larry " URI referansı için oluşturulan bir GET isteği , başlık alanını içeren 301 (Kalıcı Olarak Taşındı) yanıtıyla sonuçlanabilir:

Location: http://www.example.net/index.html

kullanıcı aracısının orijinal parça tanımlayıcısını koruyarak " http://www.example.net/index.html#larry " adresine yönlendirmesini önerir .

Bu sorularınızı açıkça cevaplamalıdır.

Güncelleme END

bu, geçerli HTTP belirtimiyle ilgili açık (belirtilmemiş) bir sorundur . IETF httpbis çalışma grubunun 2 sayısında ele alınmıştır :

• 6: Konumda izin verilen parçalara
• # 43: Yeniden yönlendirme sırasında parça kombinasyonu / öncelik

# 6 Locationbaşlıktaki parçalara izin verir . # 43 diyor ki:

Bunu çeşitli tarayıcılarla test ettim.

• Firefox ve Safari, konum üstbilgisindeki parçayı kullanır.
• Opera, mevcut olduğunda kaynak URI'den gelen parçayı kullanır, aksi takdirde yönlendirme konumundan parçayı kullanır
• IE (8), konum URI'sındaki parçayı yok sayar, dolayısıyla mevcut olduğunda kaynak URI parçasını kullanır

Öneri:

"Not: orijinal URI'den parça tanımlayıcıları ile yeniden yönlendirmenin birleştirilmesi gerektiğinde davranış tanımlanmamıştır; mevcut Kullanıcı Aracıları aslında hangi parçanın öncelikli olduğuna göre farklılık gösterir."

[...]

IE8 görünür yapar fragmanı idenfitier kullanmak Location(davranış ı testere localhost ile sınırlı olabilir).

Bu nedenle, orijinal URI ne olursa olsun, Konum başlığındaki parçanın kullanılması nedeniyle Safari / IE / Firefox / Chrome için (yeni test edildi) tutarlı bir davranışımız var gibi görünüyor.

Bu yüzden belgeye önerimi değiştirmek o beklenen davranış olarak.

bu, tarayıcınızla en uyumlu ve gelecekteki kanıtlara yol açar (çünkü bu sorun sonunda standartlaştırılacaktır) sorunuzun yanıtını verir:

A: orijinal URL'lerden parçalar atılır.

B: gelen fragmanlar Locationbaşlığının layık edilir.

HTTP / 3xx yönlendirmesi gerçekleşirse, Safari 5 ve IE9 ve önceki sürümleri orijinal URI'nin parçasını düşürür. Yanıttaki Konum üstbilgisi bir parça belirtiyorsa, kullanılır.

IE10 +, Chrome 11+, Firefox 4+ ve Opera, 3xx yönlendirmesini izledikten sonra orijinal URI parçasını "yeniden bağlar".

Test sayfası: http://www.webdbg.com/test/redir/fragment/ .

Bu konuyla ilgili daha fazla tartışmaya http://blogs.msdn.com/b/ieinternals/archive/2011/05/17/url-fragments-and-redirects-anchor-hash-missing.aspx adresinden ulaşabilirsiniz.

Sadece size bildirmek için, burada uygun özellikleri bulabilirsiniz. w3c tarafından herkesin nasıl davranması gerektiğini tanımlayan: http://www.w3.org/TR/cuap#uri - madde 4.1 - aşağıya bakın:

Bir kaynak (URI1) taşındığında, HTTP yönlendirmesi yeni konumunu (URI2) gösterebilir.

URI1'in bir parça tanıtıcısı #frag varsa, kullanıcı aracısının ulaşmaya çalışması gereken yeni hedef URI2 # frag olur. URI2'de zaten bir parça tanımlayıcı varsa, #frag eklenmemeli ve yeni hedef URI2 olmalıdır.

Yanlış: Geçerli kullanıcı aracılarının çoğu HTTP yönlendirmeleri uygular, ancak yeni URI'ye parça tanımlayıcı eklemez; bu da kullanıcıyı yanlış kaynakla sonuçlandıkları için genellikle karıştırır.

Referanslar:

HTTP yönlendirmeleri, HTTP / 1.1 spesifikasyonunun [RFC2616] bölüm 10.3'ünde açıklanmaktadır. Gerekli davranış "Yeniden yönlendirilen URL'lerde parça tanımlayıcılarının işlenmesi" [RURL] bölümünde ayrıntılı olarak açıklanmaktadır. "Kalıcı Tekdüzen Kaynak Konum Belirleyicisi (PURL)" terimi, HTTP yönlendirmesi aracılığıyla başka bir URL'yi gösteren bir URL (özel bir URI örneği) belirtir. Daha fazla bilgi için, bkz. "Kalıcı Düzgün Kaynak Bulucuları" [PURL]. Misal:

Bir kullanıcının kaynağı http://www.w3.org/TR/WD-ruby/#changes adresinde istediğini ve sunucunun kullanıcı aracısını http://www.w3.org/TR/ruby/ adresine yönlendirdiğini varsayalım . Bu ikinci URI'yi getirmeden önce, tarayıcıya #changes parça tanımlayıcısını eklemelidir: http://www.w3.org/TR/ruby/#changes .

Karşılaştığım çözümle benzer bir sorun paylaşıyorum.

Umarım preserving hash in IE302 yönlendirmeleri için benzer şartı olan birine yardımcı olur .

Sadece bağlantılar yerine cevabın önemli kısımlarını eklemek

SiteMinderUygulamamızda kimlik doğrulaması kullanıyoruz .

Ben başarılı kimlik doğrulamadan sonra anladım SiteMinderyapıyor 302 redirectionkullanarak kullanıcı istenen başvuru sayfasına giriş formu gizli değişkenivalue (kullanıcı URL'yi talep depolayan /myapp/- without hash fragmento sunucuya gönderilecek olmaz çünkü) benzer isimde redirect. Aşağıdaki örnek form

Yana redirectgizli değişken değeri yalnızca içeren /myapp/karma parçasına olmadan ve bir 302 yönlendirme var, karma parçası bile otomatik bizim uygulama ve bizim uygulama kodunda çalışıyoruz çözümler dışarı çalışmıyor ne olursa olsun gelmeden önce IE tarafından çıkarılır.

IE /myapp/yalnızca yeniden yönlendiriyor ve uygulamamızın varsayılan ana sayfasına açılıyor https://ourapp.com/myapp/#/home.

Bu davranışı anlamak için neredeyse bir gününü boşa harcadık.

Çözüm şudur:

Mevcut değerle birlikte ekleyerek karma parçasını tutmak için giriş formu gizli değişken ( redirect) değerini değiştirdik window.location.hash. Aşağıdaki koda benzer

$(function () {
  var $redirect = $('input[name="redirect"]');
  $redirect.val($redirect.val() + window.location.hash);
});

Bu değişiklikten sonra, redirectgizli değişken kullanıcı tarafından istenen URL değerini olarak depolar /myapp/#/pending/requestsve SiteMinderbunu /myapp/#/pending/requestsIE'de yeniden yönlendirir .

Yukarıdaki çözüm, üç tarayıcıda da iyi çalışıyor Chrome, Firefox and IE.

@AlexFord'a ayrıntılı açıklama ve bu soruna çözüm sağlaması için teşekkürler .