---

Er der en der kan forklare forskellen og også gerne fortælle mig, hvornår
man bruger de to forskellige metoder?

/Henrik

---

> Er der en der kan forklare forskellen og også gerne fortælle mig, hvornår
> man bruger de to forskellige metoder?

Ved Get sendes alle informationer i din form i query string'en
(addressebaren). Det er således muligt at aflæse f.eks et
kodeordsfelt og anden information. Der er såvidt jeg ved en
begrænsning på omkring 2000 tegn i adressebaren, så det er også en
begrænsning.

Ved Post bliver det sendt direkte til serveren, fra din browser. Der
er her ingen begrænsninger. Det er også sikkert, da ingen kan aflæse
informationen.

Jeg bruger altid Post, da jeg endnu ikke har set nogen grund til at
bruge Get.

Mvh Mark

---
Postet via www.improve.dk

---

<SNIP>
> Ved Post bliver det sendt direkte til serveren, fra din browser. Der
> er her ingen begrænsninger. Det er også sikkert, da ingen kan aflæse
> informationen.
>
At det er sikkert er ikke helt korrekt - data sendes nemlig ikke krypteret,
så der er en mulighed for sniffe sig til de data der sendes til serveren.

Mvh.
Morten Jokumsen
http://www.dotnetforum.dk

---

> At det er sikkert er ikke helt korrekt - data sendes nemlig ikke krypteret,
> så der er en mulighed for sniffe sig til de data der sendes til serveren.

Sikkert er selvfølgelig en relativ størrelse :).

---
Postet via www.improve.dk

---

Mark S. Rasmussen skrev:

> Jeg bruger altid Post, da jeg endnu ikke har set nogen grund
> til at bruge Get.

Så skal jeg prøve at give dig et par stykker:

<http://www.google.com/search?q=get+method>

<http://www.dsn.dk/cgi-bin/ordbog/ronet?M=1&P=post>

<http://www3.idlesurf.net/drsearch.php?query=opera>

Alle ovenstående links er kun mulige at give fordi der benyttes Get
i de respektive formularer.

Med Get ligger værdierne fra en form direkte i URI'en. Det giver
mulighed for at man kan lave direkte link til fx søgninger. Det gør
det også muligt at gå direkte til en resultatside uden at skulle
indtaste noget på en formside.

Post er velegnet til at gemme data samt at håndtere beskyttede
data. Get er bl.a. god til søgesider.

--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO - www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns928BEACE3BE3Ejcdmfdk@212.242.40.196...
> Mark S. Rasmussen skrev:
>
> Med Get ligger værdierne fra en form direkte i URI'en. Det giver
> mulighed for at man kan lave direkte link til fx søgninger. Det gør
> det også muligt at gå direkte til en resultatside uden at skulle
> indtaste noget på en formside.
>
Netop her bruger jeg get-metoden meget, nemlig når jeg selv skal have
overført nogle variable, altså ikke brugerinput.
Hvis du for eksempel viser en oversigt over et eller andet fra en database,
hvor hver ting vises mere udførligt på en anden side ex. ved klik på et
link, ja så kan man tage den pågældende id med sig ved at bygge den ind i
linket, hurtigt og nemt.
- selvfølgelig skal man så huske at overveje om det er variable som brugeren
godt må se....

MVH
Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote in message news:am6kf6$bbq$1@sunsite.dk...
>
> - selvfølgelig skal man så huske at overveje om det er variable som brugeren
> godt må se....

.... eller som brugeren har BRUG for at se? ,-) Jeg fik en hjerneblødning om emnet
tidligere på året og skrev http://www.hinnerup.net/2002/articles/uri/

/Tobias

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net> skrev i en meddelelse
news:am6r0r$2si$1@news.cybercity.dk...
>
> "Chrisser" <cbj@egdatainform.dk> wrote in message
news:am6kf6$bbq$1@sunsite.dk...
> >
> > - selvfølgelig skal man så huske at overveje om det er variable som
brugeren
> > godt må se....
>
> ... eller som brugeren har BRUG for at se? ,-) Jeg fik en hjerneblødning
om emnet
> tidligere på året og skrev http://www.hinnerup.net/2002/articles/uri/
>
> /Tobias
>
Hmmm, jeg har skimmet din artikel, og så vidt jeg kan se omhandler den
[citat] ..kunsten at lave holdbare url'er... [citat slut]

