🚀 go-pugleaf

W dniu 04-06-2010 15:58, Ghost pisze:
> W jaki sposob powinno sie komunikowac blad do aplikacji w przypadku np.
> nie przejscia jakiejs walidacji danych

0 - dana nie przeszła walidacji
1 - dana przeszła walidację

albo

Użytkowniku! Dana, którą wpisałeś w polu edycyjnym jest nieprawidłowa. 
Proszę, popraw lub wprowadź od nowa.

> ale juz na po stronie servera - czy
> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?

Znaczy się, chcesz powiedzieć, że podczas walidacji danych wywalił się 
serwer? :)

Pozdrawiam
Piotr

Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w wiadomości 
news:4c090d70$0$2600$65785112@news.neostrada.pl...
>W dniu 04-06-2010 15:58, Ghost pisze:

>> ale juz na po stronie servera - czy
>> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>
> Znaczy się, chcesz powiedzieć, że podczas walidacji danych wywalił się 
> serwer? :)

Znasz lepszy numer niz 500? To podaj, prosze. 

W dniu 04-06-2010 16:36, Ghost pisze:
>>> ale juz na po stronie servera - czy
>>> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>>
>> Znaczy się, chcesz powiedzieć, że podczas walidacji danych wywalił się
>> serwer? :)
>
> Znasz lepszy numer niz 500? To podaj, prosze.

Co to znaczy lepszy?

http://www.elider.pl/137_co_oznaczaja_kody_bledow_serwera_i_dlaczego_warto_je_znac.html

Błąd walidacji danych, to nie błąd w działaniu serwera. To nawet nie 
jest błąd w działaniu aplikacji na serwerze.

Ale oczywiście, możesz aplikację kliencką informować o błędzie walidacji 
numerem 500, jeżeli taką masz ochotę. Nie jest ważne co wyślesz w 
odpowiedzi, "źle", "dobrze", "dupa", ważne jak aplikacja zareaguje na 
komunikat. Jeżeli aplikacja zrozumie komunikat "500" jako błąd walidacji 
to i "500" będzie dobre.

Pozdrawiam
Piotr

Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w wiadomości 
news:4c09120f$0$19179$65785112@news.neostrada.pl...
>W dniu 04-06-2010 16:36, Ghost pisze:
>>>> ale juz na po stronie servera - czy
>>>> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>>>
>>> Znaczy się, chcesz powiedzieć, że podczas walidacji danych wywalił się
>>> serwer? :)
>>
>> Znasz lepszy numer niz 500? To podaj, prosze.
>
> Co to znaczy lepszy?

Lepiej oddajacy sytuacje, ze nie mozna bylo wykonac danej operacji bo 
costam-costam (walidacja to tylko przyklad).

> http://www.elider.pl/137_co_oznaczaja_kody_bledow_serwera_i_dlaczego_warto_je_znac.html
>
> Błąd walidacji danych, to nie błąd w działaniu serwera. To nawet nie jest 
> błąd w działaniu aplikacji na serwerze.
>
> Ale oczywiście, możesz aplikację kliencką informować o błędzie walidacji 
> numerem 500, jeżeli taką masz ochotę. Nie jest ważne co wyślesz w 
> odpowiedzi, "źle", "dobrze", "dupa", ważne jak aplikacja zareaguje na 
> komunikat. Jeżeli aplikacja zrozumie komunikat "500" jako błąd walidacji 
> to i "500" będzie dobre.

No wiec, ja sie zastanawiam nad dobrymi praktykami, bo to, ze w ogolnym 
przypadku moge to wiem. 

Dnia 04.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>
>> Ale oczywiście, możesz aplikację kliencką informować o błędzie walidacji 
>> numerem 500, jeżeli taką masz ochotę. Nie jest ważne co wyślesz w 
>> odpowiedzi, "źle", "dobrze", "dupa", ważne jak aplikacja zareaguje na 
>> komunikat. Jeżeli aplikacja zrozumie komunikat "500" jako błąd walidacji 
>> to i "500" będzie dobre.
>
> No wiec, ja sie zastanawiam nad dobrymi praktykami, bo to, ze w ogolnym 
> przypadku moge to wiem. 

Dobra praktyka to odpowieni forward błędu w protokole konkretnej warstwy.
Warstwa http przepycha do Ciebie 500/404 itd i Ty podejmujesz decyzje co z
tym robić dalej np dla 404 otwierasza jakiegoś defaulta albo pchasz ten błąd
wyżej w ostateczności na konsole usera np alert. Natomiast jak serwer odwalił
swoją robotę w http należycie, a przesyłasz błąd walidacji czegoś tam ze
serwera (Twojego np w cgi czy php) do klienta (Twój sktypt) to ubierz to w
swoje ramki.
Ja praktykuję wysyłanie danych w xml albo w poleceniach js (cel ajaxa w eval).
Wtedy błąd śle np w error='1.1 Błąd taki czy inny'; albo tag <blad/> dla xml

