400 Bad Request Hatası Nedir? Nasıl Çözülür?

Hostider tarafından

Ağustos 13, 2026 1 kez okundu Okuma süresi: 16dk, 20sn

400 Bad Request Hatası Nedir? Nasıl Çözülür?

400 Bad Request Hatası Nedir? İstemci İstekleri Neden Bozulur?

400 Bad Request, web sunucusunun istemciden aldığı HTTP isteğinde bir problem bulunduğunu ve bu nedenle isteği işleyemediğini veya işlemeyi reddettiğini gösteren bir HTTP durum kodudur. Hatalı istek sözdizimi, büyük veya geçersiz header alanları, bozuk cookie verileri ya da uygulamanın beklediği biçime uymayan API istekleri 400 yanıtına neden olabilir.

Bu hata görüldüğünde bağlantının tamamen kopuk olduğu düşünülmemelidir. Sunucu çoğu durumda isteği almış ve HTTP seviyesinde hata yanıtı üretmiştir. Bu nedenle teşhis, bağlantı sorunlarından çok isteğin nasıl oluşturulduğu ve sunucunun bu isteği neden kabul etmediği üzerine yapılmalıdır.

400 Bad Request Hatası Nedir?

HTTP durum kodları, sunucunun istemciden gelen isteğe verdiği sonucu açıklar. 4xx sınıfındaki kodlar istemci tarafından gönderilen istekte sorun bulunduğunu veya isteğin belirli koşullar altında gerçekleştirilemediğini belirtir.

Basit bir HTTP isteği şu şekilde düşünülebilir:

İstemci
   │
   │ GET /urun?id=42 HTTP/1.1
   │ Host: example.com
   │ Cookie: ...
   │
   ▼
Web Sunucusu

İstemci
   │
   │ GET /urun?id=42 HTTP/1.1
   │ Host: example.com
   │ Cookie: ...
   │
   ▼
Web Sunucusu

İstek geçerliyse sunucu örneğin:

HTTP/1.1 200 OK

HTTP/1.1 200 OK

yanıtı döndürebilir.

Sunucu isteğin yapısını kabul etmiyorsa ise:

HTTP/1.1 400 Bad Request

HTTP/1.1 400 Bad Request

yanıtı oluşabilir.

Buradaki önemli ayrım şudur:

400 Bad Request, çoğunlukla sunucuya ulaşıldığını ancak gönderilen HTTP isteğinin kabul edilmediğini gösterir.

Örneğin ERR_CONNECTION_REFUSED hatasında TCP bağlantısı daha HTTP katmanına ulaşmadan başarısız olabilir. 400 hatasında ise bağlantı kurulmuş ve HTTP seviyesinde bir yanıt alınmıştır.

Bir HTTP İsteği Nelerden Oluşur?

400 hatasını doğru anlamak için HTTP isteğinin yalnızca URL’den ibaret olmadığını bilmek gerekir.

Tipik bir istek şu bileşenleri içerir:

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <TOKEN>
Cookie: session=...

{
  "name": "Ahmet"
}

POST /api/users HTTP/1.1
Host: example.com
Content-Type: application/json
Authorization: Bearer <TOKEN>
Cookie: session=...

{
  "name": "Ahmet"
}

Bu yapıda:

HTTP metodu,
hedef URI,
request header alanları,
cookie bilgileri,
request body,
Content-Type,
kimlik doğrulama bilgileri

sunucunun isteği nasıl yorumlayacağını belirler.

Bu bileşenlerden herhangi biri web sunucusunun veya uygulamanın beklediği biçime uymadığında istek reddedilebilir.

400 Bad Request Hatası Neden Olur?

Hatalı veya Bozuk HTTP İsteği

HTTP mesajı geçerli biçimde oluşturulmamışsa sunucu isteği okuyamayabilir.

Özellikle şu ortamlarda bu tür problemlerle karşılaşılabilir:

özel API istemcileri,
yanlış yapılandırılmış proxy sistemleri,
botlar,
otomasyon araçları,
manuel HTTP istekleri,
hatalı frontend veya backend kodları.

Normal bir web tarayıcısının kendi başına bozuk HTTP mesajı üretmesi daha düşük olasılıktır. Buna karşılık tarayıcıda çalışan JavaScript kodu veya uygulamanın oluşturduğu URL ve request içeriği hatalı olabilir.