Yep, det har du sikkert ret i selv om jeg ikke har skænket dette område
mange tanker - har vel ikke haft brug for det -
men øhhh, hvad har det at gøre med de argumenter der kan sættes på med
get-metoden ??
Jeg har prøvet at udlæse argumenter som jeg ikke har sat på, jeg har også
prøvet at sætte argumenter på som jeg efterfølgende ikke udlæser osv.
Det er selvfølgelig dumt, men det jeg vil frem til, er at det endnu ikke er
lykkedes mig at fremprovokere fejl 404 ved brug af get-metoden....
Ret mig hvis jeg tager fejl

Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote in message news:am6sv8$f7n$1@sunsite.dk...
>
> Hmmm, jeg har skimmet din artikel

Artiklen omhandler det at bruge URI som brugergrænseflade, hvilket er relevant i
forbindelse med specielt GET's, der som bekendt forvansker en URI betydeligt. Det
oprindelige spørgsmål gik på hvad der er bedst at bruge (hhv GET/POST), og derfor er
artiklen i høj grad relevant.

.... lad mig bare anbefale én gang til at læse den ,-)

/Tobias

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net> escribió

> ... lad mig bare anbefale én gang til at læse den ,-)

Artiklen handler vel stort som om at lave URI's der holder i fremtiden
(aufhaengig af aktuelle fil-typer og struktur paa serveren). At GET er godt
eller skidt bliver der ikke sagt noget om.
Get behoever ikke at forvanske en URI, den bliver maaske mere kompliceret,
men ikke noedvendigvis forvansket.

---

Tobias Hinnerup wrote in news:am6vf1$7sv$1@news.cybercity.dk:

> "Chrisser" <cbj@egdatainform.dk> wrote in message
> news:am6sv8$f7n$1@sunsite.dk...
>>
>> Hmmm, jeg har skimmet din artikel
>
> Artiklen omhandler det at bruge URI som brugergrænseflade, hvilket er
> relevant i forbindelse med specielt GET's, der som bekendt forvansker
> en URI betydeligt.

Hvorfor "forvansker" anvendelsen af GET i en form en URI ?

> Det oprindelige spørgsmål gik på hvad der er bedst
> at bruge (hhv GET/POST), og derfor er artiklen i høj grad relevant.

uden at komme ind på en diskussion af indholdet i din artikel, så vil jeg
mene, at den er relevant i det øjeblik man _har_ besluttet sig for enten
at anvende GET eller POST ... men ikke under selve overvejelserne om,
hvad der skal vælges. Artiklen er jo lige "relevant" om man vælger det
ene eller det andet.

> ... lad mig bare anbefale én gang til at læse den ,-)

....

--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <jespers@stocholm.invalid> wrote in message
news:Xns928C7ED1B36B2spamstocholmdk@130.226.1.34...
>
> uden at komme ind på en diskussion af indholdet i din artikel, så vil jeg
> mene, at den er relevant i det øjeblik man _har_ besluttet sig for enten
> at anvende GET eller POST ... men ikke under selve overvejelserne om,
> hvad der skal vælges. Artiklen er jo lige "relevant" om man vælger det
> ene eller det andet.

I og med at resultatet af valget af GET frem for POST kan producere URI der f.eks. ligner
http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&lr=&ie=UTF-8 (den er grim,
hvia nogen er i tvivl!), så er det da bestemt også noget der skal med i overvejelserne
inden man beslutter sig for at bruge GET? Men jow, vist så er den da også gyldig bagefter


/Tobias

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net>

> I og med at resultatet af valget af GET frem
> for POST kan producere URI der f.eks. ligner
> http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&lr=&ie=UTF-8
> (den er grim, hvia nogen er i tvivl!),

Nej, den er kompliceret, men den er da meget informativ.

Med venlig hilsen
Lars Hoffmann

---

Tobias Hinnerup skrev:

> Artiklen omhandler det at bruge URI som brugergrænseflade,
> hvilket er relevant i forbindelse med specielt GET's, der som
> bekendt forvansker en URI betydeligt.

Undskyld - jeg er ikke helt med. Hvad mener du med forvansker?

> Det oprindelige spørgsmål gik på hvad der er bedst at bruge (hhv
> GET/POST), og derfor er artiklen i høj grad relevant.


Ja - derfor er det en skam at din server tilsyneladende har
kvababbelser.

> ... lad mig bare anbefale én gang til at læse den ,-)

Jeg fandt den via Googles cache - har dog ikke læst det hele. Men
jeg kan forstå at du argumenterer for at skjule så meget af
adressen som muligt, af hensyn til holdbarheden af links.

Til det vil jeg tilføje at ideen måske er meget god, men at det
måske ikke altid er så relevant at ethvert muligt link også virker
om 2 år. Specielt vanskeligt er det hvis man ikke på forhånd kan
vide hvad der søges på. Jeg har lavet en udgave hvor søgningen
fungerer via en særlig 404-side, men det er ikke særlig elegant
(jeg kunne ikke finde andre måder at gøre det på alligevel).

Et site som Google bruger da også querystring til at overføre
søgestrengen - jeg kan ikke helt se problemet.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> wrote in message
news:Xns928C7F901284Ejcdmfdk@193.88.15.213...
>
> Ja - derfor er det en skam at din server tilsyneladende har
> kvababbelser.

Serveren har nu ikke været vendt i et par dage, og så vidt jeg kan teste mig frem, er der
hul igennem til den både fra Nørrebronx, Thailand og Hørsholm.

> Jeg fandt den via Googles cache

Den er genial, den cache!

> - har dog ikke læst det hele. [SNIP]
> Et site som Google bruger da også querystring til at overføre
> søgestrengen - jeg kan ikke helt se problemet.

Læs det hele! *gG* Hvis du lægger mærke til google i øvrigt, vil du også se at de har
fjernet filtype-angivelserne fra alle deres URI'er - og fortæl mig nu ikke, at du synes at
en URI som http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&lr=&ie=UTF-8 er
et eksempel på et godt gennemtænkt brugerinterface? *lol*

/Tobias

---

On Tue, 17 Sep 2002 12:32:23 +0200, "Jens Gyldenkærne Clausen"
<jens@gyros.invalid> wrote:

>Men
>jeg kan forstå at du argumenterer for at skjule så meget af
>adressen som muligt, af hensyn til holdbarheden af links.

Vel nærmere at adressen ikke er "teknologi-afhængig" (.asp, .aspx,
..php, .shtml, cgi etc.)

<snip>

>Et site som Google bruger da også querystring til at overføre
>søgestrengen - jeg kan ikke helt se problemet.

Ja, men ikke .asp, .php eller hvad de nu bruger:
http://www.google.com/search?hl=da osv.

Jeg synes Tobias har en god pointe - bare ikke til
GET/POST-diskussionen

--
Jørn Andersen,
Brønshøj

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net> skrev i en meddelelse
news:am6vf1$7sv$1@news.cybercity.dk...
> Artiklen omhandler det at bruge URI som brugergrænseflade, hvilket er
relevant i
> forbindelse med specielt GET's, der som bekendt forvansker en URI
betydeligt. Det
> oprindelige spørgsmål gik på hvad der er bedst at bruge (hhv GET/POST), og
derfor er
> artiklen i høj grad relevant.
>
> ... lad mig bare anbefale én gang til at læse den ,-)
>
> /Tobias
>
Som jeg skrev før, så vidt jeg ved, så forvansker alt det man tilføjer efter
"?" ikke url'en, det kan højst forvanske koden hvis man ikke holder tungen
lige i munden !
- så jeg ser stadig ikke din kobling til get/post ....

Som jeg ser get/post, og som der kan læses i diverse bøger, så bruges post i
forbindelse med afsending af formularer og behandling af disse.( Formularer
bruges i forbindelse med brugerinput.)
Post data bliver sendt som en del af HTTP-bodyen, og læses i asp ved
Request.Form("mitFelt").