-- 
"A cóż to za sens kupować samochód, żeby jeździć po asfalcie? 
Tam, gdzie jest  asfalt, nie ma nic ciekawego,  a gdzie  jest 
coś ciekawego, tam nie ma asfaltu".
               Strugaccy - Poniedziałek zaczyna się w sobotę.

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał w 
wiadomości news:slrni0itsu.lv0.write-only-with-spf@dns.media-lab.com.pl...
> Dnia 04.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>>
>>> Ale oczywiście, możesz aplikację kliencką informować o błędzie walidacji
>>> numerem 500, jeżeli taką masz ochotę. Nie jest ważne co wyślesz w
>>> odpowiedzi, "źle", "dobrze", "dupa", ważne jak aplikacja zareaguje na
>>> komunikat. Jeżeli aplikacja zrozumie komunikat "500" jako błąd walidacji
>>> to i "500" będzie dobre.
>>
>> No wiec, ja sie zastanawiam nad dobrymi praktykami, bo to, ze w ogolnym
>> przypadku moge to wiem.
>
> Dobra praktyka to odpowieni forward błędu w protokole konkretnej warstwy.
> Warstwa http przepycha do Ciebie 500/404 itd i Ty podejmujesz decyzje co z
> tym robić dalej np dla 404 otwierasza jakiegoś defaulta albo pchasz ten 
> błąd
> wyżej w ostateczności na konsole usera np alert. Natomiast jak serwer 
> odwalił
> swoją robotę w http należycie, a przesyłasz błąd walidacji czegoś tam ze
> serwera (Twojego np w cgi czy php) do klienta (Twój sktypt) to ubierz to w
> swoje ramki.
> Ja praktykuję wysyłanie danych w xml albo w poleceniach js (cel ajaxa w 
> eval).
> Wtedy błąd śle np w error='1.1 Błąd taki czy inny'; albo tag <blad/> dla 
> xml

Widze, ze sie nie dogadujemy. Dam wiecej szczegolow. Uzywam, jqGrid i edycji 
inline. Ma on taka ciekawa wlasciwosc, ze gdy cos nie bardzo uda sie w 
komunikacji AJAXem, przywraca automatycznie stara wartosc linijki. Niestety 
"cos nie tak" to sytuacja kiedy server zwraca blad (z tych htmlowych, np. 
500). Stad moej pytanie czyda sie pod to podpinac. Troche ono akademickie bo 
oczywiscie sa sposoby by to obejsc. 

W dniu 05-06-2010 09:04, Ghost pisze:
> Widze, ze sie nie dogadujemy. Dam wiecej szczegolow. Uzywam, jqGrid i
> edycji inline. Ma on taka ciekawa wlasciwosc, ze gdy cos nie bardzo uda
> sie w komunikacji AJAXem, przywraca automatycznie stara wartosc linijki.

No to jeżeli pytasz o dobre praktyki: to jest dobra praktyka.

Już pisałem, jest różnica między błędem w komunikacji z serwerem, gdzie 
serwer cię informuje (odpowiednim kodem) o błędzie, błędem spowodowanym 
przez aplikację, a "informacją" do użytkownika, że popełnił błąd 
wprowadzając błędną wartość.

> Niestety "cos nie tak" to sytuacja kiedy server zwraca blad (z tych
> htmlowych, np. 500). Stad moej pytanie czyda sie pod to podpinac.

Sprecyzuj "to" i napisz "pod co" chcesz podpinać.

> Troche
> ono akademickie bo oczywiscie sa sposoby by to obejsc.

Sprecyzuj "to" do obchodzenia, bo nie rozumiem co chcesz obchodzić i 
dlaczego.

Przecież to od Ciebie zależy co zrobisz z błędem. Jak nie otrzymasz 
odpowiedzi z serwera możesz przerwać działanie, wyświetlić komunikat 
użytkownikowi "błąd połączenia", ponowić próbę połączenia, zmienić kolor 
tła czy co tam sobie wymyślisz.

Może po prostu napisz z czym konkretnie masz problem.

Pozdrawiam
Piotr

Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>
> komunikacji AJAXem, przywraca automatycznie stara wartosc linijki. 