Cookie Verisinin Bozulması veya Büyümesi

400 hatasının kullanıcı tarafında en sık karşılaşılan nedenlerinden biri cookie verileridir.

Bir alan adına ait cookie sayısı veya boyutu zaman içinde büyüyebilir. Uygulama da eski veya geçersiz oturum bilgilerini tekrar tekrar istemciye gönderebilir.

Şu senaryo cookie sorununa işaret edebilir:

Site normal tarayıcı profilinde açılmıyor.
Aynı site gizli pencerede çalışıyor.
Başka cihazdan açılabiliyor.
Diğer kullanıcılar problem yaşamıyor.

Böyle bir durumda ilgili alan adına ait cookie’leri temizlemek anlamlı bir testtir.

Tüm tarayıcı geçmişini ve tüm site verilerini silmek yerine yalnızca sorun yaşanan alan adına ait cookie’leri temizlemek daha kontrollü bir yaklaşımdır.

Request Header Boyutunun Aşılması

HTTP istekleri çeşitli header alanları taşıyabilir:

Host
Cookie
Authorization
User-Agent
Referer
Accept
Content-Type

Host
Cookie
Authorization
User-Agent
Referer
Accept
Content-Type

Özellikle Cookie ve Authorization alanları büyüyebilir.

Örneğin:

çok sayıda cookie oluşturulması,
büyük oturum verilerinin cookie içinde tutulması,
uzun kimlik doğrulama token’ları,
tekrar eden header alanları

request header boyutunu artırabilir.

Web sunucusu belirlediği header sınırını aşan isteği reddedebilir.

Bu durumda kullanıcı bazen şu ifadeye benzer bir hata görebilir:

400 Bad Request
Request Header Or Cookie Too Large

400 Bad Request
Request Header Or Cookie Too Large

Ancak header sınırını yükseltmek tek başına kalıcı çözüm değildir. Öncelikle header’ın neden gereğinden fazla büyüdüğü araştırılmalıdır.

Hatalı URL ve Query Parametreleri

Bir URL yalnızca alan adından oluşmaz.

Örneğin:

https://example.com/search?q=vds&page=2

https://example.com/search?q=vds&page=2

adresinde q ve page birer query parametresidir.

Uygulama tarafından hatalı oluşturulan URL’ler, geçersiz karakterler veya yanlış encode edilmiş parametreler isteğin reddedilmesine yol açabilir.

Özellikle:

uygulamanın oluşturduğu yönlendirmeler,
frontend tarafından üretilen API URL’leri,
üçüncü taraf entegrasyonlar

bu tür problemlere neden olabilir.

Bununla birlikte her uzun veya hatalı URL’nin 400 döndürmesi gerekmez. Örneğin URI boyutu sunucu sınırını aşarsa 414 URI Too Long gibi daha spesifik bir durum kodu görülebilir.

Bu nedenle gerçek HTTP yanıt kodu sunucu loglarından doğrulanmalıdır.

API İsteğinin Beklenen Formata Uymaması

API’lerde 400 hatası oldukça yaygındır.

Bir endpoint şu JSON yapısını bekliyor olabilir:

{
  "name": "Ahmet",
  "email": "user@example.com"
}

{
  "name": "Ahmet",
  "email": "[email protected]"
}

İstemci ise şu veriyi gönderiyor olabilir:

{
  "mail": "user@example.com"
}

{
  "mail": "[email protected]"
}

Uygulamanın doğrulama kurallarına göre zorunlu name veya email alanlarının eksik olması 400 yanıtına neden olabilir.

Benzer biçimde request body JSON olmasına rağmen şu header kullanılıyorsa:

Content-Type: text/plain

Content-Type: text/plain

uygulama isteği beklenen biçimde işleyemeyebilir.

Doğru değer şu olabilir:

Content-Type: application/json

Content-Type: application/json

Her geçersiz API isteğinin zorunlu olarak 400 döndürmesi gerekmediğini de unutmamak gerekir. Problemin türüne göre 401, 403, 415 veya 422 gibi daha spesifik HTTP kodları kullanılabilir.

Reverse Proxy veya Web Sunucusu Sorunları