Get kan også bruges i forbindelse med formularer, men den bruges også til
direkte at overføre variable mellem to sider.
Get data bliver sendt som en del af url'en, og er oftest en forespørgsel om
information beliggende på den pågældende url. De læses i asp ved
Request.QueryString("minVariabel")

For mig at se bliver resultatet at man bruger post/get alt efter hvad det er
man i en given situation vil.


Chrisser

---

"Chrisser" <cbj@egdatainform.dk> wrote in message news:am71k3$2k2$1@sunsite.dk...
> >
> Som jeg skrev før, så vidt jeg ved, så forvansker alt det man tilføjer efter
> "?" ikke url'en, det kan højst forvanske koden hvis man ikke holder tungen
> lige i munden !
> - så jeg ser stadig ikke din kobling til get/post ....

Hvis ikke du synes at en URI som f.eks.
http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&lr=&ie=UTF-8 er forvansket,
så fred være med dig

> For mig at se bliver resultatet at man bruger post/get alt efter hvad det er
> man i en given situation vil.

Enighed erklæret.

/Tobias

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net> skrev i en meddelelse
news:am72v5$bau$1@news.cybercity.dk...

> Hvis ikke du synes at en URI som f.eks.
> http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&lr=&ie=UTF-8
er forvansket,
> så fred være med dig
>
> > For mig at se bliver resultatet at man bruger post/get alt efter hvad
det er
> > man i en given situation vil.
>
> Enighed erklæret.
>
> /Tobias
>
Jo tak det er den også ( freden altså ), og nu har jeg såmænd også læst
din artikel, og har derfor fattet essencen din... ( om filnavne i det hele
taget skal med på url'en)
Jeg forstår fint hvor du vil hen, men problemet er klart mest relevant hvis
man skal programmere et site som man forventer at folk der er lige så
kritiske som du selv vil linke til.
Jeg tror ikke almindelige mennesker tænker over det med filnavne, og det er
jo også lovligt hvis man skifter teknologi ( eller flytter sine sider ) at
omdirigere brugerne til de nye sider.
Selv sidder jeg og laver webbaserede dele til et internt
administrations-system, så jeg behøver/vil ikke tage stilling til det
forløbig.
PS: Hvis du så også har nogle gode alternativer til os "get-fans", så kunne
det jo være at nogle blev overbevist

MVH
Chrisser

---

On Tue, 17 Sep 2002 13:34:37 +0200, "Chrisser" <cbj@egdatainform.dk>
wrote:

>Jeg forstår fint hvor du vil hen, men problemet er klart mest relevant hvis
>man skal programmere et site som man forventer at folk der er lige så
>kritiske som du selv vil linke til.

Det er vel ikke det, der er problemet, men snarere hvor stor ravage
man laver, *når* (ikke *hvis*) man skal lave et teknologi-skift.

Den almindelige bruger kan jo i princippet være ligeglad med, hvordan
URI'en ser ud, men derimod ikke med om den også holder om 2 år.

>Jeg tror ikke almindelige mennesker tænker over det med filnavne, og det er
>jo også lovligt hvis man skifter teknologi ( eller flytter sine sider ) at
>omdirigere brugerne til de nye sider.

Hvordan vil du omdirigere:
www.domain.tld/minside.asp
hvis du fx har skiftet til PHP eller ASP.Net - og du ikke selv har
mulighed for at konfigurere server?
- for ikke at snakke om:
www.domain.tld/minside.asp?navn=finn&postnr=9900

- så har du måske (sandsynligvis) ikke længere ASP-sider.

>Selv sidder jeg og laver webbaserede dele til et internt
>administrations-system, så jeg behøver/vil ikke tage stilling til det
>forløbig.

Intranet har sine helt egne love/lovløsheder

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

> Den almindelige bruger kan jo i princippet være ligeglad med,
> hvordan URI'en ser ud, men derimod ikke med om den også holder
> om 2 år.

Det virker som om at du (m.fl.) vægter alle URI'er ens. For mig er
der stor forskel på at have en langtidsholdbar URI til en egentlig
hjemmeside (fx kontaktsiden på et site, nyhedsredaktionens side
etc.), og så et forsøg på at langtidssikre ethvert link. Har man fx
et varekatalog med 5000 dippedutter på nettet - så er jeg ret
ligeglad med at en bruger måske skal rette sit link fra
<www.minserver.dk/katalog.asp?dippedutID=2345> til hvad den nu
måtte hedde i et nyt system - sålænge han stadig kan finde
oversigten på eksempelvis <www.minserver.dk/katalog/>.

Skillelinjen går for mit vedkommende nogenlunde der hvor man selv
lister adresserne. Det vil sige at alle links jeg eksplicit angiver
gerne skulle kunne holde i lang tid, mens de links som en bruger
selv opsnapper ved at aflæse URI'en i adresselinjen står for denne
brugers eget ansvar.

Hvis det gør mig til en skidt programmør må jeg leve med det .

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

On Tue, 17 Sep 2002 14:15:53 +0200, "Jens Gyldenkærne Clausen"
<jens@gyros.invalid> wrote:

>Det virker som om at du (m.fl.) vægter alle URI'er ens. For mig er
>der stor forskel på at have en langtidsholdbar URI til en egentlig
>hjemmeside (fx kontaktsiden på et site, nyhedsredaktionens side
>etc.), og så et forsøg på at langtidssikre ethvert link.

Det er jeg selvfølgelig enig i, så længe vi snakker fx varekatalog
o.l.. Men der kan være en del "grænse-tilfælde", hvor svaret ikke er
så enkelt - fx en artikeldatabase (a la Tobias' eksempel).

Her vil der være et stort behov for langtidsholdbarhed. Om
langtidsholdbarheden så opnås ved Tobias' metode eller ved at der er
en gennemskuelig "oversættelse" fra gammel til ny standard må være en
afvejning af hvilke ressourcer man har til rådighed. - Men jeg har i
hvert fald et par stykker, hvor jeg efter at have læst Tobias' artikel
nok vil gennemtænke strukturen lidt grundigere næste gang der skal
omstruktureres.

Spørgsmålet er selvfølgelig, hvor meget brugerne får ud af fx:
<URL: http://webreview.com/2001/03_16/webauthors/index01.shtml>
- en lidt "nørdet" bruger vil sagtens kunne gennemskue, at man skal
kigge efter en artikel fra 16. marts 2001, men standardbrugerne vil
næppe.

>Skillelinjen går for mit vedkommende nogenlunde der hvor man selv
>lister adresserne. Det vil sige at alle links jeg eksplicit angiver
>gerne skulle kunne holde i lang tid, mens de links som en bruger
>selv opsnapper ved at aflæse URI'en i adresselinjen står for denne
>brugers eget ansvar.

Den skillelinie vil jeg sagtens kunne leve med - det ændrer bare ikke
ved, at du vil opleve brugere, der "går forgæves".

>Hvis det gør mig til en skidt programmør må jeg leve med det .

Slet ikke - det vigtigste er efter min ringe mening, at man *tager
stilling*. Alle løsninger har fordele og ulemper, og hvad man vælger
afhænger som nævnt også af hvilke ressourcer, man har til rådighed.
Man må så leve med konsekvenserne af de beslutninger, man tager - men
så er det i det mindste en bevidst beslutning og ikke noget der *bare
sker*

--
Jørn Andersen,
Brønshøj

---

Jørn Andersen skrev:

> Den skillelinie vil jeg sagtens kunne leve med - det ændrer
> bare ikke ved, at du vil opleve brugere, der "går forgæves".

Her er det afgørende så hvor meget der skal til for at brugerne
ikke går forgæves alligevel. Med eksemplet fra før vil det ikke
være et stort problem for en habil bruger at benytte søgefunktionen
til at finde den nye adresse. Men det kræver selvfølgelig at man
ved lidt om hvad man leder efter. Linket:

<server.dk/artikel.asp?artikelID=234> er ubrugeligt hvis man ikke
kan søge på artikelnumre i et nyt system. Men hvis det indgår i en
sammenhæng hvor man refererer til linket er det straks lettere:

Usenetsiden om citatteknik: <usenet.dk/netikette/citatteknik.html>

Hvis adressen blev ændret (internt på serveren) har man med et
ordentligt søgeværktøj alligevel gode muligheder for at finde
siden.

Det er altså også vigtigt (i mine øjne) hvordan man bruger sine og
andres links.


>>Hvis det gør mig til en skidt programmør må jeg leve med det
>>.
>
> Slet ikke - det vigtigste er efter min ringe mening, at man
> *tager stilling*.


Helt enig.


--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Tobias Hinnerup skrev:

> Hvis ikke du synes at en URI som f.eks.
> http://www.google.com/advanced_search?q=Tobias+Hinnerup&hl=da&l
> r=&ie=UTF-8 er forvansket, så fred være med dig

Den er da ikke forvansket. Jeg kan forstå at du synes den er grim -
men det er ikke det samme. Mellemrummet i "Tobias Hinnerup" er
erstattet af et plustegn - det er den eneste ændring der sker med
dit søgeudtryk (visse andre tegn vil også blive ændret, men de
fleste tegn sendes uændret).

At Google så finder det relevant at tilføje et antal ekstra
parametre har ikke noget med forvanskning at gøre.


--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

Chrisser wrote in news:am71k3$2k2$1@sunsite.dk:

> Post data bliver sendt som en del af HTTP-bodyen, og læses i asp ved
> Request.Form("mitFelt").

men ved du tilfældigvis også, hvordan de sendes som en del af entity-body ?
Jeg sidder med RFC2616/1945 og forsøger at læse mig frem til, hvordan
syntaksen er for data i entity-body ... men jeg kan ikke finde ud af det. Er
det samme "format" som body i en HTML, hvor body er delt op i en text/plain-
del og (evt) en multipart/-del ?



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns928CB4152D107spamstocholmdk@192.38.208.81...

> men ved du tilfældigvis også, hvordan de sendes som en del af entity-body
?
> Jeg sidder med RFC2616/1945 og forsøger at læse mig frem til, hvordan
> syntaksen er for data i entity-body ... men jeg kan ikke finde ud af det.
Er
> det samme "format" som body i en HTML, hvor body er delt op i en
text/plain-
> del og (evt) en multipart/-del ?
>
Tjaa, nu er vi inde i total sort snak for mig, så jeg er ikke spor sikker på
at jeg kan være til nogen hjælp
MEN, jeg har lige slået post op i min asp-bog, og der er entity er nævnt som
en del af HTTP-headeren, indeholdende information om data som sendes mellem
klient og server (intet andet)

Endvidere siger den udover get, post og head( som er næsten det samme som
get ), PUT, DELETE, TRACE, CONNECT og OPTIONS som nogle af de andre de andre
metoder støttet af HTTP...
Det er dog uden for bogens område og der henvises til:
http://www.cis.ohio-state.edu/htbin/rfc/rfc2068.html
- og hvis det kunne have forbindelse med det du søger, så må vi jo håbe at
de i mellemtiden ikke har skiftet teknologi

Chrisser

PS: Andre måske nyttige links fra bogen (de er heller ikke testet):
http://www.asptoday.com/ (artikler skrevet af eksperter)
http://www.powerasp.com/ (kodestumper, trics, forum mm)

---

"Chrisser" <cbj@egdatainform.dk> wrote in message news:am99fb$742$1@sunsite.dk...
>
> http://www.cis.ohio-state.edu/htbin/rfc/rfc2068.html
> - og hvis det kunne have forbindelse med det du søger, så må vi jo håbe at
> de i mellemtiden ikke har skiftet teknologi

Det er _lidt_ OT, jeg ved det - men hvis man går til kilden, vil man faktisk kunne
konstatere at de benytter en mere fornuftig URI til den ressource:
http://www.w3.org/Protocols/rfc2068/rfc2068 (og nej, jeg kan ikke genneskue hvorfor den
gentages i slutningen) *gG*

/Tobias

---

"Tobias Hinnerup" <hinnerup@nospamhinnerup.net> skrev i en meddelelse
news:am9bk6$2g76$1@news.cybercity.dk...
> Det er _lidt_ OT, jeg ved det - men hvis man går til kilden, vil man
faktisk kunne
> konstatere at de benytter en mere fornuftig URI til den ressource:
> http://www.w3.org/Protocols/rfc2068/rfc2068 (og nej, jeg kan ikke
genneskue hvorfor den
> gentages i slutningen) *gG*
>