Co oznacza 'przywraca automatycznie starą wartość linijki'??? bo tego nie
rozumiem. W wywołaniu ajax masz normalnie status z _pobrania danych_ ze
serwera i koniec, a czy w wyniku wykonywanie tego pobierania ten serwer
nie mógł się dogadać np z bazą to ajaxa g. to obchodzi, on odwalił swoją
robotę więc nią (tą robotą) wyśle np <blad id="1.1">Nie można połączyć
się z DB</blad>

> Niestety 
> "cos nie tak" to sytuacja kiedy server zwraca blad (z tych htmlowych, np. 
> 500). 

I tu jest Twój problem, bo błąd 500 nie jest błędem htmlowym tylko http-owym
jeśli już. Nie jest to błąd walidacji strony html tylko błąd w komunikacji ze
serwerem w protokole http. Podobnie chcesz wymieszać błędy.

> Stad moej pytanie czyda sie pod to podpinac. Troche ono akademickie bo 
> oczywiscie sa sposoby by to obejsc. 

Oczywiście że da się podpiąć, ale nie jest to 'dobra praktyka', a o to
pytałeś.

-- 
"A cóż to za sens kupować samochód, żeby jeździć po asfalcie? 
Tam, gdzie jest  asfalt, nie ma nic ciekawego,  a gdzie  jest 
coś ciekawego, tam nie ma asfaltu".
               Strugaccy - Poniedziałek zaczyna się w sobotę.

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał w 
wiadomości news:slrni0k1i7.8fs.write-only-with-spf@dns.media-lab.com.pl...
> Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>
>> komunikacji AJAXem, przywraca automatycznie stara wartosc linijki.
>
> Co oznacza 'przywraca automatycznie starą wartość linijki'??? bo tego nie
> rozumiem.

Sprzed edycji. Edycja linikjki w tabelce - enter, w celu zapisania, zonk, 
odtworzenie linijki.

>> Niestety
>> "cos nie tak" to sytuacja kiedy server zwraca blad (z tych htmlowych, np.
>> 500).
>
> I tu jest Twój problem, bo błąd 500 nie jest błędem htmlowym tylko 
> http-owym
> jeśli już.

Boze, upatrujesz problemow gdzie ich nie ma, oczywiscie zle napisalem, 
myslalem o http, a napilasem html.
.
>> Stad moej pytanie czyda sie pod to podpinac. Troche ono akademickie bo
>> oczywiscie sa sposoby by to obejsc.
>
> Oczywiście że da się podpiąć, ale nie jest to 'dobra praktyka', a o to
> pytałeś.

I wlasnie tego dotyczy pytanie - dlaczego nie jest?

Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w wiadomości 
news:4c0a023c$0$17100$65785112@news.neostrada.pl...
>W dniu 05-06-2010 09:04, Ghost pisze:

> Może po prostu napisz z czym konkretnie masz problem.

Przeciez napisalem, widze jednak, zes bardziej filozof niz "dobry praktyk" 

Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>
> Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał w 
> wiadomości news:slrni0k1i7.8fs.write-only-with-spf@dns.media-lab.com.pl...
>> Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>>
>>> komunikacji AJAXem, przywraca automatycznie stara wartosc linijki.
>>
>> Co oznacza 'przywraca automatycznie starą wartość linijki'??? bo tego nie
>> rozumiem.
>
> Sprzed edycji. Edycja linikjki w tabelce - enter, w celu zapisania, zonk, 
> odtworzenie linijki.

Co ma z tym wspólnego ajax? To czy zmienisz zawartość tabelki po błędzie czy
nie, to już nie robota ajaxa, tylko tego co w nim przyśle serwer.
ajax może sam wygenerować błąd np komunikacji, albo wykonać się dobrze, ale
błąd był w _wyższej warstwie_ więc powinien być w tej wartstwie opakowany.

>>> Niestety
>>> "cos nie tak" to sytuacja kiedy server zwraca blad (z tych htmlowych, np.
>>> 500).
>>
>> I tu jest Twój problem, bo błąd 500 nie jest błędem htmlowym tylko 
>> http-owym
>> jeśli już.
>
> Boze, upatrujesz problemow gdzie ich nie ma, oczywiscie zle napisalem, 
> myslalem o http, a napilasem html.

Ale ten problem jak ulał koresponduje z tym co chcesz zrobić.

>>> Stad moej pytanie czyda sie pod to podpinac. Troche ono akademickie bo
>>> oczywiscie sa sposoby by to obejsc.
>>
>> Oczywiście że da się podpiąć, ale nie jest to 'dobra praktyka', a o to
>> pytałeś.
>
> I wlasnie tego dotyczy pytanie - dlaczego nie jest?