Gerçek üretim ortamında istemci çoğu zaman doğrudan uygulamaya bağlanmaz.

Örneğin:

Tarayıcı
   │
   ▼
Reverse Proxy
   │
   ▼
NGINX
   │
   ▼
Uygulama

Tarayıcı
   │
   ▼
Reverse Proxy
   │
   ▼
NGINX
   │
   ▼
Uygulama

veya:

İstemci
   │
   ▼
Load Balancer
   │
   ▼
Web Sunucusu
   │
   ▼
Container
   │
   ▼
API

İstemci
   │
   ▼
Load Balancer
   │
   ▼
Web Sunucusu
   │
   ▼
Container
   │
   ▼
API

400 yanıtını uygulamanın kendisi yerine önündeki reverse proxy veya web sunucusu üretebilir.

Bu nedenle uygulama loglarında hiçbir istek bulunmaması önemli bir teşhis ipucudur.

İstek uygulamaya hiç ulaşmıyorsa problem şu katmanlarda aranabilir:

NGINX,
Apache,
load balancer,
WAF,
reverse proxy,
başka bir ara katman.

400 Bad Request Kullanıcı Tarafında Nasıl Çözülür?

Bir web sitesinde 400 hatası gören son kullanıcı aşağıdaki sırayı izleyebilir.

1. URL’yi Kontrol Edin

Adres çubuğundaki URL yanlış veya manuel olarak değiştirilmiş olabilir.

Özellikle çok uzun parametreler içeren bağlantılarda sitenin ana sayfasını açıp ilgili sayfaya yeniden ilerlemek yararlı olabilir.

2. Sayfayı Yeniden Yükleyin

Geçici istemci veya oturum problemlerinde sayfanın yeniden istenmesi yeterli olabilir.

Ancak kalıcı 400 hatalarında sürekli yenilemek sorunun nedenini ortadan kaldırmaz.

3. Gizli Pencerede Test Edin

Site gizli pencerede sorunsuz açılıyorsa normal tarayıcı profilindeki:

cookie,
oturum verisi,
siteye özel tarayıcı verileri

kontrol edilmelidir.

4. İlgili Siteye Ait Cookie’leri Temizleyin

Özellikle:

Request Header Or Cookie Too Large

Request Header Or Cookie Too Large

mesajıyla karşılaşılıyorsa cookie’lerin temizlenmesi faydalı olabilir.

Ancak sorun sürekli tekrarlanıyorsa web uygulamasının gereğinden büyük cookie üretip üretmediği sunucu tarafında araştırılmalıdır.

5. Başka Tarayıcı veya Cihazda Deneyin

Farklı bir istemcide site çalışıyorsa problemin sunucunun tamamından ziyade belirli bir kullanıcı oturumuyla ilişkili olma ihtimali artar.

6. Sorunun Herkeste Olup Olmadığını Kontrol Edin

Tüm kullanıcılar aynı URL’de 400 alıyorsa yalnızca tarayıcı ayarlarına odaklanmak doğru değildir.

Bu durumda web sunucusu ve uygulama logları incelenmelidir.

Sunucu Tarafında 400 Hatası Nasıl Teşhis Edilir?

Sunucu yöneticisinin cevaplaması gereken en önemli soru şudur:

400 yanıtını hangi bileşen oluşturuyor?

Örnek:

Client
  ↓
Reverse Proxy
  ↓
NGINX
  ↓
Application

Client
  ↓
Reverse Proxy
  ↓
NGINX
  ↓
Application

İstek uygulama loglarına kadar ulaşıyor mu?

Ulaşmıyorsa 400 daha üst bir katmanda oluşturuluyor olabilir.

curl ile İsteği Kontrol Etme

HTTP iletişimini ayrıntılı incelemek için:

curl -v https://example.com/

curl -v https://example.com/

kullanılabilir.

Bir API isteğini test etmek için:

curl -v \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Ahmet"}' \
  https://example.com/api/users

curl -v \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"name":"Ahmet"}' \
  https://example.com/api/users

Bu komut yalnızca örnektir.

curl -v bağlantı ayrıntılarıyla birlikte gönderilen ve alınan header’ları görmeyi kolaylaştırır.

Güvenlik notu: Authorization, session cookie veya API token gibi hassas değerleri hata kaydı ya da destek talebi paylaşırken mutlaka maskeleyin.