Nu ved jeg da at mit måske svar er nået frem
- jeg kan ikke selv se det hos mig.

Og nu er jeg nødt til at spørge: Hvad betyder det når i skriver OT ???

Mvh
Chrisser

---

On Wed, 18 Sep 2002 10:01:55 +0200, "Chrisser" <cbj@egdatainform.dk>
wrote:

>Hvad betyder det når i skriver OT ???

Off Topic = uden for gruppens emneområde

I øvrigt en lidt underlig forkortelse, da det modsatte er On Topic,
som har samme forkortelse

--
Jørn Andersen,
Brønshøj

---

> Off Topic = uden for gruppens emneområde
>
> I øvrigt en lidt underlig forkortelse, da det modsatte er On Topic,
> som har samme forkortelse
>
> --
> Jørn Andersen,
> Brønshøj

Ja, den har jeg også undret mig lidt over - hvem i alverden har fundet på
det?

Og her lidt mere OT - noget nyt fra Wannafind?

/Henrik

---

Chrisser wrote in news:am99fb$742$1@sunsite.dk:

>
> "Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
> news:Xns928CB4152D107spamstocholmdk@192.38.208.81...
>
>> men ved du tilfældigvis også, hvordan de sendes som en del af
>> entity-body

> Tjaa, nu er vi inde i total sort snak for mig, så jeg er ikke spor
> sikker på at jeg kan være til nogen hjælp
> MEN, jeg har lige slået post op i min asp-bog, og der er entity er
> nævnt som en del af HTTP-headeren, indeholdende information om data
> som sendes mellem klient og server (intet andet)

