Re: [WSG] Where did I come from?

[Patrick H. Lauke]

Sarah Peeke wrote:

So, if the HTTP headers are "changed along the response chain from 
server to client" what is the likely outcome? Where would the user be 
directed in this case?


The user is not directed anywhere, it's just that - in the case we're 
discussing - the receiving page can't determine the referrer (it's 
either blank, or changed to something random). As it's not uncommon for 
headers like http-referer to be rewritten (for instance, anybody using 
Norton Internet Security has this), it simply means you as a developer 
can't rely on them (to gather stats on referrers, or create a magical 
and redundant "back" button/link, etc).


P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Hassan Schroeder]

changed along the response chain from server to client they can't be
relied upon.


Other way 'round.

Referer is a Request header, (optionally) originated by the client.
But even user agents that provide one may have it stripped from the
Request by "personal fire walls", proxies, etc.

But since it's optional, servers (and well-written web applications)
shouldn't care. :-)



--
Hassan Schroeder - [EMAIL PROTECTED]
Webtuitive Design ===  (+1) 408-621-3445   === http://webtuitive.com

  dream.  code.


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Lea de Groot]

On Tue, 22 Jan 2008 13:58:52 +1100, Sarah Peeke wrote:
> So, if the HTTP headers are "changed along the response chain from 
> server to client" what is the likely outcome? Where would the user be 
> directed in this case?

HTML doesn't care.
Its possible to write server-side code that generates different markup 
based on the referer, or even js code the same, but HTML on its own 
doesn't read the referer to care what it says or doesn't say and will 
display the same.

warmly,
Lea
-- 
Lea de Groot
Elysian Systems
Brisbane, Australia


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Matthew Cruickshank]

On Jan 22, 2008 3:58 PM, Sarah Peeke <[EMAIL PROTECTED]> wrote:
> So, if the HTTP headers are "changed along the response chain from
> server to client" what is the likely outcome? Where would the user be
> directed in this case?


That depends on the application. It's not a required field, but that
doesn't mean that applications shouldn't make decisions based on it.

A good example of web software that makes decisions based on referrers
are anti-image-leech scripts*.


--
.Matthew Cruickshank
http://holloway.co.nz/
[*] and image leech scripts are a good response to kids that use your
photos  and drain through gigs
of traffic... because then you start serving up something like this
instead http://holloway.co.nz/image-leech.jpg


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Chris Knowles]

Sarah Peeke wrote:

> So, if the HTTP headers are "changed along the response chain from
> server to client" what is the likely outcome? Where would the user be
> directed in this case?

the http referer is just the uri of the page that referred you to the
current page you are on. So if you are on page A and click on a link
that takes you to page B, then the Page B headers may show the http
referer as being page A. But they may not as it may never be set in the
first place or may be changed or removed along the way, e.g. by a proxy
server. So there is no outcome other than the referer header may not be
set and so if it's not then it can't be referenced.


-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Sarah Peeke]

On 22/1/08 1:37 PM, Chris Knowles wrote:

Referer is just one HTTP header - it is separate from response codes
(200, 404 etc) and other headers. No error is thrown if it's not present
so content is passed on as normal. But because HTTP headers can be
changed along the response chain from server to client they can't be
relied upon. 


Hi Chris,

Thanks for your reply.

So, if the HTTP headers are "changed along the response chain from server to 
client" what is the likely outcome? Where would the user be directed in this case?

Cheers,
--
Sarah Peeke
XERT Communications
Email: [EMAIL PROTECTED]
Skype: s.peeke
Website: http://xert.com.au/
LinkedIn: http://www.linkedin.com/in/sarahpeeke
Geofeat International: http://geofeat.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Chris Knowles]

Chris Knowles wrote:
> Sarah Peeke wrote:
>> Hi Martin and others,
>>
>> On 19/1/08 1:45 AM, Martin Heiden wrote:
>>> 2. HTTP-Header Referrer - may be supressed by proxies/firewalls or the
>>> user
>>>You can access it via (PHP|Java|ASP|...) or by JS document.referrer
>> Just out of interest, what happens when HTTP-Header Referrer is
>> suppressed? Does the page remain unchanged, is there a 404, or some
>> other error?
>>
> 
> Sarah,
> 
> Referer is just one HTTP header - it is separate from response codes
> (200, 404 etc) and other headers. No error is thrown if it's not present
> so content is passed on as normal. But because HTTP headers can be
> changed along the response chain from server to client they can't be
> relied upon.
> 
> 

actually, I should have said "changed along the request/response chain
between server and client".

-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Chris Knowles]