NGINX Loglarını İnceleme

NGINX kullanılan birçok Linux sisteminde yaygın log konumları şöyledir:

/var/log/nginx/access.log
/var/log/nginx/error.log

/var/log/nginx/access.log
/var/log/nginx/error.log

Son hata kayıtlarını görmek için:

sudo tail -n 100 /var/log/nginx/error.log

sudo tail -n 100 /var/log/nginx/error.log

Canlı takip için:

sudo tail -f /var/log/nginx/error.log

sudo tail -f /var/log/nginx/error.log

Özel NGINX yapılandırmalarında log dosyalarının farklı konumlarda bulunabileceğini unutmayın.

Access log şu sorulara cevap verebilir:

İstek sunucuya ulaştı mı?
Hangi URL 400 döndürdü?
Hangi istemci etkilendi?
Sorun yalnızca belirli endpointlerde mi?

Error log ise web sunucusunun isteği neden reddettiğine dair daha ayrıntılı mesajlar sağlayabilir.

Apache Loglarını İnceleme

Debian/Ubuntu tabanlı sistemlerde Apache error log yaygın olarak:

/var/log/apache2/error.log

/var/log/apache2/error.log

konumundadır.

RHEL tabanlı sistemlerde ise yaygın bir yol:

/var/log/httpd/error_log

/var/log/httpd/error_log

olabilir.

Kesin log yolu mevcut Apache yapılandırmasından doğrulanmalıdır.

Buradaki amaç yalnızca hata kodunu görmek değil, 400 yanıtının hangi virtual host veya request nedeniyle oluştuğunu anlamaktır.

NGINX’te Header ve Cookie Kaynaklı 400 Hataları

NGINX, HTTP request header verilerini buffer’lar içinde işler.

Bu davranışla ilişkili direktiflerden bazıları:

client_header_buffer_size 1k;
large_client_header_buffers 4 8k;

client_header_buffer_size 1k;
large_client_header_buffers 4 8k;

şeklinde olabilir.

Bu değerler örnektir; çalışan sistemdeki gerçek yapılandırma kontrol edilmelidir.

Özellikle büyük Cookie veya Authorization header alanları web sunucusunun kabul ettiği sınırı aşarsa 400 hatası oluşabilir.

Bu durumda yanlış yaklaşım şudur:

Header büyük
   ↓
Limiti çok yükselt
   ↓
Sorun çözüldü

Header büyük
   ↓
Limiti çok yükselt
   ↓
Sorun çözüldü

Asıl araştırılması gereken şudur:

Cookie neden büyüdü?
Aynı veri birden fazla cookie içinde mi tutuluyor?
Token gereğinden büyük mü?
Eski cookie’ler temizlenmiyor mu?
Uygulama her istekte yeni cookie mi üretiyor?
Reverse proxy farklı bir sınır uyguluyor mu?

Yapılandırma değişikliğinden önce NGINX dosyalarını doğrulamak için:

sudo nginx -t

sudo nginx -t

kullanılabilir.

Test başarılıysa uygun servis yönetim yöntemiyle yapılandırma yeniden yüklenebilir.

API’lerde 400 Bad Request Nasıl İncelenir?

API tarafında 400 teşhisi yapılırken request parçaları ayrı ayrı kontrol edilmelidir.

HTTP Metodunu Kontrol Edin

API endpoint’i:

POST /api/users

POST /api/users

beklerken yanlış method gönderiliyor olabilir.

Content-Type Değerini Kontrol Edin

JSON gönderen bir istemci çoğu durumda uygun içerik türünü belirtmelidir:

Content-Type: application/json

Content-Type: application/json

JSON Sözdizimini Doğrulayın

Hatalı JSON:

{
  "name": "Ahmet",
}

{
  "name": "Ahmet",
}

Geçerli JSON:

{
  "name": "Ahmet"
}

{
  "name": "Ahmet"
}

Sondaki gereksiz virgül bazı JSON parser’larında isteğin reddedilmesine neden olur.

Zorunlu Alanları Kontrol Edin

API şu yapıyı bekliyor olabilir:

{
  "name": "Ahmet",
  "email": "user@example.com"
}

{
  "name": "Ahmet",
  "email": "[email protected]"
}