Ponieważ podczas obsługi błedu http używasz statusu ajax, a sam ajax
wykonuje się prawidłowo (w sensie wywołania procedury na serwerze aplikacji i
powrocie danych do klienta aplikacji) więc dlaczego ma tam istnieć błąd?
Tam go nie ma. Generowanie 500 będzie powodowało że jakiś serwisant/wdrożeniowec
Twojej aplikacji zacznie szukać błędu nie tam gdzie powinien (hmm 500 wewnętrzny
błąd serwera - znaczy się apache coś klęka, procesy padają itd, jeszcze wmiesza
w problem sprzętowca). Gdy błąd jest w komunikacji np serwer aplikacji -> baza
danych - np ktoś zmienił hasło którym appsrv łączył się z bazą.
Druga sprawa to np obsługa takiej aplikacji przez proxy, które _może_ ingerować w
błędy http (jest pośrednikiem tej warstwy), natomiast nie powinno ingerować w treść
przesyłaną (w zawartość ajaxa, np Twojego xml z danymi do tableki czy js do
evalowania).

-- 
"A cóż to za sens kupować samochód, żeby jeździć po asfalcie? 
Tam, gdzie jest  asfalt, nie ma nic ciekawego,  a gdzie  jest 
coś ciekawego, tam nie ma asfaltu".
               Strugaccy - Poniedziałek zaczyna się w sobotę.

Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał w 
wiadomości news:slrni0k48m.8fs.write-only-with-spf@dns.media-lab.com.pl...
> Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>
>> Użytkownik "Sergiusz Rozanski" <write-only-with-spf@sergiusz.com> napisał 
>> w
>> wiadomości 
>> news:slrni0k1i7.8fs.write-only-with-spf@dns.media-lab.com.pl...
>>> Dnia 05.06.2010 Ghost <ghost@everywhere.pl> napisał/a:
>>>>
>>>> komunikacji AJAXem, przywraca automatycznie stara wartosc linijki.
>>>
>>> Co oznacza 'przywraca automatycznie starą wartość linijki'??? bo tego 
>>> nie
>>> rozumiem.
>>
>> Sprzed edycji. Edycja linikjki w tabelce - enter, w celu zapisania, zonk,
>> odtworzenie linijki.
>
> Co ma z tym wspólnego ajax?

Rencemnieopadaja - juz nic.

>> I wlasnie tego dotyczy pytanie - dlaczego nie jest?
>
> Ponieważ podczas obsługi błedu http używasz statusu ajax

Jak kiedys trafisz na jqGrid i uzyjesz edycji inline moze zrozumiesz o co 
biega. Sorry, widze, ze sie nie zrozumiemy. 

W dniu 05-06-2010 10:25, Ghost pisze:
> Przeciez napisalem, widze jednak, zes bardziej filozof niz "dobry praktyk"

Widzę jednak, że nie masz pojęcia o co pytasz.

"uzywac 500 Internal Server Error" i "walidacja danych".
Programista rzesz jego mać...

Pozdrawiam
Piotr

Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w wiadomości 
news:4c0a7f9f$0$2595$65785112@news.neostrada.pl...
>W dniu 05-06-2010 10:25, Ghost pisze:
>> Przeciez napisalem, widze jednak, zes bardziej filozof niz "dobry 
>> praktyk"
>
> Widzę jednak, że nie masz pojęcia o co pytasz.
>
> "uzywac 500 Internal Server Error" i "walidacja danych".
> Programista rzesz jego mać...

Dziecko, piszac stronki nawet z javascriptem, nigdy nie bedziesz 
programista.

PLONK 

W dniu 05-06-2010 21:06, Ghost pisze:
>> "uzywac 500 Internal Server Error" i "walidacja danych".
>> Programista rzesz jego mać...
>
> Dziecko, piszac stronki nawet z javascriptem, nigdy nie bedziesz
> programista.

Mistrzu nieodróżniający błędów serwera od błędów walidacji danych, nie 
dorastam ci do pięt.
Na szczęście.

Pozdrawiam
Piotr

Użytkownik "Ghost" <ghost@everywhere.pl> napisał w wiadomości 
news:hub0tu$o6b$2@mx1.internetia.pl...
> Witam,
>
>    W jaki sposob powinno sie komunikowac blad do aplikacji w przypadku np.
> nie przejscia jakiejs walidacji danych ale juz na po stronie servera - czy
> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>

Jeśli jest to błąd niezgodności formalnej parametrów GET lub POST (np. brak 
któregoś lub błąd deserializacji) to powinno się wystawić "Bad Request". Z 
założeniem jednak, że taki błąd "nie powinien nigdy wystapić", tzn. 
javascript i tak wychwyci go jeszcze przed wysłaniem żądania. Błędy logiki 
aplikacji powinny zaś już być normalną odpowiedzią z grupy 200.

