تابعی برای هدایت کاربر به صفحه مورد نظر

[marvel]

سلام
من دنبال تابعی می گردم که بتونم با فراخونی اون به یه صفحه مشخص برم.
مثلا اگر کاربر نام کاربری و کلمه عبور را درست وارد کرد به صفحه محصولات هدایت بشه.
لطفا منو راهنمایی کنید.

[oxygenws]

header
راهنمای PHP رو بخون.

[peyman1987]

همونطور که گفتن با تابع header و خصوصیت location میتونین اینکار رو بکنین
بقیشو خودتون از مرجع پیدا کنین تا برای همیشه توی ذهنتون بمونه

[babak869]

شکل کلی دستور به شکل زیره


header ("LOCATION:http://www.mysite/mypage.php");
exit;

موفق باشید

[oxygenws]

header ("LOCATION:http://www.mysite/mypage.php");

این از نظر منطقی مشکل داره و استاندارد نیست. این درسته:

header ("Location: http://www.mysite/mypage.php");

[babak869]

این از نظر منطقی مشکل داره و استاندارد نیست. این درسته:

ببخشید منظورتون از غیر منطقی بودن فقط حروف کوچک نوشتن Location هست؟ من که تا بحال با این شکل نوشتن به مشکلی بر نخوردم . در مورد استانداردش میشه بیشتر توضیح بدید ؟

[oxygenws]

ببخشید منظورتون از غیر منطقی بودن فقط حروف کوچک نوشتن Location هست؟ من که تا بحال با این شکل نوشتن به مشکلی بر نخوردم . در مورد استانداردش میشه بیشتر توضیح بدید ؟
آره برادر... این که به مشکل بر بخوری یا نخوری به مرورگرت بر می گرده و وقتی کاری رو استاندارد انجام ندی، یعنی ممکنه یه جایی، تو یه سیستم عامل دیگه، توی یک دنیای دیگه... به مشکل بخوره...
این استاندارد های رو می تونی توی RFC ها پیدا کنی... اگر نفهمیدی چی گفتم، بگو تا بیشتر توضیح بدم.

[armin390]

در http/1.0 باید بین : و مقدار فیلد یک فاصله هم باشه و از اونجا که در سطح php ما به عنوان برنامه نویس نمی تونیم پروتکل رو تعیین کنیم مجبوریم که بر طبق این استاندارد عمل کنیم تا 1.1(که در اینجا هم بر استفاده از فاصله تاکید شده) رو هم پوشش بده ولی بالعکسش مورد داره..

[babak869]

این استاندارد های رو می تونی توی RFC ها پیدا کنی... اگر نفهمیدی چی گفتم، بگو تا بیشتر توضیح بدم.

خدا رو شکر سو تفاهم بخوبی و خوشی حل شد !!!
موفق و پیروز باشی

[I,Nobody]

بابک جان من فکر نمی کنم که مدیر محترم قصد توهین داشته.
شما فرض کن نوشته " اگه متوجه نشدی "
اینجوری واسه همه بهتره

[oxygenws]

RFC مربوط به HTTP1.1 رو می تونی در اینجا ببینی:
http://www.faqs.org/rfcs/rfc2616.html

در این RFC گفته شده که هدر ها می تونند کوچیک یا بزرگ نوشته بشن، اما منظور هدر های کل entity است و این قضیه ربطی به هدر های response یا request نداره و این هدر های خاص باید سینتکس خاص خودشون رو داشته باشند.
بخش ۱۴.۳۰ از این RFC به این مقوله پرداخته....


14.30 Location

The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. The
field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

An example is:

Location: http://www.w3.org/pub/WWW/People.html

Note: The Content-Location header field (section 14.14) differs
from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache
requirements of some methods.

خوش باشید

پ.ن: بابک، بد نیست پست قبلی من رو با تصور «صورتی خندون» از من، بخونی و ببینی که، خواننده، می تونه دچار سوء تفاهم بشه!!!

[babak869]

بله درسته . من کاملا تفاوت این دونوع نوشتن رو متوجه شدم.(از کمک های گذشته ت هم متشکرم ).
موفق باشی

[armin390]

در این RFC گفته شده که هدر ها می تونند کوچیک یا بزرگ نوشته بشن، اما منظور هدر های کل entity است و این قضیه ربطی به هدر های response یا request نداره و این هدر های خاص باید سینتکس خاص خودشون رو داشته باشند.نه؛ دقیقاً نام برده شده چه فیلدهایی رو شامل میشن:
RFC 2616


4.2 Message Headers

HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 (http://www.faqs.org/rfcs/rfc822.html) [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive. The field value MAY be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications ought to follow "common form", where
one is known or indicated, when generating HTTP constructs, since
there might exist some implementations that fail to accept anything

beyond the common forms.

message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>

The field-content does not include any leading or trailing LWS:
linear white space occurring before the first non-whitespace
character of the field-value or after the last non-whitespace
character of the field-value. Such leading or trailing LWS MAY be
removed without changing the semantics of the field value. Any LWS
that occurs between field-content MAY be replaced with a single SP
before interpreting the field value or forwarding the message
downstream.

The order in which header fields with differing field names are
received is not significant. However, it is "good practice" to send
general-header fields first, followed by request-header or response-
header fields, and ending with the entity-header fields.

Multiple message-header fields with the same field-name MAY be
present in a message if and only if the entire field-value for that
header field is defined as a comma-separated list .
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma. The order in which header fields with the same
field-name are received is therefore significant to the
interpretation of the combined field value, and thus a proxy MUST NOT

change the order of these field values when a message is forwarded.




[I] 6.2 Response Header Fields

The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and about
further access to the resource identified by the Request-URI.

response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33

| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47

Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as entity-header fields.

[babak869]

حیفم اومد فقط با یه تشکر خشک و خالی سایت از شما عزیزان تشکر کنم. توضیحات شما خیلیمنو راهنمایی کرد و موضوع کاملا برام روشن شد
بسیار متشکرم