İstemci yalnızca:

{
  "name": "Ahmet"
}

{
  "name": "Ahmet"
}

gönderiyorsa uygulama doğrulaması başarısız olabilir.

Sunucu Loglarıyla İsteği Eşleştirin

Client tarafında oluşturulan request ile backend loglarını eşleştirmek gerekir.

Şu sorular önemlidir:

İstek API’ye ulaşıyor mu?
JSON parser aşamasında mı hata oluşuyor?
Validation katmanı mı reddediyor?
Reverse proxy mi 400 döndürüyor?
Application response body ek hata açıklaması içeriyor mu?

Bu ayrım yapılmadan yalnızca HTTP koduna bakmak çoğu zaman yeterli değildir.

400 ile Diğer 4xx Hataları Arasındaki Farklar

400 tüm istemci problemlerini ifade eden tek hata kodu değildir.

HTTP Kodu	Temel anlam	Örnek durum
400 Bad Request	İstek hatalı veya kabul edilemez	Bozuk HTTP isteği
401 Unauthorized	Kimlik doğrulama gerekiyor/geçersiz	Eksik API token
403 Forbidden	Erişim reddedildi	Yetkisiz kaynak
404 Not Found	Kaynak bulunamadı	Hatalı endpoint
413 Content Too Large	Request body fazla büyük	Büyük dosya yükleme
414 URI Too Long	URI fazla uzun	Aşırı uzun query string
415 Unsupported Media Type	İçerik türü desteklenmiyor	Yanlış Content-Type
422 Unprocessable Content	İstek yapısal olarak anlaşılmış ancak içerik işlenemiyor	Validation hatası

Bu ayrım özellikle API tasarımında önemlidir.

Örneğin çok büyük bir dosya gönderildiğinde problemi “400 Bad Request” olarak genellemek yerine uygun koşullarda 413 Content Too Large kullanılması istemciye daha açıklayıcı bilgi sağlar.

Benzer şekilde gönderilen medya türü desteklenmiyorsa 415 Unsupported Media Type daha anlamlı olabilir.

400 Hatasını Çözerken Yapılmaması Gerekenler

400 hatasını düzeltmek amacıyla yapılan bazı müdahaleler problemi yalnızca gizleyebilir.

Özellikle şu yaklaşımlardan kaçınılmalıdır:

Nedenini araştırmadan header limitlerini yükseltmek,
Tüm ziyaretçilere cookie temizletmeyi kalıcı çözüm kabul etmek,
Uygulama loglarını incelemeden yalnızca NGINX yapılandırmasını değiştirmek,
Reverse proxy katmanını göz ardı etmek,
400, 413, 414 ve 422 kodlarını aynı hata kabul etmek,
Hassas Authorization header veya cookie değerlerini açık biçimde loglamak,
Her API validation hatasını otomatik olarak 400’e dönüştürmek.

Kalıcı çözüm için amaç hata mesajını ortadan kaldırmak değil, hangi request bileşeninin neden geçersiz hale geldiğini bulmak olmalıdır.

400 Bad Request Kontrol Listesi

400 hatasını sistematik biçimde teşhis etmek için şu sıra kullanılabilir:

Hata yalnızca bir kullanıcıda mı oluşuyor?
Gizli pencerede aynı problem devam ediyor mu?
Farklı cihaz ve tarayıcıda hata tekrarlanıyor mu?
Sadece belirli URL veya endpoint etkileniyor mu?
Cookie temizlendiğinde hata düzeliyor mu?
curl -v ile gerçek HTTP yanıtı doğrulandı mı?
Access log isteği görüyor mu?
Error log ek hata açıklaması içeriyor mu?
400 yanıtını proxy mi, web sunucusu mu, uygulama mı üretiyor?
Request header olağan dışı büyüklükte mi?
Cookie veya Authorization verisi büyümüş mü?
API’nin Content-Type değeri doğru mu?
JSON veya form verisi geçerli mi?
Zorunlu API alanları gönderiliyor mu?
Sorun aslında 413, 414, 415 veya 422 gibi daha spesifik bir HTTP durumu mu?
Yapılandırma değişiklikleri kök neden belirlendikten sonra mı yapılıyor?