> TIA
>
> Pozdrawiam,
> Ghost
> 

On 4 Cze, 15:58, "Ghost" <gh...@everywhere.pl> wrote:
> Witam,
>
>     W jaki sposob powinno sie komunikowac blad do aplikacji w przypadku np.
> nie przejscia jakiejs walidacji danych ale juz na po stronie servera - czy
> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>
> TIA
>
> Pozdrawiam,
> Ghost

Witam,
Nie widze powodu żeby się ciśnieniować, bo sprawa jest dość prosta.

Błąd walidacji to oznaka, że wszystko działa i odpowiednie dane
powinny zostać zwrócone z serwera np.  w postaci obiektu jsona

var erros = {'id_field' : "Komunikat bledu", 'id_field2' : "Komunikat
bledu"}

Natomiast po stronie JS może być zalozony globalny handler na
wszystkie requesty AJAXowe, ktory bedzie np. wyswietlac alert jesli
jakikolwiek status odpowiedzi z serwera jest innych niz 200.

http://ajaxpatterns.org/XMLHttpRequest_Call#Detecting_Errors

pozdro
keemor.com

Użytkownik "keemor" <keemor@gmail.com> napisał w wiadomości 
news:a3dda797-b80a-4c4d-bd75-1fdcc456ddc7@w31g2000yqb.googlegroups.com...
On 4 Cze, 15:58, "Ghost" <gh...@everywhere.pl> wrote:
>> Witam,
>
>> W jaki sposob powinno sie komunikowac blad do aplikacji w przypadku np.
>> nie przejscia jakiejs walidacji danych ale juz na po stronie servera - 
>> czy
>> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>>
>> TIA
>>
>> Pozdrawiam,
>> Ghost

>Witam,
>Nie widze powodu żeby się ciśnieniować, bo sprawa jest dość prosta.

>Błąd walidacji to oznaka, że wszystko działa i odpowiednie dane
>powinny zostać zwrócone z serwera np.  w postaci obiektu jsona

>var erros = {'id_field' : "Komunikat bledu", 'id_field2' : "Komunikat
>bledu"}

>Natomiast po stronie JS może być zalozony globalny handler na
>wszystkie requesty AJAXowe, ktory bedzie np. wyswietlac alert jesli
>jakikolwiek status odpowiedzi z serwera jest innych niz 200.

>http://ajaxpatterns.org/XMLHttpRequest_Call#Detecting_Errors


To co piszesz, to sa oczywiste, ogolnie znane informacje. Temat powstal ze 
wzgledu na specyficzne dzialanie jqGrid i tyle. Nie chce mi sie tego 
ponownie opisywac. EOT.

W dniu 2010-06-07 10:20, William Bonawentura pisze:
> Jeśli jest to błąd niezgodności formalnej parametrów GET lub POST (np.
> brak któregoś lub błąd deserializacji) to powinno się wystawić "Bad
> Request". Z założeniem jednak, że taki błąd "nie powinien nigdy
> wystapić", tzn. javascript i tak wychwyci go jeszcze przed wysłaniem
> żądania. Błędy logiki aplikacji powinny zaś już być normalną odpowiedzią
> z grupy 200.

SOAP wywala 500 przy każdym wyjątku po stronie serwera. Tak więc można 
dopuścić bardziej ogólną interpretację. Nie zmienia to faktu, że błędy 
walidacji są sytuacją normalną, więc chyba jednak nie powinny generować 
wyjątków, tylko np zwrócić listę niepoprawnie wypełnionych pól. Ja bym 
dopuścił 400 (czy 500) jeśli aplikacja spodziewa się tylko poprawnej 
odpowiedzi (format odpowiedzi nie przewiduje komunikatów błędów).

artur

W dniu 07-06-2010 20:16, Artur Muszyński pisze:
> SOAP wywala 500 przy każdym wyjątku po stronie serwera.

Zaraz, zaraz przecież "500 Internal Server Error" to kod odpowiedzi 
protokołu HTTP.
SOAP nie musi "chodzić" po HTTP.

Zawsze mi się wydawało, że SOAP to standard wymiany danych między 
aplikacjami i sam z siebie niczego nie wysyła. Jak serwer zdechnie i 
aplikacja się nie wykona to jak ta aplikacja wyśle komunikat w 
standardzie SOAP?

> Tak więc można
> dopuścić bardziej ogólną interpretację. Nie zmienia to faktu, że błędy
> walidacji są sytuacją normalną, więc chyba jednak nie powinny generować
> wyjątków, tylko np zwrócić listę niepoprawnie wypełnionych pól. Ja bym
> dopuścił 400 (czy 500) jeśli aplikacja spodziewa się tylko poprawnej
> odpowiedzi (format odpowiedzi nie przewiduje komunikatów błędów).

Hmmm...
Jaki wpływ ma aplikacja na generowane błędy przez serwer? Zakładam, że 
to nie aplikacja powoduje wysypanie się serwera.

Pozdrawiam
Piotr

Użytkownik "Artur Muszyński" <arturm@union.wytnijto.com.pl> napisał w 
wiadomości news:hujd62$hv2$1@mx1.internetia.pl...
>W dniu 2010-06-07 10:20, William Bonawentura pisze:
>> Jeśli jest to błąd niezgodności formalnej parametrów GET lub POST (np.
>> brak któregoś lub błąd deserializacji) to powinno się wystawić "Bad
>> Request". Z założeniem jednak, że taki błąd "nie powinien nigdy
>> wystapić", tzn. javascript i tak wychwyci go jeszcze przed wysłaniem
>> żądania. Błędy logiki aplikacji powinny zaś już być normalną odpowiedzią
>> z grupy 200.
>
> SOAP wywala 500 przy każdym wyjątku po stronie serwera. Tak więc można 
> dopuścić bardziej ogólną interpretację. Nie zmienia to faktu, że błędy 
> walidacji są sytuacją normalną, więc chyba jednak nie powinny generować

Błąd walidacji np. pole "imię" jest puste => odpowiedź 200
Błąd formalny parametru np. pole "imię" nie zostało w ogóle wysłane (źle 
opracowano formularza lub kod) => odpwiedź 400

> wyjątków, tylko np zwrócić listę niepoprawnie wypełnionych pól. Ja bym 
> dopuścił 400 (czy 500) jeśli aplikacja spodziewa się tylko poprawnej 
> odpowiedzi (format odpowiedzi nie przewiduje komunikatów błędów).
>
> artur

IMHO każdy błąd 500 w logu powinien trafić do logu i być analizowany przez 
serwis / wdrożenie. 

W dniu 2010-06-08 07:52, William Bonawentura pisze:
> IMHO każdy błąd 500 w logu powinien trafić do logu i być analizowany
> przez serwis / wdrożenie.

To się zgadza. Poważnie napisany soft ma na pewno włączone logowanie 
błędów/wyjątków.

Pozdrawiam,

Artur Muszyński

W dniu 2010-06-08 07:39, Kviat pisze:
> W dniu 07-06-2010 20:16, Artur Muszyński pisze:
>> SOAP wywala 500 przy każdym wyjątku po stronie serwera.
>
> Zaraz, zaraz przecież "500 Internal Server Error" to kod odpowiedzi
> protokołu HTTP.
> SOAP nie musi "chodzić" po HTTP.

Pewnie jeśli chodzi po RPC, to używa natywnych mechanizmów RPC. Nie 
wiem, nie zagłębiałem się. Odpal sniffera, jak masz wątpliwości.

> Zawsze mi się wydawało, że SOAP to standard wymiany danych między
> aplikacjami i sam z siebie niczego nie wysyła. Jak serwer zdechnie i
> aplikacja się nie wykona to jak ta aplikacja wyśle komunikat w
> standardzie SOAP?

Ale nie wyśle też odpowiedzi ze statusem 200, a tylko taka traktowana 
jest jako poprawna. XML sam w sobie nie zawiera natywnego sposobu 
reprezentowania sytuacji błędnej. Jeżeli na przykład jakiś komponent 
obsługuje generyczne źródła danych XML, to ustawienie statusu <> 200 w 
przypadku wyjątku na serwerze jest najskuteczniejszym sposobem zarówno 
na odpowiednie potraktowanie tego faktu przez oprogramowanie serwera 
(zapis do error logu), jak i przez klienta (zignorowanie odpowiedzi). Z 
punktu widzenia klienta nie jest ważny powód - ważne jest, że 
spodziewana odpowiedź nie może nadejść.

artur

W dniu 08-06-2010 09:45, Artur Muszyński pisze:
>>> SOAP wywala 500 przy każdym wyjątku po stronie serwera.
>>
>> Zaraz, zaraz przecież "500 Internal Server Error" to kod odpowiedzi
>> protokołu HTTP.
>> SOAP nie musi "chodzić" po HTTP.
>
> Pewnie jeśli chodzi po RPC, to używa natywnych mechanizmów RPC. Nie
> wiem, nie zagłębiałem się. Odpal sniffera, jak masz wątpliwości.

Ale jakich wątpliwości?

Pytanie brzmi: w jaki sposób "SOAP wywala 500" skoro SOAP to tylko 
standard wymiany danych?

>
>> Zawsze mi się wydawało, że SOAP to standard wymiany danych między
>> aplikacjami i sam z siebie niczego nie wysyła. Jak serwer zdechnie i
>> aplikacja się nie wykona to jak ta aplikacja wyśle komunikat w
>> standardzie SOAP?
>
> Ale nie wyśle też odpowiedzi ze statusem 200,

Jak się serwer wywali, to chyba oczywiste, że aplikacja działająca na 
tym serwerze *nic nie wyśle*, ponieważ *się nawet nie uruchomi*.

> a tylko taka traktowana
> jest jako poprawna. XML sam w sobie nie zawiera natywnego sposobu
> reprezentowania sytuacji błędnej. Jeżeli na przykład jakiś komponent
> obsługuje generyczne źródła danych XML, to ustawienie statusu <> 200 w
> przypadku wyjątku na serwerze jest najskuteczniejszym sposobem zarówno
> na odpowiednie potraktowanie tego faktu przez oprogramowanie serwera
> (zapis do error logu), jak i przez klienta (zignorowanie odpowiedzi). Z
> punktu widzenia klienta nie jest ważny powód - ważne jest, że
> spodziewana odpowiedź nie może nadejść.

Coś mi się wydaje, że mówiąc o serwerze mamy na myśli dwie różne sprawy, 
stąd chyba niezrozumienie.

Aplikacja na serwerze (np.PHP) -> Serwer (np.Apache, IIS, AOLserver) 
<- http (może być xml SOAP) -> Aplikacja kliencka (np. JavaScript w 
przeglądarce czy desktop pod win napisany w Delphi)


Serwer (np.Apache) nie dokonuje walidacji przesyłanych danych.
A skoro walidację przeprowadza aplikacja php, to w przypadku 
niepowodzenia, nie wydaje mi się żeby to było logiczne, aby w odpowiedzi 
aplikacja generowała "500 Internal Server Error" skoro Apache żyje (jak 
i jego moduły łącznie z php) i ma się dobrze.

Dlatego związek "500 Internal Server Error" i "walidacja danych" wydał 
mi się co najmniej dziwny.
No i dodatkowo opakowanie danych w SOAP (xml) również nie ma znaczenia 
dla działania serwera.

Pozdrawiam
Piotr

W dniu 2010-06-08 15:32, Kviat pisze:
> Pytanie brzmi: w jaki sposób "SOAP wywala 500" skoro SOAP to tylko
> standard wymiany danych?

Przeczytaj specyfikację SOAP (HTTP binding).

> Dlatego związek "500 Internal Server Error" i "walidacja danych" wydał
> mi się co najmniej dziwny.

Ja też bym generalnie nie podpinał walidacji pod błąd serwera, co 
napisałem w pierwszym poście, ale czy nie wolno tego zrobić, tego nie 
umiem rozstrzygnąć.
RFC stwierdza tylko, że status 500 oznacza, że serwer nie może poprawnie 
wykonać żądania (z dodatkowym ważnym słowem unexpected). Nie ma 
rozróżnienia między Apache/moduły/skrypty.

artur

W dniu 08-06-2010 22:15, Artur Muszyński pisze:
> W dniu 2010-06-08 15:32, Kviat pisze:
>> Pytanie brzmi: w jaki sposób "SOAP wywala 500" skoro SOAP to tylko
>> standard wymiany danych?
>
> Przeczytaj specyfikację SOAP (HTTP binding).

Hmmm...
http://www.w3schools.com/soap/soap_httpbinding.asp

"SOAP HTTP Binding
A SOAP method is an HTTP request/response that complies with the SOAP 
encoding rules.
HTTP + XML = SOAP
A SOAP request could be an HTTP POST or an HTTP GET request."

To, że http jest opakowywany w xml (czyli właśnie SOAP) nie powoduje 
tego, że SOAP może coś wywalać.

Jak sobie opakuję http w JSONa to JSON będzie wywalać "500 Internal 
Server Error"?

Przecież serwer może się wywalić niezależnie od tego czym wyślę dane, 
jak wyślę, a już szczególnie nie widzę powodu, żeby opakowanie danych 
sypało komunikatami serwera.

Jak dostanę z serwera (na przykład):
1) czystym tekstem:
500 Internal Serwer Error
2) w xml:
<error>500 Internal Serwer Error</error>