Det er for så vidt næsten korrekt. Ved GET-requests er entity-body tom -
hvorimod dette ikke er tilfældet ved POST. Envidere kræver data i entity-
body, at der i headeren sættes linien

content-length:

der siger, hvor meget data der er i entity-body.

Men hvis jeg kigger i den reference du gav, så giver den - i lighed med
RFC1945 og RFC2616 kun denne beskrivelse:

entity-body = *OCTET

(sec. 7.2)

Og dette forstår jeg ikke helt ...

> Endvidere siger den udover get, post og head( som er næsten det samme
> som get )

det kan godt være, at de er næsten det samme ... men jeg vil nu mene, at
der er stor forskel på de situationer, hvor man vælger HEAD frem for fx
GET.



--
Jesper Stocholm
http://stocholm.dk
http://asp.stocholm.dk
Svar til gruppen og ikke til mig privat pr. email :|

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns928EACAB3A60spamstocholmdk@130.226.1.34...
> Chrisser wrote in news:am99fb$742$1@sunsite.dk:
>
>
> Det er for så vidt næsten korrekt. Ved GET-requests er entity-body tom -
> hvorimod dette ikke er tilfældet ved POST. Envidere kræver data i entity-
> body, at der i headeren sættes linien
>
> content-length:
>
> der siger, hvor meget data der er i entity-body.

- så blev jeg da også lidt klogere...

> det kan godt være, at de er næsten det samme ... men jeg vil nu mene, at
> der er stor forskel på de situationer, hvor man vælger HEAD frem for fx
> GET.

Ja, jeg har aldrig brugt HEAD, så jeg skal ikke kunne sige det...jeg samlede
bare sammen, hvad der lige stod i min bog, for der kunne jo være at der var
noget Tobias kunne bruge

Chrisser

---

"Jesper Stocholm" <jespers@stocholm.invalid> skrev i en meddelelse
news:Xns928CB4152D107spamstocholmdk@192.38.208.81...
> men ved du tilfældigvis også, hvordan de sendes som en del af entity-body
?
> Jeg sidder med RFC2616/1945 og forsøger at læse mig frem til, hvordan
> syntaksen er for data i entity-body ... men jeg kan ikke finde ud af det.
Er
> det samme "format" som body i en HTML, hvor body er delt op i en
text/plain-
> del og (evt) en multipart/-del ?
>
>

Hej hvor er mit svar blevet af ???
Chrisser