Bu kontrol sırası, basit tarayıcı cookie probleminden reverse proxy ve API katmanına kadar farklı ihtimalleri sistematik olarak elemenizi sağlar.

Sonuç

400 Bad Request hatası, web sunucusunun istemciden aldığı HTTP isteğini geçersiz veya işlenemez gördüğünü ifade eder. Sorunun kaynağı bozuk HTTP yapısı, cookie/header büyüklüğü, yanlış API isteği veya reverse proxy katmanındaki bir uyumsuzluk olabilir.

Son kullanıcılar için gizli pencere, farklı tarayıcı ve siteye özgü cookie kontrolleri iyi bir başlangıçtır. Sunucu yöneticilerinin ise istemci → proxy → web sunucusu → uygulama zincirini izleyerek 400 yanıtını hangi bileşenin oluşturduğunu belirlemesi gerekir.

Web uygulamalarını VDS veya benzeri sunucu ortamlarında barındırırken yalnızca CPU ve RAM kaynakları değil; NGINX/Apache yapılandırması, reverse proxy mimarisi ve uygulamanın HTTP isteklerini nasıl işlediği de erişilebilirlik ve kararlılık açısından önemlidir. Hostider’ın ilgili sunucu çözümleri değerlendirilirken uygulamanın bu teknik gereksinimleri de sunucu planlamasına dahil edilebilir.

5. Sıkça Sorulan Sorular

400 Bad Request ne demek?

400 Bad Request, sunucunun istemciden gelen HTTP isteğinde bir problem bulunduğunu ve isteği işleyemediğini veya işlemeyi reddettiğini gösteren 4xx durum kodudur. Hatalı request yapısı, büyük cookie/header alanı veya geçersiz API verisi bu yanıta neden olabilir.

400 Bad Request hatası nasıl düzeltilir?

Son kullanıcıysanız URL’yi kontrol edin, gizli pencerede test yapın ve gerekirse yalnızca ilgili siteye ait cookie’leri temizleyin. Sunucu yöneticisiyseniz access/error loglarını inceleyerek 400 yanıtını hangi bileşenin oluşturduğunu belirleyin; ardından header, cookie, request body ve API formatını kontrol edin.

Cookie temizlemek 400 hatasını çözer mi?

Sorun bozuk veya aşırı büyük cookie verilerinden kaynaklanıyorsa evet. Özellikle site gizli pencerede çalışıyor ancak normal tarayıcı profilinde 400 dönüyorsa cookie’leri temizlemek anlamlıdır. Ancak hata sürekli tekrarlanıyorsa uygulamanın neden büyük veya hatalı cookie oluşturduğu ayrıca araştırılmalıdır.

NGINX neden 400 Bad Request hatası verir?

NGINX hatalı HTTP isteği, geçersiz request yapısı veya kabul ettiği header boyutunun aşılması gibi durumlarda 400 döndürebilir. Özellikle büyük Cookie veya Authorization header alanları client_header_buffer_size ve large_client_header_buffers ile ilişkili sınırların kontrol edilmesini gerektirebilir.

400 Bad Request sunucu hatası mı?

HTTP sınıflandırmasında 400 bir istemci hatasıdır. Bununla birlikte son kullanıcının mutlaka yanlış bir işlem yaptığı anlamına gelmez. Frontend yazılımının hatalı request üretmesi, proxy katmanındaki sorunlar veya uygulamayla uyumsuz sunucu limitleri de ziyaretçiye 400 olarak yansıyabilir.

400 ile 404 arasındaki fark nedir?

400, gönderilen isteğin geçersiz veya kabul edilemez olduğunu belirtir. 404 ise isteğin yapısı geçerli olsa bile istenen kaynağın bulunamadığını ifade eder. Örneğin geçerli biçimde gönderilen ancak mevcut olmayan /api/user/999 endpoint’i 404 döndürebilir.

400 ile 413 aynı hata mı?

Hayır. 400 genel olarak hatalı veya kabul edilemeyen bir isteği ifade ederken 413 Content Too Large, request içeriğinin sunucunun kabul ettiği boyutu aştığını belirtir. Büyük bir dosya yüklemesinde body sınırı aşılmışsa 413 daha spesifik ve açıklayıcı bir durum kodudur.

Görüntülenme: 1

Bu Yazıya Tepkiniz Ne Oldu?