to w drugim przypadku daleki będę od stwierdzenia, że mi xml wywalił 
błędem, tylko dlatego, że komunikat z serwera został opakowany w xmla.

Albo ja nadal czegoś nie rozumiem :)


>> Dlatego związek "500 Internal Server Error" i "walidacja danych" wydał
>> mi się co najmniej dziwny.
>
> Ja też bym generalnie nie podpinał walidacji pod błąd serwera, co
> napisałem w pierwszym poście, ale czy nie wolno tego zrobić, tego nie
> umiem rozstrzygnąć.
> RFC stwierdza tylko, że status 500 oznacza, że serwer nie może poprawnie
> wykonać żądania (z dodatkowym ważnym słowem unexpected). Nie ma
> rozróżnienia między Apache/moduły/skrypty.

No tu mam odmienne zdanie.
Odpowiedź z serwera:
1) Dana dobra (serwer: 200 OK)
lub
2) Dana zła (nadal serwer: 200 OK)

oznacza dla mnie, że nie dość, że aplikacja (po stronie serwera) daną 
zwalidowała poprawnie (uściślę: proces walidacji przebiegł poprawnie, 
albo inaczej: procedura walidująca nie zabiła serwera i zwróciła jeden z 
oczekiwanych przeze mnie wyników), to dodatkowo *serwer poprawnie 
żądanie wykonał* bo inaczej nie dostałbym od tej aplikacji odpowiedzi.