Sarah Peeke wrote:
> Hi Martin and others,
> 
> On 19/1/08 1:45 AM, Martin Heiden wrote:
>> 2. HTTP-Header Referrer - may be supressed by proxies/firewalls or the
>> user
>>You can access it via (PHP|Java|ASP|...) or by JS document.referrer
> 
> Just out of interest, what happens when HTTP-Header Referrer is
> suppressed? Does the page remain unchanged, is there a 404, or some
> other error?
> 

Sarah,

Referer is just one HTTP header - it is separate from response codes
(200, 404 etc) and other headers. No error is thrown if it's not present
so content is passed on as normal. But because HTTP headers can be
changed along the response chain from server to client they can't be
relied upon.


-- 
Chris Knowles


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Where did I come from?

[Sarah Peeke]

Hi Martin and others,

On 19/1/08 1:45 AM, Martin Heiden wrote:

2. HTTP-Header Referrer - may be supressed by proxies/firewalls or the user
   You can access it via (PHP|Java|ASP|...) or by JS document.referrer


Just out of interest, what happens when HTTP-Header Referrer is suppressed? 
Does the page remain unchanged, is there a 404, or some other error?

--
Sarah Peeke
XERT Communications
Email: [EMAIL PROTECTED]
Skype: s.peeke
Website: http://xert.com.au/
LinkedIn: http://www.linkedin.com/in/sarahpeeke
Geofeat International: http://geofeat.com/


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] When can I start using E4X

[liorean]

On 15/01/2008, Keryx Web <[EMAIL PROTECTED]> wrote:
> "I know Opera have E4X in the works at some level"
> http://www.codingforums.com/showpost.php?s=a9dfc400dfd427203a99487bd4ea29d9&p=448007&postcount=10

That comment's based on the the fact that Opera resolved my RFE for
"for each" looping as fixed, and "for each" is part of E4X. It's a
very long step to derive the assumption Opera have E4X in the works
from that, however. There's tons of uses of "for each" looping, and
implementing "for each" is cheap if you're aiming at creating an
internal structure that will be able to implement ES4 enumerators
efficiently.

> My questions:
> 1. Are there any clear indications from the developers of these browser
> engines (or their internal ECMAScript engines) that I've missed?

Well, you might want to read what Jeff Walden says about Mozilla
implementing E4X at
http://www.webstandards.org/2008/01/16/whats-the-best-test-for-acid3/#comment-59499>

> 2. Will E4X on MSIE in fact be facilitated through ScreamingMonkey?
>
> 3. When do you predict that we can really start using E4X and expect it
> to work for most visitors to our websites?

With any luck, it will be E5X (well, it's a better name than E44X...)
by then, will work well together with ES4, and have several integrity
and interoperability problems fixed.



On 15/01/2008, David Storey <[EMAIL PROTECTED]> wrote:
> I can't comment officially on support for ECMAScript 4, but we do
> have people that are involved in the ECMAScript meetings (such as at
> http://wiki.ecmascript.org/doku.php?id=meetings:minutes_jul_27_2006),
> and we do strongly believe in implementing standards.  We also have
> an article on Dev Opera from our lead javascript engineer on why he
> loves ECMAScript4 - http://dev.opera.com/articles/view/why-i-love-
> ecmascript-4-real-decimals/ .  So you can take those as hints that we
> plan support sometime in the future.

E4X is not part of ECMAScript 4, it's an extension to ECMAScript 3. A
slightly broken one, at that.


To quote myself in a mail to one of the Opera volunteer mailing lists,
editing out the quoted Opera staff:
> If you ask me (which you haven't...):
>
> - E4X isn't that very useful unless it cooperates seamlessly with the
> DOM, so that we can use it to manipulate document trees in place. This
> is not the case in the Moz implementation, and that level of E4X is
> simply not worth it for developers.
>
> - ES4 though - I can imagine a few of the new features being popular,
> but them being relevant for developers would require pretty much all
> browsers to have implementing them as a high priority issue. I'm
> particularly interested in features like true arrays, true
> dictionaries, the new number types and the scope improvements from
> block scope and namespaces.
>
> - Most interesting for a developer is those changes that can be
> emulated if not present, that doesn't need a "use only if this support
> is present" switch like a version=#.# attribute on the Content-Type -
> that is, mostly standard library stuff. This simply because those can
> be utilised in current code with only minor headaches, unlike any of
> the syntax additions.

I'd say Opera would do best spending developer resources:
1a. Matching the syntax/semantics extensions of Mozilla JavaScript
1.6-1.9, with array comprehensions, let blocks, let expressions etc.
1b. Implementing standard library only fearures. (.hashcode property
on all values is an example I'd like to see here)
2. Implementing the features of ES4 in order of what is perceived to
give most benefit to web developers with some kind of opt-in flag á la
"application/javascript;e4x=1".
3. And maybe last, E4X.
-- 
David "liorean" Andersson

***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***