a jakbym dostał tylko:
3) serwer: 500 Internal Server Error

to mam zgadywać, że dana była zła? A może jednak była dobra tylko serwer 
się wywalił?

No i na koniec :)
Kompletnie nielogiczne jest, że od serwera, który *poprawnie wykonał 
żądanie* otrzymam odpowiedź: 500 "nie może poprawnie wykonać żądania".

Pozdrawiam
Piotr

W dniu 2010-06-04 16:36, Ghost pisze:
>
> Użytkownik "Kviat" <kviat@NIE_DLA_SPAMUneostrada.pl> napisał w
> wiadomości news:4c090d70$0$2600$65785112@news.neostrada.pl...
>> W dniu 04-06-2010 15:58, Ghost pisze:
>
>>> ale juz na po stronie servera - czy
>>> wyrzucanie po prosti 500 jest wskazane? Czy raczej nie?
>>
>> Znaczy się, chcesz powiedzieć, że podczas walidacji danych wywalił się
>> serwer? :)
>
> Znasz lepszy numer niz 500? To podaj, prosze.

Jak już koniecznie chcesz coś innego niż 200 to wybierz sobie coś z 4xx 
(może 406).

5xx to błąd serwera, a to klient wysłał złe dane.

-- 
yew

W dniu 2010-06-09 00:09, Kviat pisze:
>> Przeczytaj specyfikację SOAP (HTTP binding).
>
> Hmmm...
> http://www.w3schools.com/soap/soap_httpbinding.asp

http://www.w3.org/TR/2007/REC-soap12-part2-20070427/#soapinhttp

"This binding of SOAP to HTTP is intended to make appropriate use of 
HTTP as an application protocol. For example, successful responses are 
sent with status code 200 or 202, and failures are indicated as 4XX or 5XX."

artur

W dniu 09-06-2010 20:25, Artur Muszyński pisze:
> W dniu 2010-06-09 00:09, Kviat pisze:
>>> Przeczytaj specyfikację SOAP (HTTP binding).
>>
>> Hmmm...
>> http://www.w3schools.com/soap/soap_httpbinding.asp
>
> http://www.w3.org/TR/2007/REC-soap12-part2-20070427/#soapinhttp
>
> "This binding of SOAP to HTTP is intended to make appropriate use of
> HTTP as an application protocol. For example, successful responses are
> sent with status code 200 or 202, and failures are indicated as 4XX or
> 5XX."

Czyli opakowana w SOAP odpowiedź w http, jest wysyłana *z kodem*. Z 
kodem wygenerowanym przez serwer. Nie przez SOAP.

Pozdrawiam
Piotr

W dniu 2010-06-09 22:11, Kviat pisze:
>> "This binding of SOAP to HTTP is intended to make appropriate use of
>> HTTP as an application protocol. For example, successful responses are
>> sent with status code 200 or 202, and failures are indicated as 4XX or
>> 5XX."
>
> Czyli opakowana w SOAP odpowiedź w http, jest wysyłana *z kodem*. Z
> kodem wygenerowanym przez serwer. Nie przez SOAP.

Nie jesteśmy na seminarium naukowym :-) Skoro wszystko jasne, to EOT?

artur

W dniu 11-06-2010 08:59, Artur Muszyński pisze:
> Nie jesteśmy na seminarium naukowym :-) Skoro wszystko jasne, to EOT?

Jasne :)

Pozdrawiam
Piotr